Older blog entries for lukeg (starting at number 5)

TCP seems to have a bad reputation, mostly for inefficiency. Friends often tell me about rolling their own protocols because of perceived problems with TCP, but nobody tells me real details of what TCP's doing wrong. Generally I think TCP gets a bad rap, but I'm curious about what all the perceived problems are.

The TCP Considered Annoying article (recently posted on raph's diary) is really interesting, but I don't think its title or conclusions are really justified. The specific criticisms are mostly for missing datagram-related feeping creatures rather than for TCP doing a bad job of its intended purpose: providing reliable streams over general internetworks. Particularly, I don't think it was established that "[of TCP's features] some almost always good, some of less certain value, and at least one outright bad", or that the desired extra features are worth adding to TCP.

I realise the author is a smart and informed guy, and that the article wasn't intended as "scientific writing", but I'd like to criticise none the less. This is partly to defend TCP's good name, partly to start a conversation by putting my head on the block, and partly to show off that I've read a book about networks ;-)

First off, there's not much against TCP as a reliable stream protocol for the internet. For people doing stream-based internet programs, TCP's doing a good job for them and they have no need to be "annoyed" with it or to invent their own hopefully-extra-efficient protocols based on UDP. The article doesn't suggest this, but I think it's a fairly common notion (y'know, for when it needs to be really efficient..)

For a specially provisioned network that won't lose packets or become congested, TCP's still going to do a pretty good job. You might like to disable nagle's algorithm to reduce latency, and perhaps tune your buffer sizes, but that's straight forward enough. The congestion-control features are mostly pay-as-you-use, the only thing that should affect you on such a network is slow-start. For initiating new connections to do batch transfers, TCP will give you some overhead - I estimate less than 2ms of total idle time on my local fast ethernet. So setting up new connections has some expense, but if you have a lot of data to transfer and you reuse the connections, this should disappear.

For the complaint that TCP hides packet boundaries, and that lower-layer IP packet shapes could be used instead of in-band length headers, I think a whole can of worms would be opened because this breaks the layering of the protocol stack. Specifically, convenient and useful things that (transparent) proxy servers and "Layer-7" switches can do today could break such a TCP by "reshaping" the packets (which can be useful, and is safe for a stream protocol). What about a content-transforming proxy server, or a generic TCP proxy with different path MTUs on either side? And what if the packets are larger than the MTU - use IP fragmentation? Programs like that would be more awkward to write and prone to subtle errors.

That added complexity doesn't seem worthwhile just to avoid writing some tiny in-band length headers, and would only partially satisfy people who want reliable datagrams, anyway.

Or maybe the real reason to be annoyed with TCP is the "worse is better" sense: it's so good for 90% of the cases that not enough people throw their weight behind things like reliable datagram protocols or SCTP.

This entry intentionally left blank.

I've just spent the swedish 4.5-day Easter weekend on some of the most frenzied hacking I've done in years, resulting in my new favourite home-made program: Distel. It's a partial and interoperable implementation of the Erlang programming language in Emacs Lisp. And I even have time left to brag about it on the internet before the sun rises!

I spent about a day writing a manual for Distel, which makes it the second program that I've been so excited about that I've written a "real" manual for it. The other was Echidna. I usually avoid writing, but it is interesting to go through a lot of iterations of the edit-print-read cycle, catching problems and making little improvements each time. The really interesting thing is how unsatisfactory it would turn out without all those iterations.

Which raises the awkward thought: I don't print/read/edit my programs that way. As an experiment I've been going through the loop a few times with some of my source code, and I think it makes a really solid improvement. I guess this is old news to good programmers, but I'm not usually in the habbit of sitting down and reading my own programs start-to-end.

If I were a real man I'd ask some colleagues to point out my worst code, and print/read/edit that. But I'm not sure I'm that brave right now :-)

All that said, the manual is probably full of typos, and the programs full of bugs - but such is life!

Today I added some basic builtin help functions to Ermacs. As well the as Emacsey C-h k <key sequence> `describe-key', I have a C-h s <key sequence> `find-source', which takes takes you to the source code that's bound to that key. So if you press a key and it doesn't do what you want, you're only about 1sec away from the source code. I think this is a good feature for an under-development editor :-)

Emacs still has the upper hand though, since it takes a bit more than a keystroke to load new definitions into Ermacs, for now..

Welcome back to the "real world", purcell :-)

I joined in with Language of the Year, where a bunch of people get together with the goal of learning a new programming language (Haskell) during the year. So, today I wrote my first Haskell program. Now I'm hoping someone can show me some nice ways to improve it with fancy Haskell features.

Decided to make an Advogato account of my very own, after perving in other ones for ages.

I'm presently trying to learn how to hack Linux's TCP stack, which is quite fun, sort of.

Hello mbp, purcell, demoncrat, joearm, mikl, everyone!