from Hacker News

Three Dead Protocols

by englishm on 7/15/15, 10:52 PM with 75 comments

  • by userbinator on 7/16/15, 5:42 AM

    I think trivial protocols like this are a good thing to start with for educational purposes, because implementing one correctly does require quite a bit of effort for someone who has had no experience with networking or RFCs.

    Even for something as simple as QOTD the implementer has to consider things like message lengths and interpret terms like "should" (a recommendation, not an obligatory condition for compliance.) Observe that the standard also doesn't mandate that the message must change only once per day, so the implementation presented is compliant. :-)

    For TCP Echo, because TCP is a stream-oriented protocol and AFAIK since you can't actually send and receive simultaneously in code - it's always read or write - the question of how much to echo back, and after how long, is also something to consider. Theoretically, an echo server could wait to send until several GB of data were received or the connection is closed, buffering the data limitlessly, and still be compliant. This also shows the importance of being clear and precise when writing standards or protocol specifications in general, should you ever need to do so.

  • by linuxlizard on 7/16/15, 1:57 PM

    Late 90's I did firmware for print servers. The echo server was pretty important to us for testing our hand-rolled TCP/IP stack.

    Print server management was done through a Telnet interface. We also supported LPD which was one of the stupider protocols ever to see the light of day.

    I added a QOTD service to the firmware as an easter egg.

    I'm going to go soak my teeth now.

  • by Animats on 7/16/15, 7:08 AM

    As I mentioned when someone brought up the history of UDP, the original idea was that datagram protocols would be implemented at the IP level, as seen here. UDP offers the same functionality, but one level higher. In BSD, it was easier to do things from user space at the UDP level rather than at the IP level, and adding new protocols directly above IP fell out of favor.

    Try to get an IP packet that's not TCP, UDP, or ICMP through a consumer level Internet provider.

  • by achillean on 7/16/15, 4:14 AM

    These protocols may be deprecated, they may be unused and they may be out of sight but they aren't completely dead yet:

    https://www.shodan.io/report/9xshqrdb

    Many of these old protocols don't die easily and tend to linger around forever. Maybe there's a nostalgic element to keeping them alive for sysadmins :)

  • by kijin on 7/16/15, 5:25 AM

    Pretty much every port below 1024 is reserved for one protocol or another, but many of them have been obsolete for years. It seems that whoever was in charge of assigning well-known ports back then just handed them out like candy.

    Well, who am I kidding? This is the same IANA that used to hand out humongous blocks of IPv4 addresses to anyone who asked.

    Should we try to deprecate dead protocols so that low ports can be put into better use? Or have we come to expect that all new technologies will simply reuse ports 80 & 443, so we have no need to set aside new well-known ports anymore?

  • by placeybordeaux on 7/16/15, 5:45 AM

    Given the definition[1] of the echo protocol works on UDP you could potentially spoof the address to be coming from another echo server and have packets going back and forth indefiniately, correct?

    https://tools.ietf.org/html/rfc862

  • by kijin on 7/16/15, 5:15 AM

    > May 1983 [footnote] Fwiw, RFC 2616, for HTTP, was published the same month, so at least some people were doing actual work in those days.

    RFC 2616 was published in June 1999.

    I don't know what Sir Tim was doing in May 1983, but I'm pretty sure he wasn't writing an RFC for a protocol that he wouldn't invent for six more years.

    https://www.ietf.org/rfc/rfc2616.txt

  • by emmab on 7/16/15, 4:18 AM

    I think your implementation of "RFC 862, the Echo Protocol" wouldn't work if the input doesn't end in a newline.

  • by TheLoneWolfling on 7/16/15, 1:01 PM

    This actually brings up an annoyance with FF (well, Pale Moon, but same difference). If you try to open, say, pchs.co:17 with FF, it'll pop up a prompt saying "this address is restricted" - with no way of overriding it.

    You have to go into the config and add a key (!) to actually be able to access it. And worse, there's no way I've seen to actually just straight disable the "feature". You have to add an individual port, or a range of ports, or a comma-separated list of ports or ranges.

    (For those wondering, it's "network.security.ports.banned.override", with a value of a port, or range, or comma-separated list of ports or ranges. For example: "7,13,17".)

    Once you do, it works fine.

  • by zx2c4 on 7/16/15, 10:03 AM

    I've been running a QOTD service on my server for the last few years:

        $ nc zx2c4.com 17
    Source here: http://git.zx2c4.com/mulder-listen-daemon/tree/mulderd.c

    I also run a toy telnet server:

        $ telnet zx2c4.com
    :P

  • by rumcajz on 7/16/15, 5:24 AM

    Don't frget about TCPMUX listening on port 1. (RFC 1078) That's a serious stuff that could see many applications even in today's world.

  • by johnwfinigan on 7/16/15, 2:54 PM

    I have actually used daytime for a "real" use: as a quick and dirty way of eliminating the possibility of guest clock drift when running benchmark scripts inside of emulated guests with unreliable timekeeping. Obviously a bad idea for benchmarks measured on the order of seconds, but probably fine for benchmarks running for hours. ntpdate -q would probably work just as well though.

  • by skrebbel on 7/16/15, 9:28 AM

    Wait, did she just start an infinite number of threads in a loop, or is ruby awesome in ways I didn't know?

  • by batou on 7/16/15, 12:05 PM

    I spoke to someone a few years ago who has an asymmetrical transit cost agreement between two companies. He joked that it may have been lucrative to just pipe /dev/random to their echo port 24/7.

    I suspect that is one of the many reasons that is a dead protocol.

  • by foliveira on 7/16/15, 2:32 PM

    Nice little exercise. Just implemented the three servers in Node.js over lunch time.

    [1] https://github.com/foliveira/echo-is-not-dead

    [2] https://github.com/foliveira/qotd-is-not-dead

    [3] https://github.com/foliveira/daytime-is-not-dead

  • by chrismorgan on 7/16/15, 3:59 AM

    RFC 2616 has been superseded by RFC 7230 et al.

  • by imauld on 7/16/15, 4:32 PM

    This isn’t about the protocol, but you should know my code for this is really sloppy because it was my first time attempting to use vim and literally everything was hard.

    Ahh, Vim. It makes me happy to know that more seasoned developers than myself have issues with it as well.

  • by anotherevan on 7/17/15, 12:56 AM

    Hmmm, I run Q4TD[1] and now I’m thinking I should implement my own QOTD service…

    I wonder if I could do that with Google App Engine talking to the blog and just picking random posts.

    [1] http://q4td.blogspot.com/ http://www.twitter.com/q4td https://plus.google.com/u/0/110672212432591877153/posts http://www.facebook.com/quote4theday

  • by dec0dedab0de on 7/16/15, 2:55 PM

    Every time I look down the well known port numbers I imagine setting up a box with every protocol running.

    A bit of an aside, how many people still use plain netcat? I switched to ncat years ago, and haven't looked back.

  • by ajslater on 7/17/15, 11:31 PM

    No mention of finger, port 79.

    https://en.wikipedia.org/wiki/Finger_protocol

  • by vhost- on 7/16/15, 8:02 AM

    I suspect a few more implementations of these are going to spin up. I just did the qotd in Go: https://github.com/kyleterry/qotd

  • by dilap on 7/16/15, 5:00 AM

    The QOTD seems to just hang sometimes. Anyone have any guesses as to why?

  • by mml on 7/16/15, 5:07 PM

    someone should tell her about the fortune file :(