My mud implements RFCs 854,855,857,858,1073,1091,1129 and 1143.
Neener neener

I am pretty sure it was meant as the correct line end, not just correct as in valid data to send.

Yes, those all are valid output, however, they all have different meaning and only one is a valid line
end. Quixadhal posted a link to the standard, and even quoted the relevant part dealing with line ends
and \r.
To summarize:
\n\r is totally invalid in the standard.
\r\n is the proper way to send a line end
\r\0 is the way to send a lone CR - on a compliant client, this will return to the start of the line without
dropping down a line.
\n sends just a line feed - on a compliant client, this will drop down a line, but NOT return to the start
of the line. I have been on MUDs that used just this and it is NOT pretty.

Only on Windows. On Linux it's a valid line feed, and that's what decent terminal emulators support, including the Win XP command terminal. So it's TELNET vs VT100, if you send color codes you might as well use "\n" because the terminal will know what to do with both.


I think that deep inside you secretly wish to implement Scandum's Compression Protocol, on an empty line alone you reach a compression ratio of 50%!

I accept Scandum's Compression Protocol from the client. I don't send it though. ;-)

Awesome, how about we pick an arbitrary number, 98, and turn it into a telnet negotiation? For example:

Client: IAC WILL SCP
Server: IAC DO SCP

On a serious note, I assume it are mud clients sending a single \n ?

MUD clients should all be sending the telnet standard line ending, \r\n. Those that are not are broken telnet clients. In fact, I suspect that many actually do, because of all the line endings that show up in room descriptions.

Of course they're broken (mud clients), but I follow Postel's principle.

"TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others." - Jon Postel

You have to READ the standard to understand it. TELNET is a protocol for network communication. It has been designed so that all parties that implement the standard will understand what is being communicated. It does NOT have anything to do with your particular terminal type, your OS preferences, or anything else outside the network connection.

If you are using TELNET, and you send "\n", the result is supposed to be "line feed", regardless of what your terminal or OS wants to do with it. Said client has to then translate that into the appropriate behavior for your terminal, which might very well be "ESC

You have to READ the standard to understand it. TELNET is a protocol for network communication. It has been designed so that all parties that implement the standard will understand what is being communicated. It does NOT have anything to do with your particular terminal type, your OS preferences, or anything else outside the network connection.

If you are using TELNET, and you send "\n", the result is supposed to be "line feed", regardless of what your terminal or OS wants to do with it. Said client has to then translate that into the appropriate behavior for your terminal, which might very well be "ESC[D" (cursor down).

That's the point. That's why there IS a standard, so when you implement ScandumOS that uses the symbol "turkey-boy!" as the end-of-line delimiter, a proper telnet client written for ScandumOS will translate the horrible "\r\n" symbol correctly, and will also correctly make "turkey-boy!" emit "\r\n" so other, less enlightened OS users, know it means "end-of-line".

I have to wonder…. what's all this telnet talk got to do with extended bitvectors? :)

We aren't talking about implementing extended bitvectors in the telnet server? ;)

That's my fault for using it as a comparison a page up from here. I think we can officially add telnet line endings to the list of thread killers that including nazi's and elvis.

Speaking of standards, we wouldn't even be arguing about this if Multics hadn't decided to violate the ASCII-68 standards in the first place. Incidently for the same reason this proposed ScandumOS does. ;-P

We're talking about TELNET, not Windows or Linux.. TELNET is a specific transmission protocol independent of the underlying OS and with some limited independence of the underlying terminal type. A "correct" client would translate \r\n into just \n on terminals that expect just \n for newlines, just like they would convert \r\0 into just \r. Graphical clients generally don't use a pseudo-terminal so they implement these things by hand, rendering the behavior of the underlying OS moot.




You would need to select an option code to support negotiation of the feature. Or use terminal type detection (rfc 1143) and just note which ones support \n as \r\n (and be wary of the common ones like VT100, as many clients will lie and claim to be VT100-compatible when they're really not).

Also, I have ask Tyche: what the hell does your MUD need to implement NTP for?

You're not quite following me, but that's okay.

The point I'm trying to make is that when it comes down to things mud client interaction is ungoverned by protocol, (it's just a raw socket connection), so stressing a particular protocol as the golden standard is ridiculous. As a developer you can use the VT100 and TELNET protocols to get some stuff done with telnet clients, but pretty much every mud client is going to choke on a decent telnet / vt100 implementation. Like I said earlier, stressing \r\n is cherry picking, unless you implement most of the specs like Tyche, but the generic response to that is 'wtf?'.

I vote for everybody sending seemingly random characters to clients and assume that the clients implement pattern detection algorithms to eventually piece apart the hidden order, and deduce which characters to display. Who needs this standards stuff.

I don't. And I have no idea why I've got 1129 listed in the code comments. It's been awhile.

As an Old Fart (TM), I reject your foolish assertion that MUD's don't use the TELNET protocol. That's because when they were coded, there were no custom clients… they were written specifically to interact with the telnet client programs, which were available and widely used by just about every mainframe and workstation in academia.

Now, if you're going to write something that's supposed to talk to a program that WILL be using the TELNET protocol, doesn't it make sense to… I dunno… at least TRY to use the protocol that you EXPECT the other end to be using? :stare:

Of course, if you're writing your own new server, you are free to reject that idea and use whatever you want. I'd probably choose a custom client with UDP packets, as it's easier to scale up, and is good practice if you go into graphical game design. But then, you might want to call it something other than a MUD, since to most people, that means a multi-user text game that you use TELNET to connect to.

I vote we just send numbers. Everyone seems to want numbers, so just send the ASCII codes of whatever text you want to display as text and let the client reassemble it however it wants. Here, I'll give you some code to use:

void output_me(CHAR_DATA *ch, const char *s)
{
  char buf[MAX_STRING_LENGTH];

  *buf='\0';
  for(int i=0; i< strlen(s); i++)
  {
    sprintf(buf,"%02x",s[i]);
  }
  send_to_char(buf,ch);
}

:evil:

Yeah, the telnet interaction of AberMUD was mind blowing. Good old times.