John Stewart wrote:
>
> > Multicast doesn't help
>
> Except that with Multicast, a sender issues one packet, and
> it gets received by all (theoretically).
>
Yes, but the "theoretically" part is exactly the problem.
For VNet, you'd expect:
1) Most users connected over high latency low bandwidth
connections.
2) Some users connected over low latency high bandwidth
connections.
3) Most users will not be on the same local network.
4) Most users will not be a "real" multicast participant,
but will use reflectors that convertmulticasts
into singlecasts.
5) The server is expected to be on a low latency high
bandwidth connection.
The bottleneck is all the clients on slow connections,
not the server bandwidth. Which means that for the
expected case, multicast is not going to help.
If you expect different conditions to apply then the
optimal design would obviously change. I suspect that
you're making a different set of assumptions (at a guess:
everybody on relatively high bandwidth low latency
connections close to real mbone nodes)
> If, say, you have 10,000 clients; the amount of outgoing
> traffic from a server is then about 1/10,000 that of a
> unicast client/server model.
>
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.
Since client bandwidth is the bottleneck, the important
thing is to make sure that every byte to/from a client
is necessary. That means that the server needs to
individually tailor the packets sent to each client.
That's sort of the opposite of multicast.
The set-of-central-servers architecture is a way to
design around the latency/bandwidth problems. The
central-servers communicate with each other using
tools like multicast, and with the clients using
plain-old boring singlecast. The servers act as
proxies for the client, and map the world down to
meet the needs of the client.
But, obviously, the best architecture depends on
your assumptions about the environment VNet will
be running in...
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
