Discussion:
Unexpected UDP packet loss
(too old to reply)
Steve Folly
2006-12-05 21:28:12 UTC
Permalink
I know... I know... Before anyone replies with the obvious...

Yes, I *know* UDP is unreliable and it is not guaranteed that my app will
receive all UDP packets sent to it - routers dropping packets, buffer
overflows, etc.

But, there is just one scenario (below) that took me by surprise, and was
wondering if someone could explain.

In summary - the first fragmented UDP packet received at a host after
reconnecting the network cable is dropped.

More detail...

My set up is 2 hosts (both Windows XP SP2) connected directly to each other
by single cross-over ethernet cable.

1. Disconnect and then re-connect the network cable.
2. Send a single (unfragmented) UDP packet from host A to host B.
3. Host B receives the packet with no problem.
4. Send another unfragmented UDP packet for A to B.
5. Again, host B receives the packet.
4. Disconnect and re-connect the cable again.
5. Send a single (fragmented) UDP packet from A to B.
6. Host B does *NOT* receive the packet.
7. Send another fragmented UDP packet from A to B.
8. Host B now *DOES* receive the packet.


Just to reiterate, I know I must not expect guaranteed delivery of UDP
packets, but it was this one scenario that threw me a bit - since there is
no router involved, and with one 2KB packet, I was hardly expecting an
overflow!

