Re: [MUD-Dev] Sockets

[Mark Gritter <mark#erdos,Stanford.EDU>]

Cynbe ru Taren writes:
> Efficient use of today's CPUs means applying that 98% idle time to
> do something useful for the user, not upping it to 99% idle time.

*grin*  You mean you're not running SETI@home?

> E.g., check out "A Review of Experiences with Reliable Multicast"
> at http://cs-tr.cs.cornell.edu/ and decide what the implications
> are for mud-dev:  Is reliable multicast appropriate?  Practical?
> Desirable?  Does it make it too easy for a single malicious
> participant to bring everything to a halt?  How much consistency
> between the views presented to different participants is required?
> Desirable?  Practical?  Possible?

I don't see multicast being all that useful for MUDs.  As a scalable 
bulk-distribution method, it's an efficient way of updating clients
(new version of the code, image cache preloading, etc.) especially if you 
use the "digital fountain" approach.  (See http://www.dfountain.com --- 
the Berkeley people who invented it have gone commercial...)

If MUDs start incorporating voice, it might be worthwhile to have 
"per-room" multicast groups to distribute the data, but it need not be
reliable.

But... for bandwidth-intensive applications, it's more likely the individiaul 
client bandwidth that's the problem, not the server.  Multicast doesn't
help the client at all.

Usually different players have different views of a situation.
In addition to just simple position, you might have invisibility, hidden
objects or characters, darkness, blindness, etc.  Sending out more data
than the client actually "sees" has security implications and increases
client load.

Finally, global multicast groups are likely to be expensive (if ever 
available), putting them out of consideration for most MUDs.  

(Incidentally, not all reliable multicast systems suffer from the "crying
baby problem" --- one bad/slow client bringing everything down.  Reliable
multicast algorithms can use subcasting, NAK fusion, or logging to deal
with these; note also that the consistency required by a MUD isn't all
that great--- lagging characters are just ignored.)

Mark Gritter
mark#erdos,stanford.edu


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