HI, just thought i might throw in some experience from deepmatrix. IMHO Christopher is totally right. Additionally take the following into consideration. Most browsers redraw as soon as you update a single EventIn. ( I tested that ). However observing several EventOuts gives you several messages per frame. I.e. the user moving generates one position and one orientation update. if the users client is running at 10 frames/sec it generates 20 messages / sec. so the other clients have to deal with 20 messages /sec for that one user only. They would need to run at a frame rate of at least 20 frames / sec. In dm I solved it the following way. First I distinguished between VRML update messages and everything else such as chat or control messages. Then I used buffers for each client and at the outgoing side of the client, that are read by dedicated threads and pushed on the network. Only VRML updates ( by far the most ) go into these buffers. Moreover if an update message of the same type ( i.e. same receiver like avatar and same VRML field type ) is found in the buffer, it is replaced by the new one. This makes a lot of sense for continous updates like avatar position because then the other clients don't have to process updates that are allready superceded by newer one that are still stuck in the pipe. disadvantages are that the avatar motion may look jumpy but at least it is closer to the users position. also one has to be careful with scripting more complicated stuff that relies on trigger events etc. but so far i had no problem with this approach. all other messages are passed directly to the network, therefore the system can react faster to control messages and text is faster too. bye, Gerhard "Christopher K. St. John" wrote: > > 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 -- Gerhard Reitmayr mailto:[EMAIL PROTECTED] \\\ http://stop.at/gerhard L\\\\ DeepMatrix http://www.geometrek.com/products/ \\\\ I feel I am diagonally parked in a parallel universe
