Bruce Stephenson wrote:
>
> #2. I have been following the discussion re. bandwidth & making vnet
> massively multiuser. I wonder if this approach to massively multiuser
> voice chat might help. Clearly VNET has some additional requirements
> beyond voice chat, and multicast might help (speakfreely also supports
> multicast), but it seems that the architechture described below might
> well apply to vnet. Miriam suggested something similar when she
> mentioned having the clients act as a server in some capacities.
>
Multicast is not going to help if most of the users are on
high latency low bandwidth connections. The math just isn't
there. It's also a lot more complicated than a central server
setup.
If complicated is OK, and the idea it to support truly massive
multiuser worlds (10'000 - 1,000,000+), then VNet is a very
poor base to build on. Check sourceforge for some other solutions.
If complicated is bad, and the idea is to support pretty much
the people who were using VNet before, then keeping a central
server is important.
> http://www.peak.org/~stepheb/SFsite/specs/multiuser.html
>
I'm willing to be convinced, but my first impression is
that:
a) Most VNet sessions don't last nearly long enough for
that sort of dynamic network topology to stabilize.
b) Even if sessions did last for a long time, bandwidth
estimation doesn't work very well in practice. That's why
games like Quake have you specify an estimate when you
start. Based on other people's research, and my own
plaing around with alternate vnet code, the available
bandwidth between any two hosts over the internet varies
widely from second to second and minute to minute. So
the ad-hoc network is likely to be very brittle. There
are some articles about Quake that discuss this problem.
Downloading an FTP file, for example, is a bad way to
estimate because it confuses bandwidth and latency, and
latency is important for multiuser vr (and games :-)
c) I'd think the whole thing would fall apart the first
time a high bandwidth participant hung up. Or are all
high-bandwidth participants expected to donate all their
bandwidth permanently to the network?
d) Voice chat is a special case in that everybody is
supposed to get exactly the same information at aproximately
the same time. Multiuser VR isn't really like that. The
normal optimization is that nobody sees exactly the same
update stream.
But hey, some good test data will shut me up pronto. Is
there any available?
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
