[Opensim-dev] OGS 2 (or maybe 1.5) thoughts
Michael Wright
michaelwri22 at yahoo.co.uk
Fri Apr 4 21:58:19 UTC 2008
yup, I was thinking that there would be various call types. Some would want a response, some wouldn't of course, and some would want a response but it to be sent back as new message (so the calling service could continue on with whatever, and would just need to be registered to accept the return message types from the router service. )
Brian Wolfe <brianw at terrabox.com> wrote: It's a good way of cleanly seperating logic from location. The only
thing that you have to beware though is latecy of the calls. Some may
need to have a callback in order to return the calling thread control
until an answer can come back. ;-P
On Fri, 2008-04-04 at 18:09 +0100, Michael Wright wrote:
> yup you got it. I guess I did a really bad job of explaining what I
> meant. So I guess sometime I'll just commit some sample code. I'm not
> really thinking of anything complex (at least for now), just a way to
> separate all the network code from the rest of the code. So the
> "channel" is tasked with getting a message from one point to another,
> and as you said the calling code doesn't care how it does it.
>
> Brian Wolfe
wrote:
> AH, I think I get it now. :)
> Self defining transport interfaces.
>
> a service makes a call into the interface class, which then
> reads the
> configuration from the "channel" and the channel deals with
> creating
> whatever link level connection, encoding, and talking over
> that
> "channel". The supplier/consumer that is talking to the
> interface
> doesn't care if it goes over avian, udp, tcp, or http, or
> postal
> service. All it cares is that it posts and get's an answer
> back.
>
> Am I even close here?
>
> On Fri, 2008-04-04 at 13:19 +0100, Michael Wright wrote:
> > I guess in some ways it could be thought as a network bus,
> but I
> > wasn't thinking of the messages being broadcast on the
> channel, where
> > all endpoints had to listen to all messages and pick out the
> ones for
> > them. I was thinking, if anything, of more like a cut down
> web
> > services protocol stack.
> >
> > My prototype channel is just a basic HTTP based one. That
> just finds
> > where the url of the channel receiver, that the required
> servlet is
> > currently registered at, is. Then does a HTTP POST of the
> serialised
> > message to that url.
> >
> > But the implementation should be up to the channels. All the
> rest of
> > the system should care is that a channel can pass messages
> from one
> > end point to another, and can map some standard addressing
> scheme to
> > those endpoints. Allowing for a dynamic system, where the
> addressable
> > message receivers (the servlets) can move around the
> endpoints on a
> > channel as needed. And new endpoints can be added.
> >
> >
> > Dr Scofield wrote:
> > interesting thoughts. question: would a channel be something
> > like a
> > network bus?
> >
> > cheers
> > dr scofield
> >
> > Michael Wright wrote:
> > > I'm been thinking and prototyping about some improvements
> on
> > the grid
> > > servers/protocols.
> > >
> > > One of my aims is to try to separate the network code more
> > from the
> > > logic code. So am thinking of what I'm calling a Channel
> and
> > servlet
> > > system.
> > >
> > > A servlet is just a class that performs some service. I'm
> > thinking
> > > more in terms of breaking up the current servers into
> > smaller
> > > services/servlets.
> > >
> > > So then we have a collection of servlets that do the
> various
> > functions
> > > that the current servers do (except I'm not including the
> > asset server
> > > in this as think that is best kept to a proper REST
> resource
> > based
> > > system).
> > >
> > > Then we come to the channel, maybe this is a bad term for
> > what I'm
> > > thinking, but anyway. The channel has two (or three)
> parts,
> > the
> > > sender/receivers, which are responsible for the
> > > serialising/deserialising of the messages/datagrams, and
> > also of
> > > sending it to the correct url. To find the url that a
> > message should
> > > be sent to, the other part of the channel is responsible.
> > I'm
> > > currently thinking of this as a basic central hash table
> > service, that
> > > just keeps track of the servlets that are registered on
> that
> > channel
> > > and the url of the endpoint that they are one. Of course
> the
> > idea with
> > > the channel is to keep the code separate from the service
> > logic, so
> > > how the servlet tracking is done is up to the
> > implementation.
> > >
> > > While each servlet could actually have its own
> > endpoint/channel
> > > receiver, I'm thinking more of a collection of them
> sharing
> > a
> > > endpoint. So normally maybe only one endpoint per server
> > instance.
> > >
> > > So all a channel really is: Is a managed collection of
> known
> > services
> > > and the url they can be reached at. Plus the code for
> > de/serialising
> > > the messages in the format that channel uses.
> > >
> > > The third component is the Router service. Each server
> > instance would
> > > have one of these, that is tasked with routing the
> messages
> > to and
> > > from the channel endpoint to the correct servlet. A router
> > could be
> > > connected to more than one channel.
> > >
> > > Again a basic concept. The task is just to keep track of
> > servlets in
> > > that instance, to know what channels they should be
> > receiving messages
> > > from. To be able to route a message from a servlet to a
> > channel;
> > > either a particular channel, or the servlet might just say
> > any channel
> > > that has a particular type of service registered on it.
> Also
> > the
> > > router should be able to do internal routing...from one
> > servlet to
> > > another that is in the same instance.
> > >
> > >
> > > I'm also thinking that the region servers will have such a
> > router and
> > > be registered on a channel(s). And then region modules
> could
> > send and
> > > receive messages the same way.
> > >
> > > My thoughts and actually my requirements for some other
> > ideas. Is to
> > > have a dynamic modular system. That keeps the network code
> > completely
> > > separate from the services logic. I really think that the
> > current
> > > servers are too err monolithic and really group together a
> > bunch of
> > > services that are separate. I don't mean they should
> always
> > be on
> > > separate servers, just the code should be separated more
> and
> > more
> > > modular.
> > >
> > > So my thoughts are lots of smaller services/servlets. And
> > once we do
> > > that, it could lead to lots of url having to be kept track
> > of by each
> > > other servlet if we used the current approach. So thats
> why
> > I think
> > > the network code , including url management/tracking
> should
> > be
> > > completely separate.
> > > This also I think/hope could help with scaling things. In
> > that as the
> > > servlets can be grouped together as needed (and even moved
> > around the
> > > server instances). Then a very small grid might only want
> to
> > run one
> > > backend server instance that had all the servlets that it
> > needs
> > > running. While a much larger grid might have a server
> > instance for
> > > each servlet, and maybe more than one servlet of each type
> > running.
> > >
> > > Also its possible that we could use the same servlets in
> > standalone
> > > mode, as they would just use the internal routing function
> > of the
> > > routing service.
> > >
> > > Another benefit is it helps to make the whole thing more
> > customizable.
> > > In a number of different ways. One of those ways is
> > something that
> > > I've done some prototyping of. Which is as the servlets
> and
> > router
> > > classes have no network code in at all. Its a simple task
> to
> > write
> > > different versions of the channel receivers/senders for
> say
> > a ASP.net
> > > implementation.
> > >
> > > There are still a number of things that need more thought.
> > But thats a
> > > general overview of my ideas
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > > Yahoo! for Good helps you make a difference
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> >
> >
> > --
> > dr dirk husemann, mathmatics and computer science, ibm
> zurich
> > research lab
> > SL: dr scofield ---- drscofield at xyzzyxyzzy.net ----
> > http://xyzzyxyzzy.net/
> > RL: hud at zurich.ibm.com - +41 44 724 8573 -
> > http://www.zurich.ibm.com/~hud/
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> >
> >
> ______________________________________________________________________
> > Yahoo! for Good helps you make a difference
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ______________________________________________________________________
> Yahoo! for Good helps you make a difference
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
---------------------------------
Yahoo! for Good helps you make a difference
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080404/b3039ae1/attachment-0001.html>
More information about the Opensim-dev
mailing list