Live data from Hacker News

Falsehoods programmers believe about TCP

lwn.net

21–30 of 247 posts

Re: Falsehoods programmers believe about TCP

#21
post #9

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

With timeouts. You can’t unplug it for an hour and have this happen. But a few seconds is exactly what this is designed for. As another commenter pointed out, your OS could also try to be “helpful”.

Re: Falsehoods programmers believe about TCP

#23
post #9

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

Yeah, that's pretty much it.

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

#24
So TCP has slow start, and exponential fall off and shit.

but 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

#25
post #22

Related: 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...

Yup, I try to explain it with shouting a message to someone in a crowded room. You can yell at your boss "I fixed the bug", they can confirm it or ignore you, which is delivery at most once if you don't repeat the message. If you try to repeat the message until they confirm it, it is at least once delivery.

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

#30
post #9

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.

.. on Linux. If you do that on Windows the MAC will detect the loss of link pulses, report the interface as down, and Windows will "helpfully" reset all your TCP connections.
Post reply on HN