17:11] <MW__> MingChen looks good, although I would rather avoid going down the route of sandbox mode running exactly the same servers as grid mode and using http etc for communications between them
[17:11] <MW__> would rather it be like the current user server is, based on the same class but overriding methods when needed (ie for network comms)
[17:12] <MW__> also this isn't directly related to that Proposal, but I do think we should most likely call sandbox mode something else, more like standalone mode, sandbox sounds too narrow
[17:14] <MingChen> the porblem of running different servers is the apparent issues -- someone implements something in only grid mode and not in sandbox or a bug appears in only one mode and isnt discovered until someone works on getting it to work.
[17:15] <MW__> well as said if we have the same base classes, just overridding the methods that deal with comms (so grid uses http and standalone uses whatever) then there should be that problem
[17:16] <MW__> my personal opinion is in the end that standalone will be used a lot more than grid, personally I see there being thousand + of small "grids" that are single standalone instances(now standalone can nearly as many regions as we like), basically like websites.
[17:20] <MingChen> yes, sandbox mode will probably be used more often, but we cant ignore the other mode. I mean, Sugilite was a complete rewrite of sandbox mode, but grid mode was still a hack-n-slash 0.2 that now works, but barely with sugilite. It doesnt have to be done specifically the way Im outlining it, but in the long run we need to either decide to drop grid mode, or make it more sustainable.
[17:21] <MW__> yeah well I agree grid mode is hack n slash, but thats because we really need a rewriten OGS protocol
[17:22] <dalien> MW: and why do you think http-based comms with loopback would be a bad idea for the sandbox mode ?
[17:24] <MW__> I'm not saying its a totally bad idea, just don't think it is the best way and to be honest don't really see the reason for going down that route, if we write the servers with abstract interfaces/methods for comms, that it should simple be a case of changing those methods for each mode. the rest of the code (the logic etc) stays the same,
[17:25] <MingChen> MW__: thats basically how we have it now and today alone we have sandbox mode crashing with an exception and the gridserver in grid mode crashing after its restarted and something connects to it.
[17:25] <dalien> more loose coupling ? since then the demarcation would happen not at the server object point, but at the network point...
[17:25] <MW__> don't really see a reason for going with loopback http when we don't have to (shouldn't be much extra work to implement the methods for each mode)
[17:26] <MW__> well thats just my personal opinion, I would rather deal with those issue than to do a hack and use loopback
[17:27] <MingChen> if we just do http with a loopback, it will work the same in grid mode and sandbox mode. So, you dont have a fancy way of saying "sandbox mode? just call this function. grid mode? send an XMLRPC request!"
[17:31] <MW__> btw your point about the gridserver crashing in grid mode
[17:31] <MW__> well if we went with using the same servers in each mode then its very likely sandbox mode would crash too, but even if we go the http route with the other servers I really strongly would be against it with the grid server, in sandbox mode we can use the fact that we are in sandbox mode to get a lot better performance and the grid server functions do have a effect on a lot of things (like teleporting and border crossing)
[17:33] <dalien> which would be a natural incentive to improve that performance?
[17:34] <MW__> smoother border crossings, faster teleporting , anything related to inter region stuff
[17:34] <AdamZaius> Hrrm
[17:34] <AdamZaius> It does strike me that we can use local crossings though
[17:34] <AdamZaius> In both grid & sandbox mode.
[17:34] <dalien> border crossin = multiple sims ?
[17:34] <AdamZaius> After all - if it's in the same instance, why not?
[17:34] <MW__> Adam, yeah we are doing that
[17:35] <MW__> basically there should be no actual grid server in sandbox mode as the local manager takes care of it, in grid mode the local manager will deal with the stuff it can, ie for other regions in the same instance, else will use the grid server
[17:35] <MW__> so what I'm saying is there is no point in adding that same grid server to sandbox mode
[17:36] <dalien> hmmm dunno. I'm not strong on either approach, but it's a bit against the occam's razor, imho. anyway i do not have enough knowledge to have a strong argument there :)
[17:37] <MingChen> then why dont we just trash grid mode since it has apparently lack of importance?
[17:37] <MW__> the asset server I have no problems with that using http
[17:37] <MW__> in both modes
[17:37] <dalien> hm well, I'd like to be able to e.g. authenticate against external server
[17:37] <dalien> and store the assets externally :)
[17:37] <MW__> yeah we want to keep grid mode
[17:37] <MingChen> then why are we ignoring it?
[17:37] <MingChen> if we are going to have it, it needs equal attention as standalone mode
[17:38] <MingChen> not a "patched together hack to make it work over multiple computers"
[17:38] <dalien> i'd say the loopback comms should be quite fast.
[17:38] <MW__> we aren't its just not a area that personally I work on too much, but it doesn't mean that other people can't , basically at the moment it really really needs a new OGS protocol and no one has done that yet
[17:39] <MW__> I work on the region server mainly, I try to make everything so it will work in grid and sandbox but well its easiest to test in sandbox and two we really need a decent OGS protocol
[17:39] <MingChen> yes, a new protocol would help, but wouldnt solve the problem
[17:40] <AdamZaius> Yes, verymuch a decent OGS protocol.
[17:41] <MW__> its hard to get things working in grid mode due to the current procotol, like with inter sim comms at the moment, I'm not sure how the current protocol is meant to send the information it needs to the regions (like where the other regions .net remoting ports are to be found)
[17:45] <MW__> as said I have no problems with asset server using http and be exactly the same for both modes
[17:45] <MW__> the user server well currently they share the same base class with the same logic, but just different comms code (which to me seems fine)
[17:45] <MW__> IM server, well really sandbox mode shouldn't need a separate one as we should be dealing with inter region ims in a single instance for both modes
[17:45] <MW__> , grid server, well as said I don't think sandbox really needs one as they will both have local management code in the instance and that should be enough for sandbox (so they share exactly the same local code, there is just no external server in sandbox mode)
[17:46] <MingChen> that is what is confusing me
[17:46] <MW__> what part?
[17:46] <MingChen> the no grid server in standalone mode
[17:47] <MingChen> the local management code is...basically...a makeshift grid server
[17:47] <MingChen> it does the exact same thing as a remote grid server, just fused into opensim
[17:48] <MingChen> we may not have to do http in standalone mode, still havent worked that part out
[17:49] <MW__> well the grid server job is basically to tell each region about other regions, but as planned there should be local management code that deals with other regions in the same instance so that everything doesn't have to go through the grid server, why get the grid server involved when there is no need,
[17:49] <MW__> so yes it does a lot of the jobs of the remote grid server but it only does it for the regions in that intsance, it is pointless for the remote grid server to have to do everything if the regions that are involved are in the same instance.
[17:50] <MW__> but why in grid mode, have a remote grid server that could be anywhere on the planet , do stuff for two regions that are in the same instance?
[17:50] <MingChen> thats a good point
[17:50] <MW__> why not have that code in that instance so that the load on the remote grid server is kept down
[17:50] <MingChen> when getting info on a region, check first to see if its in the same instance
[17:50] <dalien> hm so basically two-tier grid server ?
[17:51] <MW__> MingChen exactly
[17:51] <MingChen> if not, resort to the grid server
[17:51] <MW__> and thats what I'm saying as in sandbox mode all regions are in the same instance, no need for the remote grid server
[17:51] <dalien> hmmm developing that idea further, hierarchical grid servers ?
[17:51] <dalien> so the standalone grid server might have a similar arch
[17:52] <dalien> something with the similar idea as DNS
[17:52] <dalien> although might not work all that well since the sims would not be colocated with the same grid server
[17:53] <MingChen> I see what you mean MW__, and I think I see what is happening here.
[17:54] <MingChen> Regardless of mode, there is going to be a local manager of all the regions for quick checking
[17:54] <AdamZaius> Yep.
[17:54] <MingChen> in standalone mode, the local manager will always be right
[17:54] <AdamZaius> I was actually thinking we can do some really neat stuff by cheating like that.
[17:54] <MW__> we aren't at that point yet. having the same local code for sandbox and grid, but thats what I would like (or nearly the same,
[17:54] <AdamZaius> Like say hosting 1001 regions on the server.
[17:54] <MW__> just grid has the "if not local use remote grid server") but to get to that point we need a better OGS protocol
[17:54] <AdamZaius> Reporting 1000 of them to the grid server
[17:55] <AdamZaius> then having 1 that's only accessible through one of the known 1000
[17:55] <dalien> so basically in standalone mode, the outbound pipe for the grid server is not used. i like the idea i think.
[17:55] <dalien> MW: then the asset/inventory/user servers would still be usable in the localmode as well, right ?
[17:56] <MingChen> therefore, the grid server will never need to be called when in standalone mode (since the local manager is always right on getting sim info), BUT in the case we want to add more things to the grid server (I dont know, but something like backup stuff, or something like that), it will be there when the local manager cant do it alone
[17:57] <dalien> MingChen: this approach has an added value of being able to develop the local gridserver first, then go do the "fallback" paths
[17:57] <MW__> yeah , well user server currently is as I said the same base class just with overridden methods handling comms
[17:57] <MW__> it seems to work so I see no reason to dump it and go to http , but its not a big issue I have no problems if we have a new user server wrote , in using http for that in sandbox mode, same with asset and inventory, they can be http,
[17:58] <MW__> but while they can be http, I would still rather most of them weren't
[17:58] <MW__> but its not a big issue
[17:58] <MingChen> MW__ yep, and even then, http for the "gridserver", but in standalone mode, that would have no need to be used
[17:58] <MW__> where as the grid server code I think is
[17:58] <MW__> MingChen, yep
[17:58] <MingChen> since the localmanager would take over every time
[17:59] <MingChen> yay agreement
[17:59] <MingChen> brb, lunch
[17:59] <MW__> yeah thats what I was saying, guess just not explaining what I meant very well
[17:59] <dalien> MW: ok, for me the bigger concern were the asset/inventory/etc. - since I'd like to be able to have them external.
[17:59] <dalien> MW: I like your idea of 2-tier gridserver quite a lot.
[18:01] <MW__> dalien, yeah I certainly agree with asset (and most likely inventory) would be nice even in sandbox mode to have them be able to be on a remote computer
[18:01] <MW__> but then again we can actually do that now as we use a common interface for the assetserver so in each mode you can use the asset server from the other mode (at one time in trunk when we had no remote asset server we had a hack so we could test things with the sandbox asset server )
[18:04] <dalien> MW: yeah. although for those it might make sense to have them over HTTP always - the amount of interactions there is not so much; plus being able to debug what happens with a mere ethereal would also be helpful, imho.
[18:07] <dalien> hmm cool. tested with libsecondlife - the "real" server sends StartPingCheck almost 2 timer per second...
[18:08] <dalien> I'll then put into my patch to send it once per second if no other traffic received.
[18:10] <MW__> yeah as said for those I have no real problem at all in them being http , just with performanc stuff (like the grid server stuff) and consider as said we will have the same local code anyway
[18:10] <MW__> same with IM, I'm not sure as Adam is doing that, but I would guess there is going to be some way for IM's to a person in another region in the same instance to have as little need of a remote server as possible, (most like just needs the remote server to say where that person is?), so that same code (with minor adjustments for lack of remote server?) works in sandbox too
[18:11] <dalien> IMs: why don't we use the external infra (jabber?) for inter-sim communications ?
[18:11] <MW__> thats the plan, Adam is looking into that
[18:11] <AdamZaius> I'm looking into Jabber.
[18:11] <dalien> so for local IMs/chats we use intra-sim means, and for external comms - this goes to jabber network
[18:11] <AdamZaius> Whether we use Jabber itself, or something that "looks like" jabber to external jabber clients remains to be seen.
[18:12] <AdamZaius> The big problem with straight up using Jabber itself is we've got a bit of a authentication problem.
[18:12] <dalien> the added advantage will be the "opensecondlife chat clients" will be pretty much anything
[18:12] <MW__> but I would rather not need to use that in sandbox mode, don't think we really want everyone to run a jabber server to run sandbox mode
[18:12] <AdamZaius> Specifically when users move from sims to sim.
[18:12] <AdamZaius> We'd need to have a jabber server in every single sim and log in a client for every agent in the sim
[18:12] <AdamZaius> or we'd need to write some kind of bypass mechanism which allows us to forge the "from" field and send that to the grid's IM servers.
[18:13] <AdamZaius> The problem comes is, that we also need to authenticate that the user is infact sending the message
[18:13] <AdamZaius> so we need to hash it with their secure session ID as a salt.
[18:13] <AdamZaius> and hence the whole thing has suddenly become layers and layers more complex.
[18:13] <dalien> yes. i wonder what kind of "trunk" connection do jabber servers have.
[18:13] <dalien> mhmh although... in jabber the users are authenticated as user@jabberserver, so indeed this will become a problem
[18:14] <dalien> login once and then use roaming ?
[18:15] <dalien> i.e. user would have a "home sim" which would log into jabber for him/her
[18:15] <dalien> and the other sims would talk to this one. although this smells like an entirely new messaging framework. grr. :)
[18:16] <AdamZaius> :)
[18:16] <AdamZaius> The problem precisely.
[18:17] <dalien> hm otoh.. what do we do with the inventory services for the grid mode ?
[18:17] <dalien> i think it should be a similar problem, no ?
[18:17] <AdamZaius> That's another big problem too.
[18:17] <AdamZaius> We do have one piece of information that the user is in the sim however.
[18:17] <AdamZaius> Or at least has been in the sim recently.
[18:18] <dalien> yeah. but i still wonder, maybe this is something that could be solved similarly
[18:18] <AdamZaius> Something called the "Secure Session ID" - the user carries it around, and we can probably pass around a SuperSecretID that the client doesnt know about.
[18:18] <dalien> user has a roaming profile - which moves around the servers
[18:18] <AdamZaius> Basically the inventory server will know the users current session ID and will be able to check incoming requests to make sure:
[18:18] <AdamZaius> a) The user is online
[18:18] <AdamZaius> b) The ID's match
[18:18] <AdamZaius> (well not match, will use a hash comparison)
[18:19] <dalien> hmm. look. idea... when user moves into the sim we can pass the "blob", right ?
[18:19] <dalien> this blob would contain the inventory server to talk to for this user
[18:19] <AdamZaius> It gets passed around with the expect_user messages
[18:19] <AdamZaius> That's passed around already
[18:19] <AdamZaius> the User Inventory URI
[18:19] <AdamZaius> same for User Asset URI
[18:19] <AdamZaius> It's done so you can have foreign users in your sims
[18:20] <dalien> ah ok. maybe we'd need to have a "messaging server" then too :)
[18:20] <dalien> although a question how to get the external messages then - becomes bit messy
[18:20] <AdamZaius> I've been thinking of breaking it up from fixed URI's like that on the users profile
[18:20] <AdamZaius> there being another table containing every service, and whether the user overrides the default grid URI for it
[18:20] <dalien> good idea.
[18:21] <MingChen> ok back
[18:23] <dalien> good. libsecondlife can connect and hang on the opensim. now i need to do the cleanup code.... seems like KillClient() is not enough...
[18:36] <MingChen> im adding the things we discussed here to the proposal and adding a few other things
[18:42] <MW__> would be good to put something on the mailing list regarding that proposal (and what we discussed here)
[18:43] <MingChen> ok