This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

escape characters

Posted by Gohan_TheDragonball on Wed 31 Jan 2007 10:13 PM — 12 posts, 40,609 views.

Gohan_TheDragonball USA #0
Long ago I implemented the client speed snippet which allows my players to set the speed at which my mud will output to their client instead of the default 512k. However I was wondering if there would be a way to automate this process. I checked all the IAC stuff and found the DO TSPEED option, but I can't figure out what the escape character is and whether or not its supported by most clients like Zmud.

Basically what I want to do is figure out the connection speed of the descriptor and send the best possible speed to their client without them having to set it each time they login, especially since most of them are just confused by what I am telling them they can do in the first place.
David Haley USA #1
Does this actually make a difference? I mean, in this day and age, won't the excess stuff just get buffered up somewhere? If the connection can't accept stuff that fast, it'll just get buffered at the nearest hop to the client. Either way it seems to work out the same.

You might want to read the following document:
http://www.ietf.org/rfc/rfc1079.txt
It describes the motivation behind this telnet option. Unless you adapt your MUD to have "user interfaces that are tuned differently for fast and slow terminals".

If you're trying to optimize for network performance I'd be very interested to see some measurement data to justify the extra trouble; like showing that reducing send speed actually increases the throughput to the client or something like that. Or even just a motivation for why you think it might work even though you haven't done any tests.
Samson USA #2
I don't know if going to the trouble of individually negotiating the client speed is worth it, but I do know that when we bumped from 512 bytes to 4K per chunk, the mud just felt smoother. Subjective measurement I know, but the difference was that tangible.
David Haley USA #3
Well, that's a little different, I think; that has to do with how SMAUG handles networking. Once a socket is ready for writing, it keeps pounding away at it until the buffer is empty -- even if the socket becomes not-ready in the meantime. I suspect that reducing the buffer size helps with that because sending in smaller chunks on the server side helps prevent filling up the server-side buffers.

Still, I don't think that has anything to do with the client's bandwidth, really, and it's just a result of a more intelligent usage of the networking code on the server side. (Handling this aspect in a better way is one of the things my reworked networking code does, e.g. pausing if the socket becomes not-ready when writing.)
Gohan_TheDragonball USA #4
samson you posted that you just set the default to 4k chunks, the reason i was looking to do this was because it stated in the client speed snippet that a high rate being sent to a low connection would lag. one thing i didn't understand was who it lags, the user, or the server? did changing the default affect your low end speed users?
David Haley USA #5
It was probably a server-side effect, because the game blocks up while trying to send too much data. (See my post just before yours...)

I really am not sure why this is supposed to significantly affect client lag, because it'll just get buffered up somewhere along the packet route and resent if the client can't read it fast enough.



EDIT:
Furthermore, as I said, all this stuff -- the actual generation of packets -- is handled by the operating system, *not* the MUD. So any speed-up should be due to bad SMAUG server code being "helped".
Amended on Mon 05 Feb 2007 02:10 AM by David Haley
Gohan_TheDragonball USA #6
it doesn't affect lag really, but it definitely makes it appear more seemless in regards to muds that output a lot of data at any given time. I am starting to use the overland system, and at 512k it doesn't appear on the screen as quickly as when i pop over to 5120k due to the large map, and it is especially noticable when a player lets say runs 10 spaces left really quickly.

and i had one of my dialup players switch to the highest speed in the snippet and while it did lag his connection slightly, my connection was not affected. even though i was snooping him as well, the data meant for me and the data redirected to me from his login was much quicker compared to his.
David Haley USA #7
For the first point: that probably has to do with SMAUG's poor implementation of the networking code... it doesn't make good use of the socket library to do its work.

For the second point: that is to be expected, right? If he wasn't getting data fast enough to trigger the SMAUG problem, it would still get to him more slowly than to you, which is normal, no?
David Haley USA #8
I went into the SMAUGfuss code, and here is the culprit code:

   for( iStart = 0; iStart < length; iStart += nWrite )
   {
      nBlock = UMIN( length - iStart, 4096 );
      nWrite = send( d->descriptor, txt + iStart, nBlock, 0 ); 
      if( nWrite == -1 ) 
      {    
         iErr = errno;
         if( iErr == EWOULDBLOCK )
         {
            /*
             * This is a SPAMMY little bug error. I would suggest
             * not using it, but I've included it in case. -Orion
             *
             perror( "Write_to_descriptor: Send is blocking" );
             */
            nWrite = 0; 
            continue;
         }
         else
         {
            perror( "Write_to_descriptor" );
            return FALSE;
         }
      }    
   }


(The MCCP version is similar but with the MCCP stuff around it. I didn't paste it for clarity's sake.)

Note how, when it would block, it simply starts the loop all over again. Therefore, as soon as it hits a blocking point (because the OS tells it "that's enough"), it just keeps pounding until the OS is able to take the extra data.

However, if you only try to send less at a time, you are less likely to hit that saturation point, and therefore would not see these effects.

The fix to this is quite simple. The function needs to stop as soon as it would block, and leave the socket's data until the next network loop. It then needs to return a number, not a bool, indicating how much was actually written out so that the callers can know to appropriately update the descriptor's buffer size.

I will probably be writing a patch for this at some point in the near future which I will post to the SMAUGfuss forum; when I do that I will post a link here.

This is the real culprit behind the "network" lag, not any client speed issue.
Gohan_TheDragonball USA #9
maybe thats why my mud doesn't lag to everyone, because my write_to_descriptor code doesn't look like that.


bool write_to_descriptor( DESCRIPTOR_DATA *d, char *txt, int length )
{
    int iStart;
    int nWrite;
    int nBlock;

    if ( length <= 0 )
        length = strlen(txt);

    for ( iStart = 0; iStart < length; iStart += nWrite )
    {
        nBlock = UMIN( length - iStart, 4096 );
        if ( ( nWrite = send( d->descriptor, txt + iStart, nBlock, 0 ) ) < 0 )
            { perror( "Write_to_descriptor" ); return FALSE; }
    }

    return TRUE;
}
Gohan_TheDragonball USA #10
i looked at stock smaug and stock fuss, and that code you are using is fuss, and mine was from smaug.
David Haley USA #11
Oh. I see what your problem is. Again this has nothing to do with client speed and it's a server issue...

Here's the thing:
When writing to the client, if the buffer contains more than 4096 bytes (4k), it outputs 512 bytes at a time -- not 512k as you've been saying.

However, it only outputs 512 bytes, and then waits until the next network cycle to output more.

So of course if you are waiting for a lot of data, it will come slowly.

Increasing that amount (from 512 bytes to, say, 1k or 2k or 4k or whatever) means that the output is divided into less chunks therefore less network cycles therefore less time.

I do not know why they chose to divide into several passes if the data is more than 4k. The operating system takes care of that kind of stuff so there is no need for SMAUG to worry about it.

In any case, in this case increasing the number from 512 bytes is helpful not because of network speed, but because of this silly chunking issue.

So, a client speed snippet that actually set that amount to the client's speed -- even a slow modem has ~10k/s -- will help, but that has nothing to do with bandwidth and instead it's because of this chunking issue. See, it's all server side, and isn't related to the client.


(Incidentally, it is wrong for the SMAUG network code to not consider the blocking case, and instead boot people when there would be a block on their socket.)