stephen f white wrote:
> 
> just a thought i had while wandering around siggraph -- 
>

 Just to confirm, we're talking vnet-server-1.1b2?

 How about this:

 1) You can only send so many messages/second to a client
before you eventually exceed a) the client's ability to 
process the messages or b) the communication channel's
bandwidth.

 2) If you exceed that max number of messages/second then
messages start to build up in the operating system socket
buffers. These buffers are several kbytes (at least) and
thus can hold many position/orientation messages (which 
are small but relatively expensive to process, since they
require a screen update)

 3) Let's say you are really pounding the clients, and 
hundreds of messages have built up in the o/s buffers,
then somebody sends a text message.

 4) The text message will get to the server at some point,
and you will see a text message notification scroll by in
the server output.

 5) However, any slow clients (and with enough messages/sec,
all clients are slow) will not see that message until all 
the buffered-up position and orientation messages are flushed
and sent first. That can take many seconds if there are enough
messages buffered up.

 6) Although at first glance it appears the server throttles
the client down to 10 position/orientation messages per
second, it's actually 10/sec from each user. So it's easy
to imagine that 1 person running around might pose
no problem (since every client can handle 10 msg/sec) but 
as soon as one other person runs around (causing 20 msgs/sec)
every client overloads simultaneously, the o/s buffers fill
up, and there's a big lag in text messages. Of course, just
because it's plausible doesn't mean it actually happens that
way...

 A way to verify this would be to run a VnClientTest app and
watch to see exactly what messages are coming through from the
server. The hypothesis would be that although no text messages
are coming through, many pos/orient messages will continue to
be received during the "hang" periods. Adding a debug output to
WriterThread::sendMessage() would also probably be enlightening.


-cks

Reply via email to