[Opensim-dev] Modifying the networking stack

[Michael Heilmann]

Greetings everyone

I and another MOSES developer are going to be looking at the 
client/server network stack, as well as the processing queue's used for 
incoming and outgoing packets.  I am going to see if I can implement a 
client stack on opensim and firestorm that uses the traditional TCP/UDP 
pairing for this type of client<->server relationship.  I have two 
thoughts, but I am interested in hearing if you have ideas or insight 
into this particular space.

Idea 1:
     Add a dedicated tcp port next to the UDP port, and move reliable 
transport transmissions to the tcp port.  I am uncomfortable increasing 
the required ports for each region, but the http server is in the way.  
I can look to move all communications from http to a tcp socket-server 
type of deployment, at the expense of simple POST/GET operations

idea 2:
     Look into increasing the performance of the http server of the 
regions, as well as testing/implementing a full websockets 
implementation, and using the websockets upgrade for consistent client 
connections.  This could eventually lead to javascript-based clients, 
and does not remove http functionality.

Either idea would see any traffic requiring reliable transport shifted 
off of the current UDP stack, and onto the tcp reliable transport.  
Either idea also will require modifications to a client to match.  I, 
and another developer here, would be developing the client code, the 
region code, and testing against a MOSES deployment.  As we are MOSES 
developers, we would be working against simian instead of Robust; so 
there would be a gap for regular Robust-based grids.

If you could lend me your opinions about these ideas, the management 
queues, associated problems in opensim, etc, I would really appreciate 
it.  We would be working completely in the open on github, and obeying 
all licensing.  We would welcome any and all cooperation, and we will 
cooperate ourselves wherever we are welcome, but we are not interested 
in avoiding positive changes to maintain SecondLife compatibility.

Thanks.

-- 
Michael Heilmann
Research Associate
Institute for Simulation and Training
University of Central Florida