I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.
What happens in that case? I'm going to speculate: 1. Remote keeps sending stuff to your unplugged connection 2. You plug your ethernet cable back in 3. Your computer's TCP acknowledges the last sequence number it received for each new sequence it receives from remote 4. Remote sees duplicate ACKs for same sequence number, interprets it as packet loss and resends the stuff
Falsehoods programmers believe about TCP
21–30 of 247 posts
Re: Falsehoods programmers believe about TCP
#22Re: Falsehoods programmers believe about TCP
#23I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.
What happens in that case? I'm going to speculate: 1. Remote keeps sending stuff to your unplugged connection 2. You plug your ethernet cable back in 3. Your computer's TCP acknowledges the last sequence number it received for each new sequence it receives from remote 4. Remote sees duplicate ACKs for same sequence number, interprets it as packet loss and resends the stuff
If packets were sent while you were disconnected, they'll be gone, but if you're disconnected for only part of the burst, duplicate ACKing will trigger retransmits.
If you were gone for the whole burst, you'll get put right by timer based retransmits.
If you're gone for long enough, most peers will timeout on unacknowledged data (although that's not in the TCP RFC), and if there's no outstanding data, most peers eventually have some sort of periodic ping and timeout (tcp keep-alives is a reasonable fallback IMHO, if your application protocol doesn't have someything, although the default of IIRC 2 hours feels long in todays world of lots of NATs and much shorter timeouts).
Re: Falsehoods programmers believe about TCP
#24but you can get round that in a lot of cases by just having a load of TCP connections in parallel.
TCP is cheap and well optimised, especially if you are keeping a bunch of connections open. (opening can be expensive)
so if you have a high latency connection, or a bit of packet loss, and you want to reach line speed without having to figure out cornercases with UDP, just open up 100-1k TCP connections and multiplex them.
bish bash bosh, mostly line speed over a high latency line (mind you this was in the days of 100m-500m cross atlantic internet, you'll probably need more connections to saturate a 10gig line.)
Re: Falsehoods programmers believe about TCP
#25Related: you can get at most once delivery or at least once delivery; you cannot get exactly once delivery. If I had a dollar for every junior who thought that a lack of exactly once delivery guarantees was a bug...
edit: Point is in confirming that message is received. If you don't receive the confirmation the message was delivered at most once.
Re: Falsehoods programmers believe about TCP
#26Re: Falsehoods programmers believe about TCP
#27Re: Falsehoods programmers believe about TCP
#28Re: Falsehoods programmers believe about TCP
#29Re: Falsehoods programmers believe about TCP
#30I recall it blew my fiancée’s mind that I could unplug her ethernet cable, move it around an obstacle, plug it back in and all her connections were still alive. It’s designed to have bombs dropped on it.