[MUD-Dev] Mud hosting services

[J C Lawrence]

On Sat, 20 Nov 1999 05:10:09 +1300 
Ian Macintosh <iman at issystems.co.nz> wrote:

>> 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).  

That's hardly a surprise.

> 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.

We're talking about a couple thousand lines of code here really.
Nothing horrible.  An error correction layer atop UDP ala TCP, and
then a series of message abstractions as you describe with some
queue and fairness algorithms.

> 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.

Yup.  This was the level the last discussion of this area on the
list reached.

> 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.

Some stacks also allow retransmit stats to be extracted.

--
J C Lawrence                              Internet: claw at kanga.nu
----------(*)                            Internet: coder at kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


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