<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
I would say the right way is to <BR>
<BR>
1) create a sim-sim versioning scheme, so sims can refuse/negotiate comms on version numbering<BR>
<BR>
and<BR>
<BR>
2) Include an optional filtering in the grid service on version numbers - so that grids simply does not report neighbours with wrong sim-sim version scheme; which lets regions construct trusted and versioned maps transparently.<BR><BR>
We did something like #2 on tribal net to accomodate for the fast up/fast down scheme that is an integral part of it - offline or timed out regions were filtered out separately from being removed from database, to let regions disappear for a couple of hours without losing their 'spot'.<BR>
<BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR><BR>
> Date: Tue, 30 Dec 2008 16:33:29 +0000<BR>> From: jjustincc@googlemail.com<BR>> To: opensim-users@lists.berlios.de<BR>> Subject: Re: [Opensim-users] Consequences of vicinity<BR>> <BR>> Diva Canto wrote:<BR>> > Justin Clark-Casey wrote:<BR>> >> Is it worth updating the interface version number in OpenSim.Framework.Servers.VersionInfo to ensure that this is <BR>> >> enforced automatically for grids?<BR>> >><BR>> >> <BR>> > Yes, to some extent, but not completely. This is about sim-sim comms, <BR>> > not sim-grid comms. Therefore if you havion n ue a running sim connected to <BR>> > osgrid who's owner is on vacation, that sim will continue to run -- and <BR>> > maybe cause problems to the neighbors -- even if you bump up the version <BR>> > number in Servers. We would need to check the version number on <BR>> > inter-region comms, not just on region registration with the grid. Or <BR>> > else on region registration, the grid server should look into the <BR>> > VersionNumber of the potential neighbors and warn/disallow registrations <BR>> > when the version numbers are not compatible.<BR>> <BR>> In principle, a grid server that has been upgraded could, on restart, kick off regions that have an interface number <BR>> that is now too low. This would be for a grid administrator that wants to ensure a smooth inter-region experience on <BR>> the grid.<BR>> <BR>> In practice, a grid administrator might want to be more lenient (perhaps notification rather than kick).<BR>> <BR>> I guess you could have a grid that allows different clusters of regions where those regions use a different/old <BR>> interface than other region clusters on the grid, yet all clusters used the same grid comms. The problem of teleport <BR>> (in which you still travel between disconnected clusters) might require a different interface version than an interface <BR>> for neighbouring sims.<BR>> <BR>> Nonetheless, in practice people who don't read these lists will continue to put sims side by side. If the version <BR>> number isn't bumped we may well see an upsurge in questions and confusion which we saw not long ago when OpenSim <BR>> revisions crossed interface incompatibility thresholds (whether grid <-> sim or sim <-> sim).<BR>> <BR>> Perhaps this is something that grid admins can give input on. Do you think the interface version number should be <BR>> bumped with neighbour interface changes to stop people having problems when they are neighbouring regions with <BR>> incompatible versions? Or should people always be instructed to keep regions away from each other unless they are sure <BR>> that their neighbours are going to update in sync with themselves.<BR>> <BR>> -- <BR>> justincc<BR>> Justin Clark-Casey<BR>> http://justincc.wordpress.com<BR>> _______________________________________________<BR>> Opensim-users mailing list<BR>> Opensim-users@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-users<BR><BR></body>
</html>