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.<br><br>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. <br><br>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.<br><br><br><b><i>Dr Scofield

 <DrScofield@xyzzyxyzzy.net></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> interesting thoughts. question: would a channel be something like a <br>network bus?<br><br>    cheers<br>    dr scofield<br><br>Michael Wright wrote:<br>> I'm been thinking and prototyping about some improvements on the grid <br>> servers/protocols.<br>><br>> One of my aims is to try to separate the network code more from the <br>> logic code. So am thinking of what I'm calling a Channel and servlet <br>> system.<br>><br>> A servlet is just a class that performs some service. I'm thinking <br>> more in terms of breaking up the current servers into smaller <br>> services/servlets.<br>><br>> So then we have a collection of servlets that do the various functions <br>> that the current servers do (except I'm not including the asset server <br>> in this as think that is best

 kept to a proper REST resource based <br>> system).<br>><br>> Then we come to the channel, maybe this is a bad term for what I'm <br>> thinking, but anyway. The channel has two (or three) parts, the <br>> sender/receivers, which are responsible for the <br>> serialising/deserialising of the messages/datagrams, and also of <br>> sending it to the correct url. To find the url that a message should <br>> be sent to, the other part of the channel is responsible. I'm <br>> currently thinking of this as a basic central hash table service, that <br>> just keeps track of the servlets that are registered on that channel <br>> and the url of the endpoint that they are one. Of course the idea with <br>> the channel is to keep the code separate from the service logic, so <br>> how the servlet tracking is done is up to the implementation.<br>><br>>  While each servlet could actually have its own endpoint/channel <br>> receiver, I'm

 thinking more of a collection of them sharing a <br>> endpoint. So normally maybe only one endpoint per server instance.<br>><br>> So all a channel really is: Is a managed collection of known services <br>> and the url they can be reached at. Plus the code for de/serialising <br>> the messages in the format that channel uses.<br>><br>> The third component is the Router service. Each server instance would <br>> have one of these, that is tasked with routing the messages to and <br>> from the channel endpoint to the correct servlet.  A router could be <br>> connected to more than one channel.<br>><br>> Again a basic concept. The task is just to keep track of servlets in <br>> that instance, to know what channels they should be receiving messages <br>> from. To be able to route a message from a servlet to a channel; <br>> either a particular channel, or the servlet might just say any channel <br>> that has a particular type of

 service registered on it. Also the <br>> router should be able to do internal routing...from one servlet to <br>> another that is in the same instance.<br>><br>><br>> I'm also thinking that the region servers will have such a router and <br>> be registered on a channel(s). And then region modules could send and <br>> receive messages the same way.<br>><br>> My thoughts and actually my requirements for some other ideas. Is to <br>> have a dynamic modular system. That keeps the network code completely <br>> separate from the services logic. I really think that the current <br>> servers are too err monolithic and really group together a bunch of <br>> services that are separate. I don't mean they should always be on <br>> separate servers, just the code should be separated more and more <br>> modular.<br>><br>> So my thoughts are lots of smaller services/servlets. And once we do <br>> 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 <br>> I've done some prototyping of. Which is as the servlets and router <br>> classes have no network code in at all. Its a simple task to write <br>> different versions of the channel receivers/senders for say a ASP.net <br>> implementation.<br>><br>> There are still a number of things that need more thought. But thats a <br>> general overview of my ideas<br>><br>><br>> ------------------------------------------------------------------------<br>> Yahoo! for Good helps you make a difference <br>> <http: mailuk="" taglines="" isp="" control="" *http:="" us.rd.yahoo.com="" evt="51947/*http://uk.promotions.yahoo.com/forgood/"> <br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>>

 https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>   <br><br><br>-- <br>dr dirk husemann, mathmatics and computer science, ibm zurich research lab<br>SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/<br>RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/<br><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></http:></blockquote><br><p> 

      <hr size=1> 

Yahoo! for Good helps you <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=51947/*http://uk.promotions.yahoo.com/forgood/">make a difference</a>