Duplicate TCP Packets in Local Network

[ktsangop]

Hello everyone!

I have a server/client application running in 4 internet cafes, and i have a packet duplication problem in one of them.

I have thoroughly examined my code and tested it in my lab and cannot find any bugs whatsoever.
So on rare conditions some of the clients seems to receive duplicate packets. (I installed wireshark to investigate the problem in the specific shop).
I am not sure if this is causing my application to crash but i have nothing else to blame!
:)

So the question :

**Is there any chance that faulty hardware (router, switches, NICs) or bad drivers can cause packet duplication or packet corruption?? I even thought of viruses but firewall and antivirus software is enabled in all machines.
**
I am in a dead end and cannot think of anything here... If the problem wasn't in a specific shop only, i would re-examine my code but..

Thanks in advance!

[JorgeM]

Is there any chance that faulty hardware (router, switches, NICs) or bad drivers can cause packet duplication or packet corruption

Yes, there are a lot of reasons why packets would be re-transmitted on the network. A faulty switch port can easily cause CRC errors. Bad cables, cross-talk, etc...

[ktsangop]

Thanks JorgeM.

So could i suppose that tcp retransmission is a feature that i should deal programatically? Because i never thought of a scenario like that.

It seems that the client receives the packet, his ACK is not received by the server, and the server retransmits the packet. So the client receives 2 identical packets which is probably not handled well by my application.

Is the above scenario plausible in tcp connections or is this my misundestanding?

[JorgeM]

In the TCP/IP conceptual model, retransmissions and data correction happens at various layers from the NIC to the application layer. I'm not sure how to advise you with your situation regarding a client/server implementation.

The only thing I'm sure of is that packets arent always going to make it to the destination and they may not always get there intact either.

[ktsangop]

Ok thanks a lot JorgeM.

If anyone else has anything to contribute...

Otherwise i'm marking this as solved

[rubberman]

From what you say, if you are receiving duplicate packets, I can only assume that you are utilizing the UDP or other packet-based protocol, as opposed to a stream-oriented one such as TCP. The TCP protocol will discard duplicates - you should never see them. UDP will not discard them, and it is up to you to detect and discard them.

[ktsangop]

So what about this case for example :

http://www.cs.umd.edu/~shankar/417-F01/Slides/chapter3b/sld007.htm

This is supposed to be a scenario of retransmission (?)

[rubberman]

There is no guarantee that the ack gets back to the sender, as in the lost ack scenario. However, each packet has a sequence # and CRC, so the receiving network stack will keep track, especially if there are missing packets in between the ones it got. If it gets a duplicate, then it will discard the new copy, yet ack that as well so more don't get sent (hopefully). Naks are for packets that were received with a bad CRC. If the connection is really flaky, then it is possible that a duplicate will be received after the original one has been transmitted to the receiving application; however, the stack (driver) will STILL know that the current window has passed by the duplicate packet, and it will ack/discard it.

This is a problem at the network stack level - and not at the application level. I do network programming in high-volume, high-speed environments (multiple thousands of interacting systems world wide with 10 gigabit network connections internally, and multi-gigabit connections to the internet. This is NOT a problem! :-) It is a good school problem, however, which will impact hardware and firmware designers. My suggestion is that you develop a rigorous finite-state-machine representation of how to deal with this situation. I always find that it clarifies such edge cases very nicely.

FWIW, I have implemented a full TCP/IP stack for real-time embedded systems in the past (around 1990), so this is an issue I am intimately familiar with, and that software runs a lot of US Navy gear - network glitches are not well-received when you are running a warship far out at sea and have to deal with incoming threats! :-)

BTW, when I say I implemented the full stack, it was not from existing source code, but from the RFC's in the DDN (Defense Department Network) Protocol Handbook (the famous set of White Books) from the US DARPA (Defense Advanced Research Projects Agency) that define TCP/IP (thanks Vint Cerf and friends at BBN!). I had to model all interactions using state machines in order to prove that the code would work as designed.

[ktsangop]

Thanks a lot!
That's a really thorough explanation.

It seems like i will have to re-check my algorithmic design so... good luck to me!
:)

Thanks again!