Meet2D Java Thin Client Edition

Initial concept Jan 14, 2001 -- BD

WHY WE HAVE TO ABSTRACT THE CONCEPT OF A PORT To complete the package of M3D/Thin there is the still remaining issue of the VNet server and those pesky ports. While we could put our process of database assignment of ports (by generating a unique page every time) this requires a much heavier commitment of a site to deploying stuff (ie our database or the user having to develop their own page generator or hand edit the ports in). In fact there may be the following much more platform independent way of doing it.. THE KEY In the applet params the caretaker (owner) of a world simply gives a unique named ID for their world (or we may give it to them). This ID will be used for all kinds of things later, for retrieving their world-caretaker record, for messaging them etc.. and could become a kind of IP address for DS spaces. Wherever this world is running, no matter with what server, we can find and reach them thru a server to server lookup like DNS. This ID could be some generated number (like ICQ) or even their email address (something unique and easy to remember for most people). With this they should be able to log into any workstation on the net and generate, access and manage their world. The ID would obviously have to come with a password.. so ID + pwd = "key". USE OF THE KEY TO ESTABLISH COMMUNICATIONS With this ID portion of the key (say for example, their email address possibly combined with worldname for a unique session.. more below), the local Oworld server (modified VNet in this first incarnation) can resolve how to serve the world in the following steps: 1. The applet starts and uses HTTP to get the content of the world downloading from a location. 2. In the same breath the applet drops its session identifier key (ID plus pwd) into a file (the "access key") on the server in the directory where the content is coming from. This is using port 80 also (HTTP). 3. Upon seeing this access key file drop (signalled in some way, perhaps by the very presence of the file or some watcher process) the Oworld server (or a super server) loads the new access key file and assigns an available port number (or channel + port number). If by chance another user is already logged in and running in this session, then that key is matched and the port or port+channel is assigned (in an internal table). Oworld server then simply writes this assignment back to another file (the "connection key") in the same resource directory for the applet(s) to find. 4. The applet polls for the existence of this connection key file a set number of times (if it cannot find it then the server is busy or otherwise unavailable and this can be reported to the user or the applet can switch to a serverless "primitive" mode.. see below). If the file is found it is loaded and parsed by the applet, the port number (possibly plus channel) is used for connection to the Oworld server. If there is a channel number assigned this is used as a prefix to any datagrams going to the Oworld server to distinguish its channel within the port (for an Oworld server supporting channels in the future). Having picked up this connection key file it is left on the server. In fact, any applet connecting with the same session ID will find that this connection file already exists and simply load that, forgoing having to write an access key (step 2). This means that the first connection starting the session requires the most steps, and subsequent connections will only require an additional file load. In fact, with this system, fixed port/channel assignments can be preset into a server by simply having these connection key files present in the directories (and not ever deleted). In this way, for now the Oworld server need not do assignments but simply respond to traffic on ports. Indeed in our current VNET configuration, we have to have a single VNET server per port so there remains the problem of which servers poll which directories (!). Some of the architecture here assumes a single super server. Hopefully this key dropping and picking up can be multithreaded and occur while the content is loading. Logon can occur after the connection key is loaded. In future the connection key can contain other types of information that the Oworld server wished to pass to the applet, such as news announcements, notices of expiration etc. AN EXAMPLE.. In fact taking this further, the access and connection keys would be uniquely identified to the Key (this has nothing to do with the user name or the resources used, those are independent). For example: Users named Harry and Sally use M3D to start a session inside the room content "tgs8" using caretaker key [owner@email.org/pwd: heyguys]. It is the key that connects the two of them into the same session. Another world caretaker (owner) could be loading the same room tgs8 but would not be seen by Harry or Sally. So in the content directory, both key files (access and connection) could be dropped by many different users from different distinct sessions (created by different caretakers). They share content, they do not share sessions. So in that one contante/control directory, if Harry gets there first, his applet drops owner@email.org.access-key and gets back from Oworld owner@email.org.connection-key Sally logs on later and her applet has the same caretaker key [owner@email.org/pwd: heyguys] and also points to tgs8's content directory where the key files generated by Harry's session connection still lie. Sally's applet simply pulls in the file owner@email.org.connection-key and pulls out the port/channel, and she should then log in and see Harry standing there in tgs8. Of course if her applet specified that she load the room tgs9 (a rare situation of mutual realities), then her applet will created a key pair too (if tgs9 is in another directory on the server) but she will still see Harry. At the same time other users BIll and Bloogie could be connecting with applets having caretaker keys [another-world-owner@email.org/pwd: heyotherguys] and using the room tgs8 and they will drop and pick up different key file pairs, and of course get different port+channels and not see Harry or Sally. In a total preassignment scenario, the connection key files: owner@email.org.connection-key another-world-owner@email.org.connection-key will be prebuilt and set into the directories, to be parsed by applets during session startup. Oworld servers need not be involved in this scenario assigning ports or channels. CARETAKERS HOSTING MORE THAN ONE WORLD (SESSION) Now if the caretaker who has email address owner@email.org has more than one distinct world (ie, desired unique session with a given space) then their unique key has to contain a suffix to distinguish which session/world they want to start with a given applet, so the keyfiles could be named, say: owner@email.org[tgs8room].connection-key owner@email.org[tgs9room].connection-key KEY CLEANUP 5. Next.. if Oworld detects when no user is in fact running a session with a given key (applets all either exit gracefully or time out) then it de-allocates the port or port+channel to be allowed for use by another session. At the same time Oworld would delete all access and connection key files from that applet's resource directory. This clean up signals that these users and their sessions are no longer active and prevents Oworld or any Applet from looking for these files by accident later. Care will have to be taken to prevent Oworld from having to scan all applet resource directories continuously to look for new access key drops. In fact if there is a way to signal Oworld explicitly that a new key is dropped (from a watcher process) this will help. BENEFITS OF KEY-FILE BASED CONNECTION ESTABLISHMENT This kind of process has the following benefits: 1. The applet can initiate the request for the port/channel to communicate with the Oworld server without having to contact the server through a port (which it does not know anyway). We wont have to have Oworld servers always contactable through a fixed port either, as that will require applets to always need 2 ports. 2. The applet creator does not have to know about ports and can create a new user session simply by using a new key. 3. The applet now has a way to know when the server is unavailable 4. Monitoring software can know when servers are down by seeing the unpicked-up keys 5. If a server is unavailable the applets can go to a "primitive mode" wherein they will continue to do everything file-based. IE: if all applets come to the recognition that there is no server (the existence of un processed keys) then they can start to write and read text chats and even avatar motion changes (very intermittently) to disk files on the server. This was described in my proposed "cherokee logic" architecture of july 2000. This can happen until a server drops the connection key. NEXT STEPS Well team, this may sound complex, but it really comes down to some simple step by step algorithms and a staged implementation. What I would suggest is that we could do the following preliminary steps to migrate gradually off the applet dependence on local port assignment: 1. If the applet parm: <param name="VNetServerPort" value="8888"> is not present then the applet is in "server side port assignment" mode so.. 2. the new parameters: <param name="CareTakerKeyID" value="ctbells@qwest.net"> <param name="CareTakerKeyPwd" value="encryptedgobbledygook"> are examined and the CareTakerKeyID is taken and combined with the world name parameter: <param name="worldName" value="titans-class"> to produced the unique caretaker KEY name ctbells@qwest.net[titans-class]. 3. the applet then tries to find the file at the following location on the server derived from: <param name="src_root" value="/dspace1/classrooms/"> giving the total path to the connection key file of: /dspace1/classrooms/ctbells@qwest.net[titans-class].connection-key 4. if that very file is present then the applet pulls it in and looks for the content, which could be simply a port number (for now). If the file is not present.. well then Oworld would have to do the assignment (to be done later when we attack the server modifications or building of a super server). YOUR COMMENTS Well team this is my brainstorm. I know BDC and Alex are likely to be able to grok this and maybe have some comments! I can't vouch for the correctness or efficiency of this approach. How much longer would applet connection times take? Will this burden the Oworld server(s) trying to scan for new connects, and write and delete files? How will this scale? Can a primitive mode allowing fall-over operation during server down time really work?

Back to Support Index