Reply to post: Re: TCP is wrong for most network transactions

Don't rush to adopt QUIC – it's a slog to make it faster than TCP

doublelayer Silver badge

Re: TCP is wrong for most network transactions

"it invariably requires programmers to implement ad-hoc framing and messaging protocols on top of it. Web programming, for example, uses the same messaging codes that FTP does (those three digit codes you see at the beginning of the frames."

So does everything. UDP requires them to packetize everything, while TCP requires them to serialize everything. In each case, it's one or more strings of bytes. The only way for an application not to have to implement their own communication system above that is if the network layer implements lots of subtypes which it can transfer on its own. That's not very efficient--most programs' internal data will take the form of structures or classes which the transport layer certainly won't already know about.

"++A TCP connection requires at a minimum a couple of timers and an extra thread. If the socket is likely to drop then it needs a secondary process to monitor the connection to detect the dropped socket and silently reconnect."

It doesn't require those things. A single timer and no thread can work too because the process reading from the socket can do that checking. Extra threads are not required for recovering from a dropped socket. More importantly, most programs don't have threads in place to silently recover from dropped sockets because that may involve recovery on the process side as well. It is not automatically the case that if your socket is not working that you should open a new one and slot it in. Many protocols over TCP will want the side which reconnects to identify itself again, provide information on the last functioning state, etc.

"ACKs on protocols that already have ACKs (WiFi....)": No, that's two different systems with ACKs. Each serves a different purpose. The WiFi AP could I suppose do the TCP acknowledging for the user, but that breaks compatibility with wired networks which wouldn't bother with that. Implementing it on the wired networks, on the other hand, would require more processing in switches or modems to figure out which of them is supposed to be intercepting the user's stream in order to acknowledge it.

"TCP is not very reliable for long duration connections because of the problem of detecting a dropped socket and silently reconnecting.": Compared to alternatives, it's not that bad. If you want something that will stay connected for a very long time and you don't want it to drop, just arrange with the other side to send polls to one another from time to time. A single poll fail indicates that you need to reconnect. That works as well with TCP as it does with UDP.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon