1
votes

So I've been having an issue with the receive functionality with the PCap library.

I set up an echo server (outside my PC) that just takes a packet and turns it around. So, in my application, I send a packet (that works fine) and I tried receiving the response packet (from the echo server) with pcap_next(). For some reason, it would wait 1 whole second to receive the packet with pcap_next(), even though Wireshark shows the packet being turned around in less than 1ms. Thus, when I send 1000 packets, it takes 1000 seconds to receive all the responses.

I couldn't figure out why it was doing that, so I tried switching to pcap_loop(). Apparently now it's doing something even more strange. I send 1000 packets, and receive 1000 packets, but not in the order I would expect.

I expect this (this is what I see on Wireshark):

Send packet #1
Receive packet #1
Send packet #2
Receive packet #2
etc.

But this is what I really get:

Send packet #1
Send packet #2
etc.
Wait 1 second
Receive packet #1
Receive packet #2
etc.

What's going on here?

2
Have you tried setsockopt w/TCP_NODELAY? ( Throwing that out there randomly...I only just read about this recently, wondering if it would be relevant: en.wikipedia.org/wiki/Nagle%27s_algorithm )HostileFork says dont trust SE
Not applicable. I'm sending raw UDP packets.theanine

2 Answers

0
votes

Perhaps you want to poll, not pull. Just call pcap_dispatch or pcap_loop and it will call you back with a packet as soon as possible. pcap_next is not efficient as it starts a dispatch loop and stops it after the fist packet is received. Read more at http://www.tcpdump.org/pcap.html

0
votes

Figured out the solution. I needed to have TX and RX on two separate threads.

RX Thread does this forever:

pcap_loop(handle, -1, got_packet, NULL);

Then I call the TX thread whenever I want, which does this (and loops however many times I need):

pcap_sendpacket(t, TxPacket, DataLen + 42);

This solved the problem.