If you follow Going Postal you will know the story of John Dearheart, a clacksman who was murdered. Like many who have died running the "clacks" (the discworld's version of a telegraph system) his name lives on. The message "GNU John Dearheart" continues. G means send on the message, N means not-logged, and U means return the message at the end of the line. This makes a datagram that continually bounces around the network.
IP as a protocol has a time-to-live (or hop-count) that stops a message going on forever, but for the names of those who should continue, we do not want a "time to live".
It seems that many systems and software around he world are finding GNU Terry Pratchett "on the wire".
Indeed, even the latest FireBrick alpha has a header, X-Clacks-Overhead: GNU Terry Pratchett in the software. His name will live on for a long time, buried in the code of the very Internet itself.
Update:
Rather than do this is a header in HTTP, which does add overhead, we have a different plan. It seems we had a slight issue with the code to handle small Ethernet packets (under 64 bytes) which ensures they are padded consistently (with NULL bytes). The internal operation of the FB2500/FB2700 was such that the last 4 bytes were not NULL. In practice this was not a leak of other buffers but an Ethernet checksum of an internal packet with a VLAN tag. However, the fix is to ensure the packets are sent with padding to 68 bytes before the VLAN tag is removed. OK, yes, this is technical.
However, padding can be anything, it does not have to be NULLs, so this is perhaps a far better place for this particular Easter Egg. On a zero payload IPv4 ICMP ping, we have 18 bytes to play with, which is one short for "GNU Terry Pratchett", but with one space removed, it aligns nicely on a packet dump as follows. In fact, ARP replies have exactly the same amount of space...
Now, yes, as one person has said, this is silly, but the actual content of the padding really does not matter at all, and can be anything. There is no harm, or waste in it being this string - so why not?
I'd like to get this in to an RFC http://www.me.uk/draft-kennard-padding.txt and I have emailed to the auditors of reality (I mean RFC editors) today (17th). P.S. I was considered but rejected, sorry.
IP as a protocol has a time-to-live (or hop-count) that stops a message going on forever, but for the names of those who should continue, we do not want a "time to live".
It seems that many systems and software around he world are finding GNU Terry Pratchett "on the wire".
Indeed, even the latest FireBrick alpha has a header, X-Clacks-Overhead: GNU Terry Pratchett in the software. His name will live on for a long time, buried in the code of the very Internet itself.
Update:
Rather than do this is a header in HTTP, which does add overhead, we have a different plan. It seems we had a slight issue with the code to handle small Ethernet packets (under 64 bytes) which ensures they are padded consistently (with NULL bytes). The internal operation of the FB2500/FB2700 was such that the last 4 bytes were not NULL. In practice this was not a leak of other buffers but an Ethernet checksum of an internal packet with a VLAN tag. However, the fix is to ensure the packets are sent with padding to 68 bytes before the VLAN tag is removed. OK, yes, this is technical.
However, padding can be anything, it does not have to be NULLs, so this is perhaps a far better place for this particular Easter Egg. On a zero payload IPv4 ICMP ping, we have 18 bytes to play with, which is one short for "GNU Terry Pratchett", but with one space removed, it aligns nicely on a packet dump as follows. In fact, ARP replies have exactly the same amount of space...
Now, yes, as one person has said, this is silly, but the actual content of the padding really does not matter at all, and can be anything. There is no harm, or waste in it being this string - so why not?
I'd like to get this in to an RFC http://www.me.uk/draft-kennard-padding.txt and I have emailed to the auditors of reality (I mean RFC editors) today (17th). P.S. I was considered but rejected, sorry.
I'm sorry, Pratchett was a great author, but this is just silly.
ReplyDeleteThere are many "silly" things in code, often called "Easter eggs".
DeleteThe final release of code may have more subtle place to put this, where some padding is needed and the content does not actually matter. We'll see how it goes.
DeleteAlthough I see this as a bit of fun, aren't you making it more difficult for people to diagnose faults, who don't have as much knowledge as yourself?
DeleteWell, the current plan of it being in padding data is not going to change anything, that is usually random or 00 or leaking data, it can be anything. I have seen plenty of places where you would see 18 bytes of some random web page in the padding.
DeleteAnother idea was to make an RFC (albeit 1st April one) that recommends the default padding for Ethernet frames be this. Now, if it goes in an RFC it will help diagnosis and debugging as it will be known to be deliberate packet padding rather than default null packet content.
DeleteFeatured on BBC News: http://www.bbc.co.uk/news/technology-31907768
ReplyDeleteSo basically you're Mad Al, Sane Alex, and Undecided Adrian.
ReplyDeleteWell, my name is Adrian :-)
DeleteI'm not sure Alex is sane - have you see his commuting videos?
DeleteI've linked your blog to the post. That's all kinds of awesome :D
ReplyDelete- frymaster
This is brilliant, a most excellent tribute.
ReplyDeleteSo appropriate. And I don't think faults diagnostics will have any issues with null bytes filled with data bytes in a field that randomly gets populated anyway. Tidy way of remembering the man.
ReplyDeleteI knew Terry some. We weren't intimates, but we were friendly and laughed at each others' jokes and enjoyed hanging out together.
ReplyDeleteThis proposal is a kindhearted use of space that I think he would have approved of.
I am a programmer, as well as a fan of Terry Pratchett, and I think this is brilliant.
ReplyDeleteGreat idea and a worthy way for fans to show their love. Not surprised to see some IT Grannies mumping about it being a waste of time. Away and bump your gums elsewhere you old trouts, TP would have loved this.
ReplyDeleteA more cynical mind would imagine that he'd planned it, he was very good at setting up jokes a long way back..
DeleteI'm so glad that I'm not the only technologist that wants to acclaim and honor the work of Sir Terry. I listen to Mozart and mourn his premature death at 35 years, at the peak of his composing creativity, and wonder what masterpieces another 30 years of composing humanity would have. And as I read Terry Pratchett's work, especially his later books, I mourn the untimely death of a man who was at the peak of his creative powers and would have left so much more for the world if he had been given another 30 years..
ReplyDelete