[MUD-Dev] Mud hosting services
J C Lawrence
claw at cp.net
Fri Nov 19 17:28:28 New Zealand Daylight Time 1999
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
> 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
More information about the MUD-Dev