[MUD-Dev] Mud hosting services

[Ian Macintosh]

    > J C Lawrence wrote:
    > Sent: Friday, 19 November 1999 11:20
    >
    > There's been some discussion on the list previously of
    > establishing
    > fault tolerant protocols for server/client
    > communications where both
    > sides specifically knew what data they had to have at
    > any point (or
    > send thru and have confirmed receipt), and what they
    > could continue
    > acceptably without.
    >
    > The above however raises another possibility: The
    > transmitter (can
    > be client or server) monitors bandwidth conditions to
    > the receiver,
    > and tailors both its frame rate and the data content of
    > the streams
    > to suit.  Thus, transposing this into a video stream analogy,
    > players on fast connections would get get high frame
    > rates, players
    > on slow connections would get lower frame rates, and,
    > and this is
    > the clever bit, everybody would always receive all the
    > data their
    > end needed for logical correctness without that data
    > (often) having
    > to compete for bandwidth with other lower priority data
    > streams..

Sadly, the only system that supports that currently is Microsoft's
DirectX (to my knowledge).  It is UDP based, and you can check your
outbound buffer size, client bandwidth capabilities, send 'urgent
front of queue' messages, unimportant datagrams, important sequenced
or unsequenced, etc, etc.  VERY good implementation.  The sad thing is
both client and server must be a Win95/98 system at the moment, or
Win2000 when it hits release date.

But if you're looking for a good protocol to emulate, this would be
it.  I wrote a similar thing about 3 years ago for Delphi, also based
on UDP, but nowhere near as advanced.  Basically, I just wanted to mix
reliable and unreliable, and also 'profile' the connection stats a
bit.  TCP is not very well designed when it comes to lost packets I
think.  It has a tendancy to stall when that happens, and I tried to
overcome this by using the principle that if an acknowledgment for a
reliable packet hadn't got back to the sender by X time, just whack it
out again.  That's very TCP like, except I kept track of the 90%
failure rate timing, and anything that exceeded this time was assumed
to have failed.  I was at that time using an ISP who had a high packet
loss connection (via satelite from USA to New Zealand).  It was a bit
'unfriendly' to the net as I was sometimes re-sending too often, but
it tended to settle down into a stable condition after about 3 minutes
or so.  Again, the big problem with this was platform availability.

The simple way to do it for cross-platform availability would be to
use two sockets.  One TCP, one UDP.  Send stuff you can afford to
loose out via the UDP port, and important stuff via TCP.  Very simple,
but could improve your system performance quite a bit.  You could
probably glean an idea of the recipients bandwidth by seeing how long
it took to ack data back to you, but that would be a bit kludgy.

What I try to do with my designs is this.  I assume that someday, I
just possibly could have such a lovely bit of technology available,
and design my i/o stream object with a host of fancy capability
methods exposed.  Then I just take all that data, and shove it out via
a normal old TCP connection.  However, if such tech becomes available,
I just tune my object up a tad, and I get an immediate benefit without
having to restructure my whole system to make use of it.

Of course, hindsight is the only 20/20 vision I've ever had :-)   So I
sometimes miss seeing where I should be clever, and sometimes I get
clever where it's actually just making life complicated for me.

Regards,

Ian.




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev