[Opensim-dev] OpenSim Comms

Diva Canto diva at metaverseink.com
Mon Dec 29 16:50:09 UTC 2008


MW wrote:
> I think we should use REST for most of the comms, but am a little bit 
> wary about if it will be the right choice for some of the region to 
> region comms. And if the overhead in lots of http requests/posts will 
> be too much, for messages like ChildAgentUpdate that we should be 
> sending quite often.
I have the same reservations as you on the particular case of 
ChildAgentUpdate. However, assuming the HTTP server is up to the task, 
sending over HTTP is an improvement over sending over Remoting, I think. 
Both are TCP-based, and Remoting has the additional overhead of using 
reflection for serialization/deserialization, which is not the case for 
the HTTP calls.
But we'll find out if this is an overhead or not when this is deployed.

> As for making comms a Region module, I'm +1 to that sort of idea. In 
> the past I have from time to time, gone through removing direct 
> references from scene, and region modules to the comms manager and 
> instead routing them through wrapper functions in 
> SceneCommunicationService. So that at some point we could refactor it 
> to remove the current comms manager and make SceneCommunicationService 
> into some sort of region module.
>
> I know that recently we have started taking the reverse course and 
> removing the wrapper function. Which also has its benefits as there 
> isn't much point in having the wrapper if we keep the comms manager as 
> it is.
>
>
> But anyway to answer your questions, if you have a REST 
> childagentUpdate working and its a improvement on what we have, then 
> I'd say that there shouldn't be any problem with replacing the old 
> method as the way to get it in the quickest.
>
> But I think we really should have some better method to do comms 
> plugin replacement/configuration in the future, weather that is by 
> having it as a region module, or just improving the current system. So 
> if you want to do that now, then I think that would be great.

Right now, I'm following Melanie's advice and implement this as region 
modules. Like this:

OpenSim/Region/Environment/Modules/Local
OpenSim/Region/Environment/Modules/REST

Then in OpenSim.ini we'll have

[Communications]

;InterregionComms = "LocalComms"
;InterregionComms = "RESTComms"

(RESTComms is implemented using LocalComms too)

This will help making the transition incremental without disturbing what 
already exists, and slowly making the existing Comms code dead.

I don't think this architecture is exactly right, for a number of 
reasons. Communications pertains to Regions, yes, but not to 
Region/Environment. And communications may be empty but should never be 
null, so the region module concept is not the best; it will be better to 
have interfaces and replaceable DLLs. Essentially, I think the current 
design OpenSim.Region.Communications.* is the right one, but needs some 
improvements. Probably we should have something like this:

OpenSim/Region/Communications/Interregion/Local
OpenSim/Region/Communications/Interregion/REST
OpenSim/Region/Communications/Interregion/<others>
OpenSim/Region/Communications/UserService/Local
OpenSim/Region/Communications/UserService/REST
...

And then

[Communications]

;InterregionComms = 
"OpenSim.Region.Communications.Interregion.LocalComms.dll"
;InterregionComms = 
"OpenSim.Region.Communications.Interregion.RESTComms.dll"
;UserServiceComms = 
"OpenSim.Region.Communications.UserService.LocalComms.dll"
...

But for now, I'm going with region modules, just to make it work without 
interfering with the existing Comms, and to study the best manner of 
componentizing this whole thing.




More information about the Opensim-dev mailing list