Thanks for any insight.
--
Regards,
Steve.
Ben Voigt
2006-12-05 23:30:19 UTC
Permalink
Post by Steve Folly
I know... I know... Before anyone replies with the obvious...
Yes, I *know* UDP is unreliable and it is not guaranteed that my app will
receive all UDP packets sent to it - routers dropping packets, buffer
overflows, etc.
But, there is just one scenario (below) that took me by surprise, and was
wondering if someone could explain.
In summary - the first fragmented UDP packet received at a host after
reconnecting the network cable is dropped.
More detail...
My set up is 2 hosts (both Windows XP SP2) connected directly to each other
by single cross-over ethernet cable.
1. Disconnect and then re-connect the network cable.
2. Send a single (unfragmented) UDP packet from host A to host B.
3. Host B receives the packet with no problem.
4. Send another unfragmented UDP packet for A to B.
5. Again, host B receives the packet.
4. Disconnect and re-connect the cable again.
5. Send a single (fragmented) UDP packet from A to B.
6. Host B does *NOT* receive the packet.
7. Send another fragmented UDP packet from A to B.
8. Host B now *DOES* receive the packet.
Just to reiterate, I know I must not expect guaranteed delivery of UDP
packets, but it was this one scenario that threw me a bit - since there is
no router involved, and with one 2KB packet, I was hardly expecting an
overflow!
Are you using DHCP? When the cable status changes, it could cause a network
reconfiguration which could flush buffers, etc.
Post by Steve Folly
Thanks for any insight.
--
Regards,
Steve.
Steve Folly
2006-12-06 06:15:35 UTC
Permalink
Post by Ben Voigt
Post by Steve Folly
I know... I know... Before anyone replies with the obvious...
Yes, I *know* UDP is unreliable and it is not guaranteed that my app will
receive all UDP packets sent to it - routers dropping packets, buffer
overflows, etc.
But, there is just one scenario (below) that took me by surprise, and was
wondering if someone could explain.
In summary - the first fragmented UDP packet received at a host after
reconnecting the network cable is dropped.
More detail...
My set up is 2 hosts (both Windows XP SP2) connected directly to each other
by single cross-over ethernet cable.
1. Disconnect and then re-connect the network cable.
2. Send a single (unfragmented) UDP packet from host A to host B.
3. Host B receives the packet with no problem.
4. Send another unfragmented UDP packet for A to B.
5. Again, host B receives the packet.
4. Disconnect and re-connect the cable again.
5. Send a single (fragmented) UDP packet from A to B.
6. Host B does *NOT* receive the packet.
7. Send another fragmented UDP packet from A to B.
8. Host B now *DOES* receive the packet.
Just to reiterate, I know I must not expect guaranteed delivery of UDP
packets, but it was this one scenario that threw me a bit - since there is
no router involved, and with one 2KB packet, I was hardly expecting an
overflow!
Are you using DHCP? When the cable status changes, it could cause a network
reconfiguration which could flush buffers, etc.
DHCP is not configured on the particular interface exhibiting the described
symptoms. Although it wouldn't surprise me if things get flushed and reset
when the cable status changes anyway.
--
Regards,
Steve.
Arkady Frenkel
2006-12-06 09:28:27 UTC
Permalink
Use some sniffer ( netmon, ethereal ) on both peers to check if that sender
fail or receiver
Arkady
Post by Steve Folly
Post by Ben Voigt
Post by Steve Folly
I know... I know... Before anyone replies with the obvious...
Yes, I *know* UDP is unreliable and it is not guaranteed that my app will
receive all UDP packets sent to it - routers dropping packets, buffer
overflows, etc.
But, there is just one scenario (below) that took me by surprise, and was
wondering if someone could explain.
In summary - the first fragmented UDP packet received at a host after
reconnecting the network cable is dropped.
More detail...
My set up is 2 hosts (both Windows XP SP2) connected directly to each other
by single cross-over ethernet cable.
1. Disconnect and then re-connect the network cable.
2. Send a single (unfragmented) UDP packet from host A to host B.
3. Host B receives the packet with no problem.
4. Send another unfragmented UDP packet for A to B.
5. Again, host B receives the packet.
4. Disconnect and re-connect the cable again.
5. Send a single (fragmented) UDP packet from A to B.
6. Host B does *NOT* receive the packet.
7. Send another fragmented UDP packet from A to B.
8. Host B now *DOES* receive the packet.
Just to reiterate, I know I must not expect guaranteed delivery of UDP
packets, but it was this one scenario that threw me a bit - since there is
no router involved, and with one 2KB packet, I was hardly expecting an
overflow!
Are you using DHCP? When the cable status changes, it could cause a network
reconfiguration which could flush buffers, etc.
DHCP is not configured on the particular interface exhibiting the described
symptoms. Although it wouldn't surprise me if things get flushed and reset
when the cable status changes anyway.
--
Regards,
Steve.
Ben Voigt
2006-12-07 20:40:54 UTC
Permalink
Post by Steve Folly
Post by Ben Voigt
Post by Steve Folly
I know... I know... Before anyone replies with the obvious...
Yes, I *know* UDP is unreliable and it is not guaranteed that my app will
receive all UDP packets sent to it - routers dropping packets, buffer
overflows, etc.
But, there is just one scenario (below) that took me by surprise, and was
wondering if someone could explain.
In summary - the first fragmented UDP packet received at a host after
reconnecting the network cable is dropped.
More detail...
My set up is 2 hosts (both Windows XP SP2) connected directly to each other
by single cross-over ethernet cable.
1. Disconnect and then re-connect the network cable.
2. Send a single (unfragmented) UDP packet from host A to host B.
3. Host B receives the packet with no problem.
4. Send another unfragmented UDP packet for A to B.
5. Again, host B receives the packet.
4. Disconnect and re-connect the cable again.
5. Send a single (fragmented) UDP packet from A to B.
6. Host B does *NOT* receive the packet.
7. Send another fragmented UDP packet from A to B.
8. Host B now *DOES* receive the packet.
Just to reiterate, I know I must not expect guaranteed delivery of UDP
packets, but it was this one scenario that threw me a bit - since there is
no router involved, and with one 2KB packet, I was hardly expecting an
overflow!
Are you using DHCP? When the cable status changes, it could cause a network
reconfiguration which could flush buffers, etc.
DHCP is not configured on the particular interface exhibiting the described
symptoms. Although it wouldn't surprise me if things get flushed and reset
when the cable status changes anyway.
Yes, but DHCP would tend to exchange packets starting when the cable
reconnected, and therefore perform the reconfiguration *some short time
later* when the DHCP handshake completed.
Post by Steve Folly
--
Regards,
Steve.
Loading...