Re: [Vrspace-dev] Standalone VRS
Brought to you by:
jalmasi
|
From: Rob M. <ro...@vr...> - 2004-08-18 23:20:52
|
At 08:20 AM 8/18/2004, you wrote: This is cool addition. >Now I must explain why Gate works as it works:) >Recursive symbolic reduction. It's about distributed AIML... i.e. host A >gets some query that ends up as catchall (can't resolve it). Then it >forwards the query to host B. B may find the appropriate category, but >also may perform some substitutions and forward new query to another host, >even A. >This may end with circular queries, A asking B and B asking A and so on. >NeuroGrid should take care of it - each unresolved query means we believe >less to this host and infinite loop should not happen. >This distributed circular symbolic reduction may be a cruical feature for >AI (ever had a dream when a situation repeats untill waking?), says >IDM : Sources of Meaning >http://pages.prodigy.net/lofting/ This questions concerns whether to link spaces together one after one as you visit them, or to always have two hop connection: first to your gateway, and your gateway to the current space. I have a very basic objection to linking: It is incredibly slow. I could even feel the effects on my local box after making something around six jumps. Add to that, it doesn't make sense. If I have left a space by gating to another, I have no objects from that space left in my Scene. Therefore, there is nothing for me to communicate with in that server any more. I don't fully understand, know you have explained several times, a very concrete example would be helpful. This is the way I see it. If a server needs to ask other servers with help concerning answering a query, then those servers should set up a peer group for resolving the answer. It is quite arbitrary to link servers together by the path you happened to take today. If you want, let this arbitrary path make suggestions to server as to which other server it should contact next. Either way, making multiple server move your requests around is resource wasteful, and I don't even think speed implementable. Don't get me wrong, I like the idea of servers being set up in a net where they can find solutions together, but it doesn't have to have anything to do with the client. >> When you first login to a space, the server searches for your >... > >But I see no advantages of zones. What you're saying won't let us carry >personal stuff to other spaces, in other words the implementation effort >is the same for both cases. >And still you can have personal space with existing code. Sure, we should >add hosts_allow/hosts_deny and allow only localhost for personal space. >Huh... not that sure: I wanna connect to my personal space from anywhere. >BTW to connect to another local server you can use PipedConnection, this >is what I did with xj3dclient - start server, start client, connect via >PipedConnection. Ports versus Zones: I am completely in support of the Zone idea. And yes, carrying things from one space to another has nothing to do with whether you use Zones or ports ( more below on Personal Spaces ). Here are the problems I see with continuing to use only Ports. Saying you have 10 major worlds, each of with have 10 sub locations. By sub location, I mean you walk are walking around outside, then you come to a castle. Walking inside the castle brings you to a sub-location, basically its own scene. That's a total of 100 ports on your server. Now say you have 1000 users ( that's what we are shooting for right ). Now you have a total of 1100 ports on your computer waiting for requests. Furthermore, when if there is no program listening on those ports to hear the connection, then there is no connection. Hence we would need about 1100 instances of the server running to accomodate. Not even remotely possible. A fix: Have one super server that first receives all requests on port 8500. It then checks to see if the particular port the client is trying to reach has a server running. It then starts up the server at that port, and then there is a connection. Slow, but not inconceivable. How's this? every single time a user wants to move from one location to another, it requires instantiating a new TCP connection. TCP connections take both time and memory. Can a computer support this many simultaneous TCP connections? Quiet down these troubles and I'll drop the Zone idea. Personal Space: I absolutely want Personal Spaces. Why? What is a personal space, but a database of your own objects. If we were not to use these spaces, then essentially we would have to create a database in each User object. Classically recursive. The situation begs for a it. >>think we should remove the vrspace.cfg file. It seems most of these >>settings can be stored in a Zone object in the Zones db, the other ones >>can go in zones.xml. > >I prefer properties file over xml file. As for db, better xml. Meaning we >need VRObject.toXml() and fromXml(). Sounds good! >> Yeah, so, I want to give the Server its own front end. It > >Right. Though I'm not that sure for it look... i.e. on startup I'd show >some form allowing user to edit server properties. >As for runtime looks... look maybe we could use xj3d for this after all, >and display spheres instead of users and boxes instead of objects... big >deal with vrspace is that it's somewhat self-documenting system: each >object has an url... Why use Xj3D, an IE window and Contact with you logged in does this ?!? You edit server properties online! >>We can make the server send files to be viewed to Chisel, though I would >>love it if VrmlPad was accessible that way, though maybe it is... > >Yeah, we should use some factory depending on mime type... i.e. i'd like >to open() java filez with jedit, etc. Yeah I would like to make VRSpace as close to the developer as possible. >> Of course, you can still run with the gateway server being >> remote as we now have it. Actually, what I really think is necessary in >> the long run is having some sort of universal identity server ( probably >> housed at vrspace.org ). This guy can give you a universal number ( >> like ICQ ) to uniquely identity you and act as an authority for >> verifying your password. There are problems with other people having >> the same name as you when you want to gate... > >Not exactly, Gate gives remote username <you>@<yourhost>. >As for 'universal' ID - won't work. With star structure you mention, we'll >bring down entire network when we upgrade vrspace.org. GUID and stuff are >somewhat better, but then we become ICANN:) Not quite p2p. Etc, that's why >I came up with <you>@<yourhost>. Sure, it's not quite unique, but since ><yourhost> isn't FQDN but any string, should be better. Universal ID is clearly not going to be an issue for a while. I like the way you put it here you@yourhost. What I didn't like before is that Gates seemed to work like, once you gate you become you@lastgatinghost, which doesn't make any sense. If you are always you@yourgateway, then it sounds pretty unique. >> Just to get it down on , er, paper, I am thinking of sending >> UDP messages from vrspace servers running to the main server to create >> heartbeating for who is online and what spaces they are advertising. I >> was even thinking of integrating into that multi-messanging client Ka >> uses : Miranda. Wouldn't it be cool to see VRSpace users online through >> it. Perhaps this where JXTA enters the mix? > >Here's how it works with JXTA: each server joins VRSpace peer group and >advertizes it's services/spaces. Fetch jxta shell at jxta.org, see what >you can do with it, source is also rather straightforward. >Then let's discuss this further. Forget UDP, JXTA is the way to go. Absolutely, I started looking at JXTA yesterday and soon realized that this is much more appropriate (and easier to implement) through that. Take care, Rob >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Vrspace-dev mailing list >Vrs...@li... >https://lists.sourceforge.net/lists/listinfo/vrspace-dev |