[Winpcap-users] EXT : WinPCAP Packet ordering

[Black, Michael (IS)]

I've been trying to tell you that UDP does NOT guarantee ordering.  And guess what you found...it's out of order.

It also doesn't guarantee delivery.  Your lucky you're not dropping packets...if you overrun the IP queue you would be dropping them.  You shouldb be using TCP.  Or...you need a sequence number in the packet so you can reassemble the order yourself.



That's why its nickname is "Unreliable Datagram Protocol".

http://en.wikipedia.org/wiki/User_Datagram_Protocol



You're probably seeing multi-core processing of packets...so it can pick them out of order since it doesn't violate the protocol.



http://stackoverflow.com/questions/2533873/why-do-i-get-udp-datagrams-out-of-order-even-with-processes-runnning-locally



Michael D. Black

Senior Scientist

NG Information Systems

Advanced Analytics Directorate



________________________________
From: winpcap-users-bounces at winpcap.org [winpcap-users-bounces at winpcap.org] on behalf of neil.powell neil.powell [neil.powell at HERRHAIR.COM]
Sent: Friday, February 25, 2011 2:44 AM
To: winpcap-users at winpcap.org
Cc: neil.powell neil.powell
Subject: EXT :[Winpcap-users] WinPCAP Packet ordering


Hello,

I would like to ask a question to the mailing list; I apologise if this has been
answered before I did search the archive but didn't see anything relating to my
question.

Firstly let me explain what I am trying to achieve...


I am writing a Windows application that is targeting Windows 7 64bit
multiprocessor machines.  The basic idea is as follows....  I have a piece of
hardware (FPGA based) that is delivering layer II packets over a Gbit network;
each packet is NO more than 1500 bytes.  The data rate pushed out of the FPGA is
typically 50Mbytes per sec or lower.

The purpose of the Windows application is the capture each packet off the
network, do some quick data integrity checks on the payload and dump it to disk
ASAP.  The FPGA has a 12bit packet counter (0-4095); this count is placed inside
our bespoke payload so that the data can be reconstituted on the PC. During the
data integrity checks I check the packet count to ensure the packets are in
order before I begin reconstituting the data; I also sanity check the timestamp
of each packet to make sure it too is increasing.


 Here is my question/problem.....
 On multicore 64 bit machines (with a 64 bit OS) can the packets come out of
order?
 My justification for the question is as follows. During debug of the windows
application I report the timestamp and pkt number of each packet.  Whilst it
appears that I do not drop packets I do see packets numbers come out of order.
Here is a debug trace.

   Timestamp             Pkt #
   15:38:40:415412   2222
   15:38:40:415413   2223
   15:38:40:415424   2224
   15:38:40:415425   2225
   15:38:40:415426   2226
   15:38:40:415428   2227
   15:38:40:415428   Found Packet: 2236 Expecting Packet: 2228
   15:38:40:415430   2237
   15:38:40:415431   2238
   15:38:40:415433   2239
   15:38:40:415433   Found Packet: 2228 Expecting Packet: 2240
   15:38:40:415434   2229
   15:38:40:415445   2230
   15:38:40:415447   2231
   15:38:40:415447   2232
   15:38:40:415448   2233
   15:38:40:415451   2234
   15:38:40:415452   2235
   15:38:40:415453   Found Packet: 2240 Expecting Packet: 2236
   15:38:40:415454   2241
   15:38:40:415456   2242
   15:38:40:415457   2243
   15:38:40:415467   2244
   15:38:40:415469   2245
   15:38:40:415471   2246

If you follow the trace you can see that I don't drop packets but they are
indeed out of order.
I must stress that this situation is NOT frequent but is exacerbated by high
data rates or heavy disk usage.
I have spent some time eliminating all the obvious… debug output buffering,
FPGA output and disk writes all of which have drawn a blank.

I am using WinPCAP in the following manner:

pcap_open:
snaplen = 1500;
flags =
PCAP_OPENFLAG_PROMISCUOUS|PCAP_OPENFLAG_NOCAPTURE_LOCAL|PCAP_OPENFLAG_MAX_RESPONSIVENESS;
read_timeout = 0;

pcap_setbuff:
100Mb

pcap_setmintocopy:
0


Thank you in advance



Neil Powell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20110225/9392e14c/attachment-0001.html>