I've fired up a couple of nodes in case you are interested to play later - <br><a href="http://dht1.opensim.be">dht1.opensim.be</a> and <a href="http://dht2.opensim.be">dht2.opensim.be</a><br><br>If you want to start up yours - grab the stuff off <a href="http://opensim.be/bamboo-opensim.tgz">http://opensim.be/bamboo-opensim.tgz</a><br>
<br>then create a user "opendht", and untar this in its home directory (it creates the subdir "bamboo").<br><br>Then do "bamboo/planetlab/run-it" and you should be all set - you can check on the <a href="http://yourhost:5851/">http://yourhost:5851/</a> if it has joined the network.<br>
<br>Currently I've set the number of replicas to be 2 for the storage (so that I could service it with just the two hosts that I have) - in case there is interest and we get more hosts eventually, we should increase the number for resiliency (the target should be 8-9 or so).<br>
<br>/d<br><br><div class="gmail_quote">On Feb 10, 2008 7:00 PM, Brian Wolfe <<a href="mailto:brianw@terrabox.com">brianw@terrabox.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
openDHT looks interesting. :) I'll have to bookmark that for digging<br>through later.<br><div><div></div><div class="Wj3C7c"><br>On Sun, 2008-02-10 at 15:06 +0100, Dalien Talbot wrote:<br>> Why not to think about a code to register the region in OpenDHT, and<br>
> periodically update that ? ("last online")<br>><br>> This way not only this becomes quite scalable, but as well lays the<br>> foundation for the "everything connected" for the future...<br>
><br>> Grid-wide pings should not be that much of a problem if they are paced<br>> by the grid server, not by the sims - of course, with the increase of<br>> the regions the detection time will increase...<br>
><br>> I've looked and apparently the code for talking to opendht is in<br>> examples in XML-RPC.Net - so we should be able use it quite easily -<br>> and start pushing the "unscalable" structures/interactions onto the<br>
> OpenDHT ?<br>><br>> just a couple of cents.<br>><br>> /d<br>><br>><br>><br>> On Feb 10, 2008 9:10 AM, Stefan Andersson <<a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a>><br>
> wrote:<br>>         I would not say this is 'fatally flawed' just because it can<br>>         be the result of one clients connectivity problems; it's still<br>>         an indication that somebody somewhere had troubles reching the<br>
>         target. That's why it should only be seen as a ping trigger,<br>>         not as status authoritative.<br>><br>>         Also, it's not the client that reports on the trouble, it's<br>>         the source region - which means, that if the client can<br>
>         re-connect to the source region but not to the target, chances<br>>         are that there's something wrong with the target.<br>><br>>         If a grid server is the authority for say 6000 servers,<br>
>         frequent grid wide pings becomes quite the task, not to<br>>         mention the fact that the grid server itself can (and in an<br>>         heterogenous grid setting, will) experience connectivity<br>
>         problems, just as the client can.<br>><br>>         Best,<br>>         /Stefan<br>><br>><br>><br>>         ______________________________________________________________<br>><br>>         > Subject: RE: [Opensim-dev] region status tracking in<br>
>         GridServer<br>>         > From: <a href="mailto:brianw@terrabox.com">brianw@terrabox.com</a><br>>         > To: <a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a><br>>         > CC: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>         > Date: Sat, 9 Feb 2008 18:22:45 -0600<br>><br>><br>>         ><br>>         > Unfortunately this is fatally flawed since teleports can<br>>         fail due to<br>>         > internet routing issues taht affect only one person, amongst<br>
>         other<br>>         > movement failures that would cause the client to think a<br>>         region is<br>>         > offline vs the server knowing it's offline or online.<br>>         ><br>
>         > I'm posting a patch to mantis that lays the foundation for<br>>         regions beign<br>>         > online or offline and when they were last heard from by the<br>>         grid server.<br>
>         ><br>>         ><br>>         ><br>>         > On Sat, 2008-02-09 at 21:25 +0100, Stefan Andersson wrote:<br>>         > > Ok, I was to do some research before I replied on this<br>
>         thread, but off<br>>         > > the top of my head;<br>>         > ><br>>         > > first of all, we should define what we want the region<br>>         status data<br>>         > > for; the data should guide choice of implementation.<br>
>         > ><br>>         > > That said, there is quite a distinct possibility that we<br>>         can use the<br>>         > > _clients_ as our agents for detecting offline region<br>>         servers.<br>
>         > ><br>>         > > Whenever someone tries to teleport off a region, the<br>>         source region is<br>>         > > informed of this, to be able to downgrade avatar presence<br>
>         to child.<br>>         > ><br>>         > > If the teleport fails (the target region is unresponsive)<br>>         the<br>>         > > connection comes back to the region so it should upgrade<br>
>         the avatar<br>>         > > presence to root again.<br>>         > ><br>>         > > (Incidentally, I've filed a mantis on this, since we<br>>         actually don't<br>
>         > > handle that, and failed teleports results in you coming<br>>         back to a<br>>         > > region, but as a 'child' ie being stuck there and possibly<br>>         causing all<br>
>         > > kind of havoc with the ClientView)<br>>         > ><br>>         > > Now, if we handled the failed teleport correctly, this<br>>         could also<br>>         > > notify the grid service that a failed teleport has<br>
>         occurred.<br>>         > ><br>>         > > The grid service could then ping the target region, to<br>>         check on its<br>>         > > state.<br>>         > ><br>
>         > > This is an alternative or complement to grid-wide ping<br>>         sweeps; you<br>>         > > probably want both, but could do the sweeps much less<br>>         frequently.<br>>         > ><br>
>         > > Combine this with proper region signon/signoff and I say<br>>         you got<br>>         > > options.<br>>         > ><br>>         > > Best,<br>>         > > /Stefan<br>
>         > ><br>>         > ><br>>         > ><br>>         > ><br>>         ______________________________________________________________________<br>>         > ><br>>         > > > From: <a href="mailto:brianw@terrabox.com">brianw@terrabox.com</a><br>
>         > > > To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>>         > > > Date: Sat, 9 Feb 2008 12:56:10 -0600<br>>         > > > Subject: [Opensim-dev] region status tracking in<br>
>         GridServer<br>>         > > ><br>>         > > > After much IRC discussion I would like to make a couple<br>>         changes to<br>>         > > the<br>>         > > > regions table.<br>
>         > > ><br>>         > > > online bool NOT NULL deafult false<br>>         > > > last_seen int(11) NULL<br>>         > > ><br>>         > > > The online column would be updated as a region logs in<br>
>         and out of<br>>         > > > GridServers. This way an external management/status<br>>         application<br>>         > > doesn't<br>>         > > > have to pester the grid server for the full list of<br>
>         regions and<br>>         > > their<br>>         > > > status. This would also provide data to regions<br>>         requesting map<br>>         > > blocks as<br>>         > > > to the status of a region (a.ka. LL's Red Regions in the<br>
>         map view).<br>>         > > ><br>>         > > > The last_seen column would be of asistance to these same<br>>         management<br>>         > > apps<br>>         > > > in helping the administrator to determine which regions<br>
>         were long<br>>         > > term<br>>         > > > MIA or just plain not wanted anymore by walk away grid<br>>         members.<br>>         > > ><br>>         > > > My main concern is load placed on the grid server and<br>
>         having to ping<br>>         > > > regions by external applications having to probe every<br>>         region<br>>         > > currently<br>>         > > > to tell if it's still around or not.<br>
>         > > ><br>>         > > > To acomplish this i'm workign on a patch to implement<br>>         region_logout<br>>         > > > XMLRPC that would be called via<br>>         > > Region.Communications.DeregisterRegion<br>
>         > > > (which is currently empty).<br>>         > > ><br>>         > > > I woudl also add an update of RegionProfileData as each<br>>         RPC call si<br>>         > > made<br>
>         > > > by a region to GridManager. Database updates would only<br>>         happen<br>>         > > > periodicly as regions login and logout.<br>>         > > ><br>>         > > > Are there any objections or reasons not to implement<br>
>         this?<br>>         > > ><br>>         > > > _______________________________________________<br>>         > > > Opensim-dev mailing list<br>>         > > > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>         > > > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>         > ><br>>         ><br>><br>
><br>><br>>         _______________________________________________<br>>         Opensim-dev mailing list<br>>         <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>         <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>><br><br></div></div></blockquote></div><br>