I get the TCP-based one, as the service would still complete the connection handshake, send ACKs, etc - but the UDP one seems indistinguishable from simply dropping the packets.
Maybe back then the designers still expected that hosts would always reply to unwanted packets with an ICMP error, so silently dropped packets were expected to be rare and always indicators of a connection fault?
Though I guess we can proudly say today that UDP:9 is the most widely deployed service on the internet...
Yes, simpler times and such. And I get the feeling someone is about to discover RFC 864, which is even more fun (as in: a DDOS amplification vector of note, but this stuff actually was useful for a while...)
> When a datagram is received, an answering datagram is sent
containing a random number (between 0 and 512) of characters (the
data in the received datagram is ignored).
> The service only send one datagram in response to each received
datagram, so there is no concern about the service sending data
faster than the user can process it.
Oof...
Yeah apparently the idea that the "user" might not be the real sender wasn't yet well-known.
I get the TCP-based one, as the service would still complete the connection handshake, send ACKs, etc - but the UDP one seems indistinguishable from simply dropping the packets.
Maybe back then the designers still expected that hosts would always reply to unwanted packets with an ICMP error, so silently dropped packets were expected to be rare and always indicators of a connection fault?
Though I guess we can proudly say today that UDP:9 is the most widely deployed service on the internet...
Yes, simpler times and such. And I get the feeling someone is about to discover RFC 864, which is even more fun (as in: a DDOS amplification vector of note, but this stuff actually was useful for a while...)
https://www.rfc-editor.org/rfc/rfc864.html
> UDP Based Character Generator Service
> When a datagram is received, an answering datagram is sent containing a random number (between 0 and 512) of characters (the data in the received datagram is ignored).
> The service only send one datagram in response to each received datagram, so there is no concern about the service sending data faster than the user can process it.
Oof...
Yeah apparently the idea that the "user" might not be the real sender wasn't yet well-known.
Simpler times indeed.
/dev/null as a service.
The networked webscale database we've all been waiting for.
See also https://jyu.dev/blog/why-dev-null-is-an-acid-compliant-datab...