<div dir="ltr"><div>and you might want to look at what we've already done for similar kinds of message-based api's in the dispatcher code. <a href="https://github.com/cmickeyb/scisim-addons">https://github.com/cmickeyb/scisim-addons</a> (dispatcher and rcontrol directories)<div><br></div><div>not intended for building visual clients... but useful for connecting external programs.</div><div><br></div><div>--mic</div><div><br></div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 1:50 PM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best,<br>
Diva<span class="im HOEnZb"><br>
<br>
On 11/13/2014 1:18 PM, Michael Heilmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings everyone<br>
<br>
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.<br>
<br>
Idea 1:<br>
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<br>
<br>
idea 2:<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks.<br>
<br>
</blockquote>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-<u></u>bin/mailman/listinfo/opensim-<u></u>dev</a><br>
</div></div></blockquote></div><br></div>