[Winpcap-users] WinPcap and Netork Line Tap

[Gianluca Varenni]

As Bob said in the original message, the packets are not reordered by the 
tap (taps like the ones from netoptics do not reorder packets at all). In 
fact he says that the timestamps show no reordering. The problem is due to 
the buffering of WinPcap: packets are not notified in user mode as soon as 
they are received.

The only way to solve the problem is to "reorder" the packets while 
receiving it. The basic idea that comes to my mind is that at any given time 
you have two packets from each adapter, and you know for sure which of the 
four packets should go in the queue.

Hope it helps
GV





----- Original Message ----- 
From: "Bryan Kadzban" <bryan at kadzban.is-a-geek.net>
To: <winpcap-users at winpcap.org>
Sent: Sunday, August 12, 2007 11:29 AM
Subject: Re: [Winpcap-users] WinPcap and Netork Line Tap


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> Buffalo Bob wrote:
>> Does anyone have any suggestions on how to guarantee that my
>> application will receive the packets in the correct order ?
>
> Don't use Ethernet?
>
> Ethernet is not guaranteed to preserve the order of frames relative to
> each other (at least, I don't think -- I know IP is not guaranteed to do
> that, so I'm fairly sure Ethernet isn't either).  The only way you can
> get what you want is to have that guarantee from the network protocol.
> If you don't have the guarantee from the network protocol, then any
> device on the network can re-order the frames on you.
>
> I'd guess that the tap device is probably re-ordering the frames itself,
> just because it knows it can -- any higher-level protocol that requires
> order to be preserved will have its own method of doing that (e.g. TCP's
> sequence numbers).  But even if it's not the tap, it could be the
> switch, or the network stack on the other end.
>
> Plus, you have two different threads -- if you get a request on one
> thread, but a response on the other, then there's no way to enforce the
> ordering between the two threads.  (But maybe that setup can't happen.)
>
> Anyway, you will very likely need something other than Ethernet.  As I
> suspect that's not possible for you, I also suspect that your intended
> behavior can't be achieved.
>
> But why not add the requests/responses to a list, and signal a third
> thread?  That thread could keep its own list of which responses have
> shown up without seeing a request, and wait for the corresponding
> request on its own.  (With an eventual timeout.)  When it gets a request
> and its matching response, it can do the processing.  It'd be a fairly
> simple producer/consumer setup, and assuming the processing doesn't take
> too long, I think it should work fine.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGv1GES5vET1Wea5wRAwSYAJ9A7UThYAW9F9spQwsIaE6aPpR89wCfWTFz
> DohYMWNCEvXmSTGaRIx2/IA=
> =OtAZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users