24 Mar, 2015, SlySven wrote in the 21st comment:
Votes: 0
{deleted}
24 Mar, 2015, SlySven wrote in the 22nd comment:
Votes: 0
Well all due respect Pymeus, alteraeon your MUD servers are located in a region of the World which probably gets by quite harmlessly in pure ASCII. Your players are not going to get annoyed by not being even capable of entering their Name into a game that insists on mangling it into something else! The Client I'm coding for at least ought to make a reasonable hash of rendering most European Scripts, or that's what I think Herr Khn, the named "author" (well it's his name we band about on the Splash Screen!) would want…

As for restriction what can be read and written, that isn't a Client's responsibility, rather it needs to make sure it passes (and parses if possible) accurately what goes between the Player and the Server - otherwise it is just a big oh that's nasty, I was going to put in the glyph at Unicode point U+1F4A9 but the forum truncated the message at that point {though I guess that IS one character that might need to be stomped to prevent abuse}! Anyhow, I think I'm deviating a bit too much here, other than to say there are plenty of glyphs out there, even beyond the BMP, that can be used in interesting ways in my opinion.
24 Mar, 2015, Scandum wrote in the 23rd comment:
Votes: 0
plamzi said:
Scandum said:
MCCP (zlib) handles broken packets, so it effectively eliminates unexpected packet fragmentation.


Care to elaborate on this part?

As I understand it zlib will eat data until it gets a finished block. The size of a block is supposedly 16K. I guess if the MUD sends more than 16K at a time there might be an issue, but this is compressed data, so with compression around 80% you'd have to send about 64K of data. I think that's more than most MUDs are willing to send at a time though I could be wrong.
25 Mar, 2015, Pymeus wrote in the 24th comment:
Votes: 0
SlySven said:
Well all due respect Pymeus, alteraeon your MUD servers are located in a region of the World which probably gets by quite harmlessly in pure ASCII. Your players are not going to get annoyed by not being even capable of entering their Name into a game that insists on mangling it into something else!

If you narrow your viewpoint to our specific situations, that's a reasonable assertion. OTOH, there are more than a few non-linguistic symbols in unicode, some of which I've thought might come in handy in a mud.
25 Mar, 2015, plamzi wrote in the 25th comment:
Votes: 0
Scandum said:
plamzi said:
Scandum said:
MCCP (zlib) handles broken packets, so it effectively eliminates unexpected packet fragmentation.


Care to elaborate on this part?

As I understand it zlib will eat data until it gets a finished block. The size of a block is supposedly 16K. I guess if the MUD sends more than 16K at a time there might be an issue, but this is compressed data, so with compression around 80% you'd have to send about 64K of data. I think that's more than most MUDs are willing to send at a time though I could be wrong.


That's my understanding as well. I think it will help lower the incidence of incomplete sequences, as I shared, but it's also my understanding that there's nothing you can do at the application level to prevent incomplete sequences, period. The only thing you can safely assume is that you will be receiving a stream of bytes in the order they were sent. So you will anyway have to have your smart buffer and run your checks at the end of every data chunk. At least, that has been my experience in the several clients I wrote (all of which support MCCP).

Here's a really dense read that I can't pretend to understand fully:
http://en.wikipedia.org/wiki/Maximum_tra...
25 Mar, 2015, quixadhal wrote in the 26th comment:
Votes: 0
A check for unicode sequences is exactly the same mechanism as the check for TELNET sequences. If you already have a TELNET stack that's watching the end of the buffer for incomplete negotiations, you can pretty much copy that code 99% verbatum to check for unicode sequences, if you're worried about it.
25 Mar, 2015, alteraeon wrote in the 27th comment:
Votes: 0
Quote
As I understand it zlib will eat data until it gets a finished block. The size of a block is supposedly 16K. I guess if the MUD sends more than 16K at a time there might be an issue, but this is compressed data, so with compression around 80% you'd have to send about 64K of data. I think that's more than most MUDs are willing to send at a time though I could be wrong.

This may be technically true, but it's a non-issue in a mud. No non-idiot implementor is going to save up 64k of socket output data before shipping it off to the compressor and network. A proper implementation will do the compression just before it sends the socket data, at the end of each slice. This means the compressed chunks are going to be small in the vast majority of cases, and will only reach the block size limit when there's socket flooding.

I honestly don't know why we're still talking about this. The packets will fragment and come in in chunks no matter what techniques you use. You will have to smart buffer and use a state machine to parse the utf-8 no matter what techniques you use. If you -aren't- doing these things, you're doing it wrong. It's pretty cut and dried. This isn't rocket science.

-dentin

Alter Aeon MUD
http://www.alteraeon.com
25 Mar, 2015, SlySven wrote in the 28th comment:
Votes: 0
dentin said:
…and use a state machine to parse the utf-8 no matter what techniques you use. If you -aren't- doing these things, you're doing it wrong…
yes, and stupidly that's still a big todo item for Mudlet AFAIK!
28 Mar, 2015, Scandum wrote in the 29th comment:
Votes: 0
alteraeon said:
Quote
As I understand it zlib will eat data until it gets a finished block. The size of a block is supposedly 16K. I guess if the MUD sends more than 16K at a time there might be an issue, but this is compressed data, so with compression around 80% you'd have to send about 64K of data. I think that's more than most MUDs are willing to send at a time though I could be wrong.

This may be technically true, but it's a non-issue in a mud. No non-idiot implementor is going to save up 64k of socket output data before shipping it off to the compressor and network. A proper implementation will do the compression just before it sends the socket data, at the end of each slice. This means the compressed chunks are going to be small in the vast majority of cases, and will only reach the block size limit when there's socket flooding.

I think you misunderstand, as long as the MUD sends less than 16K (compressed) at a time there should be no fragmentation as all the data will fit within one compression block.

As for alternatives, there is the EOR negotiation. Once negotiated the client can assume that any line that doesn't end with a linefeed or IAC EOR is fragmented. Some MUDs also use IAC GA for this purpose but EOR is better documented.
28 Mar, 2015, plamzi wrote in the 30th comment:
Votes: 0
Scandum said:
I think you misunderstand, as long as the MUD sends less than 16K (compressed) at a time there should be no fragmentation as all the data will fit within one compression block.


I don't know where you're getting "compression block". While it is certainly possible to close out the stream at the end of every data packet you are sending, that is not how MCCP works in any of the implementations I've seen. Probably because it adds significant processing overhead. What I have seen is a zlib stream that doesn't close out until one of the two sides decides to turn off MCCP.
28 Mar, 2015, alteraeon wrote in the 31st comment:
Votes: 0
Zlib has an internal block structure with IIRC a 16k block boundary. It's not actually relevant to any of the above topic, but that didn't stop it from being added.
20.0/31