Yes, this is missing the "pressure" part of "backpressure", where the recipient is able to signal to the producer that they should slow down or stop producing messages. Observability is useful, sure, but it's not the same as backpressure.
Sending message to a process has a cost (for purposes of preemption) relative to the current size of receiver's mailbox, so the sender will get preempted earlier. This isn't perfect, but it is something.
HTML is actually a dialect of SGML. XHTML was an attempt to move to an XML-based foundation, but XML's strictness in parsing worked against it, and eventually folks just standardized how HTML parsers should interpret ill-formed HTML instead.
Ah good to know. It’s interesting (to me) how similar they look to each other but you and other commentators below mention how they’re more like distant cousins
They're so good I don't feel it much either :) They're all SSL, but streamers and pros are seeing it big time. And just as it was regaining popularity. They're adding EAC soon, claiming it will help. It won't, not even a little.
> room designated was meadows and you could find herbs which would replenish over time
I'm sure several MUDs did this, but, this sounds an awful lot like my home MUD of Achaea, which started in ~1997, still exists (healthily!), and has this exact system :)
I agree in principle, but actually, according to the netcat website [0]:
> If netcat is compiled with -DTELNET, the -t argument enables it to respond to telnet option negotiation [always in the negative, i.e. DONT or WONT]. This allows it to connect to a telnetd and get past the initial negotiation far enough to get a login prompt from the server. Since this feature has the potential to modify the data stream, it is not enabled by default. You have to understand why you might need this and turn on the #define yourself.
So it supports enough to tell others that it doesn't support it. That's more than I expected, but still don't serves me when I actually want to use telnet.
The difference between "telnet" the program and "telnet" the protocol is especially important in this discussion, I think.
A more "proper" tool for that is netcat -- I doubt SMTP supports the Telnet option negotiations subsystem. (I also doubt SMTP servers can interpret the full suite of Network Virtual Terminal (NVT) commands that the Telnet protocol supports.) There's clearly enough similarity between the two protocols that if you're just using it to transfer plaintext it will probably work out fine, but they are distinct protocols.
> Someone upstream of a significant chunk of the internet’s transit infrastructure apparently decided telnet traffic isn’t worth carrying anymore. That’s probably the right call.
Does this impact traffic for MUDs at all? I know several MUDs operate on nonstandard Telnet ports, but many still allow connection on port 23. Does this block end-to-end Telnet traffic, or does it only block attempts to access Telnet services on the backbone relays themselves?
MUDs use plaintext TCP protocols that are accessible to a wide range of clients.
The Telnet protocol is well-defined and not completely plaintext. There are in-band signaling methods and negotiations. Telnet is defined to live on 23/tcp as an IANA well-known, privileged, reserved port.
MUDs do none of this. You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.
The fact that MUDs inhabit higher 4-digit ports is an artifact from their beginnings as unprivileged, user-run servers without a standardized protocol or an assigned “well-known port” presence. If you want your MUD to be particularly inaccessible, you could certainly run on port 23 now!
As a MUD enthusiast of two decades, this is not accurate. Where are you getting this information?
Most MUDs implement RFC 854, and a number of non-standard Telnet option subnegotiation protocols have been adopted for compression (MCCP2), transmission of unrendered data (ATCP, GMCP, ZMP), and even a mechanism for enabling marking up the normal content using XML-style tags (MXP). These telopts build on the subnegotiation facility in standard Telnet, whose designers knew that the base protocol would be insufficient for many needs; there are a great number of IANA-controlled and standardized telopt codes that demonstrate this, and the MUD community has developed extensions using that same mechanism.
> You can usually connect to a MUD using a Telnet client, but most players hate the experience and often deride this method in favor of a dedicated, programmable client.
I think you are confusing "telnet" the program with "telnet" the protocol. I am speaking here of the protocol, defined at base in RFC 854, for which "telnet" the program is but one particularly common implementation. You look at any of those "dedicated, programmable clients" and they will contain an implementation of RFC 854, probably also an implementation of RFC 1143 (which nails down the rules of subnegotiation in order to prevent negotiation loops), and an implementation of the RFCs for several standard telopts as well as non-standardized MUD community telopts. I can speak for the behavior of MUSHclient in especial regard here, though I am also familiar with the underlying Telnet nature of Mudlet, ZMud, and CMUD, not to mention my very own custom-made prototype client for which I very much needed to implement Telnet as described above.
Yes, perhaps we should define “MUD” and your incomplete experience of “most”.
As a MUD enthusiast for 37 years, I learned to program in C and Unix through TinyMUD, MUCK, and MUSH derived servers. From the beginning, none of these codebases implemted Telnet. There was nothing but a raw transparent TCP connection. In fact, I facilitated the introduction of a grand innovation: the "port concentrator" system which multiplexed TCP connections. Unix processes had a hard rlimit of 64 file descriptors, which crimped our style as an emerging MMORPG. The multiplexer increased this to 4096, for the biggest games of the era.
You mention MUSHclient, and I do not know about later revisions of the TinyMUSH server, but I can assure you that every MUSH I found from Larry Foard on, was not implementing Telnet. (I was privileged to help Larry "test" new features as I red-teamed his server with bizarre edge cases!)
Likewise, after I handed off TinyMUCK 2.3 to the furries, it was not doing the Telnet protocol. When we backported stuff to MUCK 1.x, it was not doing Telnet. I wrote a bonkers Perl program to read MUCK databases and sort of implement the game. No Telnet there. I've got to wonder whether the Ubermud or MOO guys had folded it in; they were close collaborators with us, back in the day.
Now as for the Diku, LP, and other “combat” type games, I’ve no idea. Perhaps they did. We never cared. I was aware that some of them had a pesky “prompt” that violated the line-mode assumptions of conventional clients and needed workarounds.
telnet(1), the program, was historically the only program that implemented the protocol. If you use Tinyfugue or Tinywar or tinymud.el, they are not, and no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.
It wouldn’t have been difficult to retrofit the Telnet RFC 854 into any MUD server, but none of us wizards had any use for it, seeing that our clients were mature and capable of much more processing without it.
If modern MUD servers have mostly implemented Telnet, then that is cool, but what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!
The modern MUSH forks do generally support telnet, but yes -- as a 29 year old who's been pathologically obsessed with "MUD archeology" off and on, I'll confirm -- historically, most MUDs did not do any sort of Telnet negotiation.
Further, most older clients did not anticipate any kind of Telnet negotiation from the server, and will print garbage to the screen if connecting to modern MUSHes that do. (I've tested tinywar, vt, and that one VMS client...)
MUCKs never, to my knowledge, implemented telnet, though. They barely support ANSI escapes, nevermind Telnet. :-)
> [...] no, I am not confused, because I was giving an example of why the Telnet-implementation, the program, the client, was so inadequate for playing on MUD servers.
Then this is at the heart of our disconnect, because the post of mine that you originally replied to --- as well as, unless I drastically misread, the original article under discussion --- was concerned with traffic on port 23, the Telnet protocol port, and not with any particular implementation communicating on that port. The concern of my original comment was that this might affect MUDs that operate on port 23. Perhaps you can understand my confusion when you reply stating categorically that most MUDs do not use "Telnet" (meaning the program), when that wasn't really what was at concern (and therefore implied that my question had no basis).
It is a true fact that many MUDs operate on port 23. Many do not, but you can skim a MUD aggregator like MudConnect [0] to see that it is quite common. Aardwolf, Discworld MUD, and the IRE games --- which consistently topped TopMudSites (when that aggregator was still running, anyway) all operate on 23, potentially in addition to an unreserved port.
> what surprises me is that it is mandatory, and your clients don’t seem to interoperate without it? That is a strange reversal!
All telopts are disabled by default, per Telnet RFC; the only things you must absolutely parse under the RFC are the standard complement of NVT commands (such as IAC GA "Go Ahead"), even if they are otherwise implemented as no-ops.
Any input stream with the high bit clear is treated as pure data -- with the incidental exception of bare `\r`, which must always be followed either by `\n` or by `\0`; but Postel's Law has turned that into more of a guideline. So as long as the standard NVT encoding is assumed (which is just 7-bit ASCII) and the NVT core escape sequences are avoided, a modern Telnet-based MUD client can interoperate with a plaintext MUD server without issue. (As you know, this is also why people get away with using `telnet` (the program) to access HTTP and SMTP services instead of using something like netcat.)
Some MUD clients will eagerly send IAC DO / IAC WILL subnegotiations, but general practice is to let the server offer first -- probably precisely to ensure compatibility with MUDs that don't implement Telnet subnegotiations.
> Now as for the Diku, LP, and other “combat” type games, I’ve no idea
Diku-family MUDs are certainly the ones I have the most experience with. I understand LP MUDs also generally have Telnet support; or at least, I recall seeing a patch for them that MUD owners often sought to apply to their games.
Wouldn't that imply that >80% of all monitored telnet sessions were exploit attempts for the specific CVE in question? Even with the scale of modern botnets, that seems unrealistic for a single vuln that was undisclosed at the time.
I'd just like to invoke the principle to "not judge a book by its cover".
The article here is very well written and does a great job of conveying the perspectives and opinions of many parties. I would recommend reading the article in spite of its headline.
reply