Article 4307 of sci.virtual-worlds: Newsgroups: sci.virtual-worlds Path: news.u.washington.edu!milton.u.washington.edu!hlab From: snoswell@ucs.adelaide.edu.au (Michael Snoswell) Subject: TECH: Info on CYBERTERM Open System (long) Message-ID: <1992May31.221443.12742@u.washington.edu> Originator: hlab@milton.u.washington.edu Sender: news@u.washington.edu (USENET News System) Organization: Information Technology Division, The University of Adelaide, AUSTR Date: Sun, 31 May 1992 16:24:54 GMT Approved: cyberoid@milton.u.washington.edu Following is the document I promised a while back on the system I am developing. I have received many requests for this data so here it is (a little incomplete or it never would have been posted). I'm emailing copies to those who requested it and will be in touch with programmers who said they were interested (see later). --------------------------------------------------------------------------- OSC Open System Cyberterm THIS DOCUMENT This document is an overview of ideas and concepts that have evolved over the last year or so. It is not meant to comprehensive, exhaustive, complete or fixed. Any items mentioned herein are open for discussion and modification through arbitration (ie if you've got a good idea, tell me and we'll use it!). Criticism is most wellcome as this has chiefly been only a two person project with various input from 1/2 dozen others. Arguments and pointers from others would be gratefully received. The first part of this document discusses some broad ideas and then gives a brief description of the terms used. Following this is a 1/2 technical discussion on a walk though of some aspects of the system. After that a more detailed examination is made of the various terms described briefly earlier and finally a look at other, less related topics is covered in cursory fashion. After all that a brief description of the software as it stands is given, along with projected milestones and pleas for technical/programming assistance. This document mentions many ideas and concepts that stem from the use and implementation of the underlying protocols. This paper discusses broad uses of the protocols and the resulting system rather than focusing on the protocol itself. The reason for this is two-fold: 1) The protocol by itself would seem pretty meaningless without describing how it works and how its resulting use affects the dynamics of a system, and 2) The protocol isn't firmly set. As the system is developed, more holes are found and things change. There are 1 dozen or so basic messages and a dozen or so rules that are followed, but these are in flux. It is hoped that this paper will give readers some familiarity with the type of system that is beeing aimed for. A later paper, covering the nitty gritty may be produced, but the detailed explanations may be left to the source code itself when it is released. Having read this discussion first, users and programmers will be in a better position to criticise and aid in the systems development (by discussion and programming support). Note: Where possible I have put terms in capitals which refer to concepts/objects whichare peculiar to this system. This is to try to differentiate items when using English to describe some ideas etc, to make things a bit clearer. SYSTEM OVERVIEW The need for a low cost, low bandwidth cyberterminal (CYBERTERM) has arisen due to the increasing need to communicate over existing data channels with existing hardware. The system is aimed for widespread use over a number of platforms and data connections. Initial release is planned for late '92 in a shareware format with full source code for all available systems. INTERFACE The interface is simply using the screen with the keyboard and mouse to provide a window view into a cyberspace area. As source code will become available. The addition of Power Glove, HMD and other devices will be encouraged but not initally supported and will not be required. The nature of the system will be such that if you have a PC XT with hercules graphics then you can display only wire frame at 1 frame per second (or whatever the software can manage). If you have an Indigo or similar then you are lucky enough to be able to display 30 frames a second, solid or rendered. The idea is that all the different systems will be able to be functionally connected together in a meaningful manner. If you have a full body suit, lucky you and you get better integration into the cyberspace etc etc etc. What this all means is that the code has a central communications core that is common to all modules on all systems. The interface business is merely a variable front end. All systems will use the same messages etc to communicate, but the low end users' systems will not request the extra data and will not be capable of producing some messages. (eg if you don't have a mouse then movenment is via keyboard. If you have a Data Glove then movement can be via gestures). INITIAL SYSTEM The system will initially be designed around a PC, with Amiga and X11 (on a Sun IPC) mods being made as we go, but with no special provisos for these machines at this point. Software is currently being written and a beta version will be available in a few months (now is May '92). Release will be via request to selected users for immediate feedback, followed by general shareware release. SYSTEM ARCHITECHETURE The whole nature of the cyberspace is controlled by the messages that are sent, which abstractly define the rules for objects, clients etc within the cyberspace. To more clearly describe the nature of these rules and messages, a number of terms have been borrowed and coined to describe new/borrowed concepts. Once these terms are defined, then it becomes much clearer as to how the whole thing fits together and the interaction of objects and the nature of this interaction will become evident as you understand the rules and contraints which define the behaviour of the cyberspace. DEFINITIONS These definitions are brief and are given to allow a fuller understanding of the descriptions to follow. A more detailed discussion of these terms will follow later. CLIENT A CLIENT is the term to describe a person (USER) who is connected to a system. The CLIENT may be automated (an AGENT). SERVER A SERVER is the central message handling facility which handles the data flow between CLIENTS. (A bit like a BBS) LOCAL SERVER (LS) A LOCAL SERVER is a SERVER that resides on the same machine as the CLIENT. REMOTE SERVER (RS) A REMOTE SERVER is not at the same physical machine as the CLIENT in question. CYBERTERM (CT) This is the term to define the CLIENT and the LOCAL SERVER together which a USER interfaces to. This all resides on his local machine. SECTOR A SECTOR is a region of CYBERSPACE which is controlled by a single SERVER. SECTOR CONTROLLER (SC) This is another term for the SERVER, but which covers the CLIENT that is local to that SERVER (akin to a News conference moderator or a BBS sysop). PERMASPACE (PS) PERMASPACE is an area of the SECTOR which has been allocated to a specific purpose. The data defining this region resides in the SC which controls the SECTOR. PRIVATE PERMASPACE (PPS) PERMASPACE can belong to a single CLIENT (or else it belongs to the SC). If a USER acquires a region of a SECTOR for their own use, that region is called PRIVATE PERMASPACE and is controlled by the owner CLIENT's LOCAL SECTOR CONTROLLER (ie the SERVER which resides on their own machine). LINE A LINE is the connection from the SERVERs to the CLIENTS, LINEs can be virtual or real. AGENTS AGENTS are macros that use the messages and protocols of the system to perform tasks as the USER himself would. There are 3 types of AGENTS defined so far. PRIVATE AGENTS, SC AGENTS and INDEPENDENT AGENTS. ASPECT ASPECT is the description of an OBJECT and covers visual and audio definitions in an extensible hierarchy of increasing complexity. All objects have default ASPECTs. CYBERSPACE CONFERENCING (CBC) This is the initial "let's get together and have a chat" aim of the system and is useful when people ask "So what are you working on?". You say, "I'm working on a Cyberspace Conferencing system", or something like that. GUEST A GUEST is a CLIENT who is remote to your location who is connected to your LOCAL SERVER. BBS A bulletin board system, which when in "chat" or "conference" mode is a good analogy for what this system will build upon (ie a graphical version of a BBS CB channel.) OBJECTS OBJECTs are any things which exist within a SECTOR and and listed in a SERVER database. This includes CLIENTS, AGENTS, PERMASPACE etc. ID ID applies to AGENTS, CLIENTS and SERVERS. It is a unique 4 byte number where the top 4 bits define what type of object the ID belongs to. FAR - 1,000 units NEAR - 100 units CLOSE - 10 units VERY_CLOSE - 1 unit (ie 26 adjacent units) A DEMONSTRATION RUN THROUGH Perhaps the best way to show how the various features of the system interact is to give a description of a typical session. This description will not be exhaustive and will give some technical details of the message passing that will take place during such a session. A complete description of all the features will not be given here as that would take too long and this is only meant to be an overview. However, what I hope is to be able to give some insight into what the working system will be like. So here we go. (by the way this description is of a screen and keyboard system, but as stated above, you can use whatever hardware/imagination you have available) First off when you start up the CYBERTERM you have a blank screen with maybe a few control buttons around the edges. The first step is to log into the LOCAL SERVER. Now this is a SECTOR CONTROLLER that resides on the same machine and in the first incarnation of the software is all in the same executable. This connection is done by hitting the 'connect' key (or mouse button etc). This will send a REQUEST_TO_ENTER message to your LOCAL SERVER, but first the interface will require that you enter some parameters. These are: 1) your proposed entry point into the LOCAL SECTOR, and 2) the proposed viewing direction. In a more advanced system these parameters will probably be pre-set in an option menu so you don't have to enter these details each time, but that's the way it is now (Note: There are quite a few places where things can be pre-set like this, as you'll see). Once the CLIENT software has assembled this data it sends the message to the LOCAL SERVER prepended by your ID, a unique identifying code (4 bytes) that defines you as a human CLIENT as well as giving you a unique handle for reference purposes. An additional parameter, velocity, is set to zero and is the final part of the message. The connection between the CLIENT and the LOCAL SERVER is a buffer that emulates a LINE. A daemon type function transfers the message across to the SERVER's input (and visa versa). The reason this is done is so that the software for a REMOTE SERVER and the LOCAL SERVER will be the same, except that the daemon will be different (ie transfering data to and from a modem, serial line, socket, or whatever). So as far as the SERVER is concerned it is running autonimously from the CLIENT and the human interface handling software. The SERVER checks its internal database of objects to see if you are allowed to enter at the specified point (more on that in a moment) then sends a MOVE_TO message back to the CLIENT. This includes the CLIENT's ID to make sure the right person gets the message (not necessary obviously as you're the only one logged into your machine), a location tuple, a direction tuple and a velocity tuple (which is zero in this case). Now it looks like we're already sending redundant information, but these are generic commands that can apply to many situations. You CLIENT software now gets this MOVE_TO message and can throw up an image on the screen which shows what the SECTOR looks like from this point. What's there to display? Well by default the 'floor' of the sctor is blue and can be displayed as a grid. The range of co-ords is 2**16 (32768) only positive, as a 32 bit fixed decimal number. This effectively gives a cube 32768 units on a side. That seems small but think of each unit as one metre. This means the SECTOR is about 32kms cubed, with increments down to 1/30 mm. I really think this will cator for system (and user) requirements for a long time to come. There is room for much more detail than this actually (2**32 time more) as is shown later under PRIVATE PERMASPACE. Okay, so we see a blue grid below us. Our CLIENT software is keeping track of our velocity and co-ords at the last vector change (ie time stamped) in its internal object database (this is separate from the SERVER's object database). So a simple look at the time and a scan of the database will give the current location of all objects and the screen can be updated accordingly. If your machine is slow this screen update is slow etc. Now that you're logged into the LOCAL SERVER things get a bit more interesting. To make things a bit clearer I'll skip over the details a bit here and get to a remote connection. Suffice to say that the objects contained in the LOCAL SERVER all belong to your PRIVATE PERMASPACE. There may be objects here, for instance that represent your hard disk and so you may have a graphical operating system where you can move files, launch applications etc. You can construct objects and store them for later use. Certain areas may be defined as dorrways to the control of real-world apparatus by telepresence etc. So you now have your own SECTOR, a whole world really, in which to create and move. Now all this on your own machine is nice but dull. The next step is to send a TRANSFER_SECTOR command. This will move you to another SECTOR. This will obviously be a REMOTE SECTOR. It's up to you to specify a legal SECTOR you wish to transfer to and it's up to your LOCAL SECTOR CONTROLLER to know how to connect to the SECTOR. Asumming all this has been set up your LOCAL SC (for modem) dials up the remote SC and identifies itself as an SC that has a CLIENT that wants to enter. This is sent as a REQUEST_TO_ENTER command (as before). Your CLIENT software knows that to issue a TRANSFER_SECTOR message you must enter a location and view direction so it prompts you for them (or gets it from pre-set options as before). The local SC passes the info on to the remote SC. If the request message is okay, a MOVE_TO command is sent from the remote SC to the local SC which now knows that any data coming in from the CLIENT (on LINE x) is transfered straight to the remote SC (on LINE y) and visa versa. Now that your CLIENT software has a new location and viewdirection it adjusts it's internal object database and updates the screen accordingly (the blue grid). When you entered the SECTOR the SC sent a message of its own to all other users who are within NEAR (100 units) of where you entered. These messages say what your ID is, your vector and location (this is actually a PERSONAL_ASPECT_DATA message which has ID, vector and location in the front of the message but without the ASPECT data as the SC doesn't have this yet). These other users may have their systems set up to ignore these (unexpected) messages, but if they process them then you, the new user, will appear on their screens in the appropriate place and will be placed in their individual object databases. They may also have a database of 'know ASPECTS' and can check to see if they already know what you look like and so can display you in your full glory straight away. Alternatively they may have their system set up to automatically request your APSECT if it is unknown and to display it then. Anyway, you've just entered this REMOTE SECTOR. Now you can send a message (or a more sophisticated system would be pre-set) to ask the REMOTE SC what the brief details are of all users within NEAR of your location (that is, to send you PERSONAL_ASPECT_DATA messages with ID, vector and direction). This data is added into your CLIENT's object database (with a time stamp) and the objects appear on your screen with the default ASPECT. You can request the details of other users over different distances first off if you like. Once you know the ID of other users you can REQUEST_ASPECT_DATA of a specific ID, to whatever level of detail of ASPECT the REMOTE SC has in it's database. So on your screen these other users appear as arrows (their default ASPECT) or their real shape. When you move (that is, change your velocity or direction) your CLIENT automatically sends a message (MOVE_TO) to the SERVER. If this is okay by the SERVER then it sends a MOVE_TO message to you telling you where to move to (the reason for this is made clear later) and then the SERVER distributes the message to all NEAR CLIENTS. In this way, as you watch your screen with these objects moving around in straight lines until they change vec/vel when you get a message from the REMOTE SC telling you their new velocity/direction. If you turn around your system sends a MOVE_TO message that is distributed and others see your shape turn around etc. It is important to note that there is no collision control and it is quite possible for you to move straight through someone else. (Note: The only possible exception to this is stopping over a PERMASPACE unit you do not own (see later) or the possiblity that two CLIENTS cannot be at the same point at the same time. There is no logical reason why this could not be so, it's just that it doesn't see right to me. Being instantaneaously at the sam epoint is okay, (ie moving through each other), but being stationary at the same point? Comments please.) An optional message that you can send to the SC is CHANGE_UPDATE_RATE which tells the SC how often to send you location, vel and vec updates of all CLIENTS within a given distance of yourself. Normally you would have to request this information specifically and the position of users you see on the screen may be false (for example a user may drift out of the NEAR distance from you but your object database is still tracking them saying they are moving at such and such a vector and speed when actually they may have changed direction etc. So with a CHANGE_UPDATE_RATE message you can request to be updated on the stats of users who are NEAR or FAR or whatever say every 10 seconds. Of course if they move when they are within NEAR of you then you will be automatically updated anyway). So now you can sit and watch these shapes going by. Other commands within a SECTOR are SEND_MAIL, JUMP_TO, REQUEST_SECTOR_TRANSFER etc. Similarly to requesting the ASPECT of users in the area, you can request the ASPECT of PERMASPACE in the area. PERMASPACE is permanaent regions that default to blue. These will usually consist of PRIVATE PERMASPACE but some regions may be owned by the SC such as public database access areas and public bulletin boards (more on these later). Just like CLIENTS, PERMASPACE has a default ASPECT that is a blue cube that occupies the unit cube that is the centre of its local co-ordinate space. Requests for higher level ASPECTS may reveal these cubes to be buildings, flashing lights or data structures etc. A PRIVATE PERMASPACE ASPECT may reveal that it belongs to a friend of yours. (It may his name on top or maybe you recognise his style of castle!) You can move through PERMASPACE but you CANNOT stop (ie have 0 velocity) when in a unit cube of PERMASPACE which does not belong to you. So you stop one unit away (VERYCLOSE) and send a REQUET_TO_ENTER_PRIVATE_PERMASPACE. This is interpreted by the SC as a TRANSFER_SECTOR message, to the LOCAL SERVER of the user who owns that PP. If the request is okayed by the owner then you are sent a MOVE_TO message that moves you to the coords of the PP. Now you have transfered to a new SECTOR and are controlled by the owner's private SC on his machine. The remote SC you were controlled by now routes all your data straight to the LINE that that new SC is on. (in a similar way to how your LOCAL SC is re-routing all your data straight through to the modem). Once again your screen is blank and you can request to see what's around you. This person may have his SECTOR set up to look like a lounge room or as rolling hills. All messages from users who you could see before (ie those outside that unit cube of PP that you're in) are filtered out to reduce bandwidth required (you may, for instance want to keep mail coming through. If you have a powerful system you may still get all 'outside' messages but make the walls of the living room appear transparent like smoked glass etc). Now that you are in his SECTOR you must abide by his rules. If you send a MOVE_TO message that will make you collide with object in his PP (eg a chair or wall) then his sector can return okay for that request, but when it calculates that you've hit a wall, it can send an addittional MOVE_TO message that sets your velocity to zero. In this way you must follow the rules he has set up in his PP. Obviously if he proves to be obnoxious you can send a EXIT_SECTOR message that the main REMOTE SC intercepts and so moves you back out into public cyberspace, garuanteed. Other users can enter the PP of your frined at the same time so you can have a 'private conference with only those present'. At that time his LOCAL SC daemon has set up secondary virtual LINES to allow the messages from several remote CLIENTS to come down the one modem connection. As each message is preceeded by the message senders ID, it's a fairly simply task fo rthe daemon to put the incoming messages into the appropriate virtual LINE buffers so the SC thinks there are lots of people/modems connected up. Of course, the main remote SC may also provide private conference rooms where similar duscussion can take place. This PP may alternatively be the front end to access a commercial database, a game service, a ticket sales office etc. So you want to establish your own PP within the public SECTOR? You send a REQUEST_TO_AQUIRE_PRIVATE_PERMASPACE message that is sent via the SC to anyone who is CLOSE to you (within 10 units). If less than 50% of those nearby say 'no' to the SC then you aquire 1 unit of PP and this is registered in the SC's object database. You can optionally send PERMASPACE_DATA messages to the SC that define the ASPECT of your PP to whatever level of detail you desire so others can see your new aquisition. Clearly, you can aquire several PP units next to each other and build up a composite structure that is more impressive. This aquisition is monitored by the SC and there may be limits defined. Some reqions of PP that belong to commercial users may be large (eg a database service for stock information may have a large area of PP that (when you request to see higher level aspects) may be large building surrounded by wide grass areas with fountains and gardens). Maybe there would be large areas within the owned PP that has no higher ASPECT so that in a crowded area of many PPs the structure will stand out as it has all this 'open' space around it. You can send mail to a friend by several methods. The most straight forward would be to use the SEND_MAIL message where you specify the recipients ID and then the message (no set format, just specify the length in 4 bytes). The mail will be sent straight to his LINE. If he is currently transfered to another SECTOR, the mail is sent on to the next SECTOR to which he travelled (he may have moved on from there too). He may have his CLIENT software set up so mail appears as a flashing icon on the screen or as a full letter box outside the little cottage that is his PP. Mail can also be send to a location and the SC will try to inform the owner, if the mail is not received, a MAIL_FAILED message is returned. Text mail may be appended to a PP ASPECT temporarily. In this way if no-one is 'home' (maybe not logged in or in another SECTOR) then you can send the mail to the PP location and when he person returns he will see an added object on his normal PP aspect. This object may be a piece of paper with the text message written on it. In a similar way a true bulletin board could be set up, where people could leave messages for others to read. So you can conference with otheres, send mail, access commercial services etc. The commercial services may first connect to the system using their original 2D flat screen interface, so when you enter their PP you just see a single screen. In this way the interface changes would be minimal to start with but they could develop better interfaces to make data access more efficient. A statistics service could have a PP where data was represented as dynamic 3D structures etc. Probably the most useful items within the cybersapce are your AGENTS. These items exist as packets of messages that together form an entity that is a type of object. See the comprehensive definition later on for details. Agents can do whatever you can do, in your place. Some agents are simply objects that you use (for instance a 'design-an-aspect' agent may allow you to draw items in 3D (walls, texture, motion etc) and will then create the ASPECT data for you). It may be an access key tool (eg you might guy a '10 shot' agent from a database service. When you want to access that database you instruct the agent as to what you want. The agent then goes off to the databases PP and gets a high prioirty of service (because you paid for it!) and also knows how the database works and so can access the data faster and then mail the data back to you (or maybe return to you itself with its ASPECT changed to show you the data) and after the tenth use it doesn't come back. The last sort of agent is independant. These actually are macro languages that are executed by the SC and may act as guides to newcomers or perform tasks within the sector for you (ie like a servant). They can exist by themselves. You can have an AGENT that 'lives' in you PP and answers requests to enter from other CLIENTS while you are tied up somewhere else. Now this brings on all sorts of possibilities. You could send an AGENT to a conference in your place and it may respond to text as a human would, to gather data for you. For this reason and others, there is one strict rule, and that is that the default ASPECT of agents are a white star made of three perpendicular axes, no matter what. Another example is to have several agents that travel with you in unison and which have ASPECTS that fit into yours to make one larger, more impressive ASPECT. One ASPECT detail that hasn't been mentioned is sound. Obviously a sound interface would be good (so you can talk to people you meet other than just sending mail or typing stuf in during a private conference). Sound would be easy enough to implement into the SEND_MAIL message protocol (you get mail from someone who is in such and such a direction therefore the headphones position the sound source accordingly). But I would like to incorporate it into the ASPECT as well so you could hear someone comming, even if you were looking in the wrong direction. (Note: Its clear that this system is open to abuse to rogue CLIENTS that send invalid messages. The buck will have to stop at the SERVER and so this could end up being a pretty awesome beast as far as functionality goes.) DETAILED DESCRIPTIONS NOT COVERED BEFORE (incomplete section) (note: I covered a bit more detail than planned above, hope it suffices for now or I'll never send this thing!) =================================================================== =================================================================== - each CLIENT has an ID derived from their "login" address (eg internet address) and so is unique. Along with ID, each CLIENT has an ASPECT which describes how they appear to other CLIENTS. ASPECT by default is an arrow with a single feather to indicate 3D orientation ASPECT has levels, the one just stated is the default level, 0. The next level is "wire frame" representation that consists of a variable length list of points and vectors. They have variable colour and have a DYNAMIC | STATIC parameter, if DYMNAMIC is TRUE then motion paramters follow (undefined yet). The last parameter is EXTENDED. If EXTENDED is TRUE then a further level follows defining solid geometry descriptions, which end with the EXTENDED parameter for future expansion. Things are designed this way so that a simple system (AT with CGA graphics) can select only the minimum display criteria because that's all it can handle. Better machines '486, Silicon Graphics Workstation etc can go for full solid rendering etc. =================================================================== =================================================================== SOFTWARE STATUS The system so far has a CLIENT that connects to the LOCAL SERVER and allows the user to move around within their own SECTOR, requesting information on and displaying PERMASPACE objects that are already in the SERVER's object database. This is all in wire frame (easily upgraded to solids, but it goes too slow on the PC (386SX) for development work). This system works on a PC and on a SUN (X11). The graphics library used is VOGLE, but REND386 is being kept in mind for PC stuff. An Amiga version is in the works (mainly just requires the VOGLE driver). (VOGLE is available from most ftp sites I assume, I got it from the Australian ftp mirror site, archie.au:/graphics/graphics/echidna) The code is in ANSI C. This is ideal stuff for C++ but that would limit the platforms we could easily port to (and not enough people are comfortable with it yet). HELP WANTED As you can see, there are many ideas brewing here and so few implemented. I really hope to have something significant done by the beta release date later this year ('92) before tasks and improvements can be farmed out to others. Ideas on modifying the concepts involved would be wonderful, but programmers with time would be even better. Managing remote development seems a difficult task. Breaking this into neat packages isn't really possible at the moment. The only area that could be done (perhaps) is the graphical operating system stuff for your local computer. I hope people will disagree with me and show how this can be done as a joint effort. My time for co-ordination of such an effort is woefully limited which is why I have perservered with the programming alone thus far. As I think I mentioned earlier, I want to make this software freely available with limited source distribution until it looks stable. But in the long run, the source should be available for everyone to update and use as they will. My main reasoning for this is to give everyone a chance to have a working interactive system that they can connect up together. So far I have received about 30 requests for information/code. This document will be posted to sci.virtual-worlds and sent to each of the senders. If after reading this you want to help with programming, then let me know. Any and all comments (public and email) would be greatly appreciated. Cheers Michael Snoswell June 1st, 1992 snoswell@sirius.ucs.adelaide.edu.au p.s. okay, so the doco's not complete...(sigh) -- Michael Snoswell snoswell@sirius.ucs.adelaide.edu.au Vision Systems Limited 08 343 0462 South Australia "Profound quote"