Mike Reddy wrote:
>
> > Traffic going out from the server is not a problem
> > in practice. It's the limited bandwidth of the clients
> > that's the problem under the above set of assumptions.
>
> I don't agree. When the server is answering 10,000 clients,
> we rapidly approach the limit where server lag affects
> client performance.
>
I suspect we're talking at cross-purposes. The current VNet
server is definitely limited by client bandwidth. I know
because I tested it :-) and Stephen rewrote some of the
network code based on the results[1]. That's why I said "in
practice" the client bandwidth is the bottleneck.
Rather than continue with the "in theory, a million user
VNet system would look like this" discussion, it might be
good to figure out some performance targets, and talk
about how to meet them.
My personal set of assumptions include:
1. Max of aproximately 10 full participants in any local
world. (20 maybe?) You can't really talk to more than
a few people at a time in any case, and with 100 users
even such simple things as the gui for the list of
participants gets ugly.
2. No more than a few seconds (2? 5?) delay between any
client sending a message and any other client seeing
that message on screen. Same goes for avatar gesture
messages and client join/leave messages.
3. No chat or gesture messages should be lost.
4. Movement messages are low priority (when chatting,
nobody moves around in any case).
5. Clients on 28k connections should be able to
participate. Clients on 56k connections are the
primary target.
6. No message filtering within a world. That means the
performance target includes all 10 people running
around chatting at once.
7. The world inter-connection thing seems like a very
good idea. An unlimited number of connections to
other, independent worlds seems cool.
8. Keep it simple, stupid. Very, very, very simple.
The only two things VNet has going for it are
that it's free, and really, really simple.
9. Keep it simple. (Yes, this one is in the list
twice :-)
> This actually happens in text only MUDs! One of the
> biggest killers is handling backlogs of client messages
> (which jeff has mentioned)
>
I certainly wouldn't argue that for MUDs, text messages
can eat up all the server bandwith :-)
But for VNet, the problem is server->client message
backlog in general, not text messages in particular. VNet
really needs a better way to estimate client lag, but
estimating client lag is a major pita. It requires some
fairly ugly changes to the networking code.
To sum up: this dicussion is about how to optimize the
communication between vnet clients. The current
bottlenecks are not well (enough) understood. Therefore we
are engaging in premature optimization. Premature
optimization is the root of all evil[2]. So this dicussion is
evil. QED. A solution to this evil is to get a good/better
characterization of the current system, and set concrete
performance goals for any nextgen system. Only after those
two things are done does it make any sense to continue
with a serious[3] discussion of performance optimizations.
[1] A single slow client used to slow all the
clients. Stephen[1a] fixed that, so slow clients no longer
interfere with fast clients. But slow clients still get
bogged down badly.
[1a] Everybody does realize that 99.99% of the code is
still Stephen's?
[2] Widely attributed to Knuth. Knuth said it, I believe
it, that settles it.
[3] OTOH, BS'ing is always fun and sometimes
productive. The danger is confusing BS with serious
dicussion.
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
