[Opensim-dev] Modifying the networking stack

[Mic Bowman]

and you might want to look at what we've already done for similar kinds of
message-based api's in the dispatcher code.
https://github.com/cmickeyb/scisim-addons (dispatcher and rcontrol
directories)

not intended for building visual clients... but useful for connecting
external programs.

--mic



On Thu, Nov 13, 2014 at 1:50 PM, Diva Canto <diva at metaverseink.com> wrote:

> What problem are you trying to solve? It's hard to comment without knowing
> what you want to achieve, but here are some random observations that you
> may want to take into account.
>
> As far as I remember, the reliable packets are a very small percentage of
> the UDP traffic at this point, so I'm not sure it's worth creating a
> dedicated TCP channel for them. Moving the HTTP traffic to the same TCP
> connection seems like a bad idea, as the HTTP traffic tends to be dominated
> by big data (textures, assets, etc) which would then get in the way of the
> small packets like AgentOnline, etc. I suspect it would make the client
> less responsive than what it is now.
>
> There is already support for WebSockets in OpenSim. It may not be
> complete, so I would encourage you to build on that. I am aware of WebGL
> clients that use WebSockets with OpenSim, and they have the same problem as
> described above: the big data gets in the way of the small packets, making
> the clients less responsive at points. But since WebGL is inevitable, your
> effort is probably best invested in this than in a TCP channel.
>
> Best,
> Diva
>
> On 11/13/2014 1:18 PM, Michael Heilmann wrote:
>
>> 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.
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141113/d776a8cb/attachment-0001.html>