From: Michael Snoswell Subject: TECH: Cyberterm Protocol Date: Wed, 22 Jul 1992 16:04:05 +0930 Cyberterm Maillist - 21st July, 1992 THE STORY THUS FAR Well, the design of the Cyberterm Protocol has gone through a number of iterations. The simple reason is that we were unable to take all the factors into account in our initial version. This may be through inexperience or whatever. It suffices to say that a test version of the system was written to test some of the nitty gritty details like message structure and parameters (there were actually three prototypes). What we have ended up with may not be the best way of doing things, but at least it works! This prototype testing has taken about 9 months and we feel it's time to get a fuller version of the system written and passed out to all of you so you can review/play with/modify/criticise it. THE PLAN The idea is that the design is being split into several component modules and those brave hackers who have offered will soon be given their allotted tasks. This stage (phase 2) should take a couple of months, after which the resulting code will be integrated by yours truly, tested by others and finally distributed by Christmas '92 as version C1.0 (`C` for Cyberterm). WHO GETS THE SOURCE CODE? Everyone receiving this mail will get the code. It's up to you to compile for your own machines. Binaries will not be made available. Documentation of undetermined quality/quantity will also be made available, but basically this is a system for programmers ans you will have to read the code to find out how it really works. WHAT WILL IN RUN ON? The Cyberterm is scheduled to run on PC, Mac, Amiga, Sun and maybe DEC station (I'm not sure what that is though!). The connections supported will be modem definitely and maybe TCP/IP as well (for ethernet and Internet connections!). WHAT WILL CYBERTERM CONSIST OF? We are talking basic front end (keyboard) and screen display. The salient features of the system are the ability to connect to any of the above mentioned computers. The system will run on a standalone computer in a meaninful fashion, but connecting to other machines is a major feature of the system. As the PC graphics library will be VOGLE or REND386, there are hooks for connecting gloves to your PC. The Cyberterm has no provision for these extra interface devices, you'll have to do that yourself. The system may be used "as is", but it is expected that it will be hacked/modified to act as a base or springboard for other ideas and systems. If the protocol proves to be robust and extensible enough so that it doesn't need changing, then we can still all communicate with each other. Cyberterm is a programmers system and is not really ready for end users directly, although it will certainly be useable in its base release format. WHAT IS THE MESSAGE FORMAT? After quite some thought we have decided (rightly or wrongly) to have a small number of messages. The actions performed in response to these messages will depend upon who gets them and what the state of the system is. Alternatively we could have had considerably more messages to cover all contingencies. However, we wanted something small and neat that could be quickly and easily grasped and implemented. The final system is more extensible for the given set of messages as their effect is determined to an extent by the sender/receiver. A larger message set would constrained the versatility of each message or made the set inordinately complicated. This way, subtlties and nuances in system behaviour are available. The base rules are fixed, certainly, but this tolerance will allow a wider variety of behaviours in implementations. The messages defined thus far are as follows: typedef enum message { /* messages that can be sent to/from client/server (but usually interpreted differently by each ) */ REQUEST_TO_ENTER = 0x0100, MOVE_TO, SEND_MAIL, ASPECT_DATA, /* messages sent from client to server */ EXIT_SECTOR = 0x0200, REQUEST_ASPECT_DATA, REQUEST_SECTOR_TRANSFER, EXIT_PRIVATE_PERMASPACE, REQUEST_PRIVATE_PERMASPACE, REQUEST_UPDATE_RATE_CHANGE, /* messages sent from server to client */ ACK_EXIT_CYBERSPACE = 0x0300, MESSAGE_FAILED, /* messages sent from the user's console to their client */ MOVE_UP = 0x0400, MOVE_DOWN, MOVE_LEFT, MOVE_RIGHT, MOVE_FORWARDS, MOVE_BACKWARDS, TURN_UP, TURN_DOWN, TURN_LEFT, TURN_RIGHT, STOP_MOVING, /* more user to client messages regarding display */ DISPLAY_MODE_RADAR, DISPLAY_MODE_WINDSCREEN, DISPLAY_MODE_ABOVE } MESSAGE; As those astute ones among you who have done cross platform programming know, enum types default to int on the local hardware. To resolve this, all message enums have a corresponding DWORD value where a DWORD is 32 bits (signed). Also, as Intel and so PCs are the odd ones out regarding big-endian and little-endian byte formats (generally speaking), then the PC is considered a special case and bytes are swapped when 32 bit codes are sent to the send buffer and swapped as they come in the receive buffer. On all other machines (thus far at least), the byte order is unchanged. Each message has the following format: DWORD sender id DWORD message size (bytes following this DWORD) DWORD message code (from above list) BYTE message body sender id is a random number at the moment, but should really be determined by "login address and name", so that it is unique. for instance, a REQUEST_TO_ENTER message sent to the LOCAL_SERVER has the format: DWORD my_id DWORD 28 DWORD 0x00000100 # REQUEST_TO_ENTER DWORD x # (x,y,z) position of proposed entry point DWORD y # into the SECTOR DWORD z # DWORD ex # view direction proposed if entry is DWORD ey # successful DWORD ez # The velocity is zero when a REQUEST_TO_ENTER message is successfully returned from the LOCAL SERVER. The LOCAL SERVER in turn will check it's internal OBJECT database to make sure you're not already connected. If you are it sends a MESSAGE_FAILED message. Otherwise it returns a MOVE_TO message, which is almost the same as the REQUEST_TO_ENTER message except it includes your velocity, which in this case is zero. DWORD your_id DWORD 40 DWORD 0x00000101 # MOVE_TO DWORD x # (x,y,z) position of proposed entry point DWORD y # into the SECTOR DWORD z # DWORD ex # view direction proposed if entry is DWORD ey # successful DWORD ez # DWORD vx # velocity vector, the length of which DWORD vy # is the speed (0, direction same as view DWORD vz # direction for REQUEST_TO_ENTER reply) Notice that three tuples are used to describe a MOVE_TO, consisting of 1) position 2) view direction, and 3) velocity (which is both direction and magnitude). This is a case of overkill for many applications as most people/objects wil be travelling the direction they are facing. Still, the addition of an option to add this later would not be possible, so it is included now. This way you can travel one direction and do a 360 degree spin to see what's around you as you travel. At 2400 baud you could receive 6 of these messages a second (approx) and so be notified of a change in position/vector etc of 6 objects within the SECTOR each second. This isn't alot! We thought about simplifying the above message. Not all the data items need to be 32 bit, certainly, but there is a certain elegance in maintaining an "orthogonal" data structure element size (ie keeping all data items 32 bit). Also, faster modems are becoming much cheaper and some system will be using ethernet. IO lines can be buffered too and as causality isn't being catored for it won't matter so much if you get a message a second or two late. (I imagine in the early days that this system will be essentially experimental so speed won`t be a big issue anyway). So you can see now, when I move (with keyboard commands for instance) my Cyberterm sends a MOVE_TO message to the SERVER. It in turn will broadcast this MOVE_TO message to all NEAR CLIENTS, who get the message and see that the sender_id isn't them. Their CLIENT searches the client OBJECT database, updates the objects (or adds them in) and time stamps them. When their display routine scans their object database it looks at the last position given and the timestamp, then updates the screen accordingly. There is a time lag here but we've decided that causality type issues are too complex to deal with here. We figure that by the time it becomes an issue, newer systems will be available. As noted elsewhere, these 32 bit number are actually fixed decimals, with 16 bits on either side of the decimal point. Speed is in units per second so the "granularity" of time is whatever your system can handle, but show be less than the frame update rate on your machine. Likewise, if you are within a SECTOR where the SECTOR CONTROLLER is LAWFULL (as apposed to UNLAWFULL), then it may stop you from hitting objects etc by sending you MOVE_TO messages that change your velocity/vector if you hit things. (an UNLAWFUL SECTOR CONTROLLER won't care if you move right on through someone else!). Obviously it's up to the discretion of the programmers of the Cyberterm implementation of that host SERVER. WHAT ABOUT THE FUTURE? With a full simulation of the entire world, we can run the system faster than real time and see what will happen in the future. It's a little like testing an aeroplane wing in a wind tunnel simulator. Just change the question from "What would happen IF we made it like this?" to "What will happen WHEN we make it like this?", and voila!, we are predicting the future.... If all goes well with this version and I have time, another version may well follow next year to implement all those wonderful improvements and features you will all be writing/suggesting. This wont become an X11 Windows of the future because I'd be old and grey by the time we reached version 11 (and not through natural ageing!). I have a number of other projects on the *front* burners, not the least of which is the draft of a book I am completing for the publishers (nothing at all to do with VR or computers), AD&Ding, looking after my pregnant wife :-) and lots of other things, aside of course from my regular 9-6 job! Expect to hear more news in a month or so, when the programmer's mantle of responsibility will be firmly resting upon the able shoulders of those tireless programmers in netland who have so humbly offered their services (I can hear the chuckles from here!). Any suggestions, thoughts or relevant ideas are still most welcome. There is a degree of flexibility built into the development process and it'd be better for us all if you speak up now before the coding is done. I'm on holidays for the next two weeks :-) and my hitherto silent design partner, Nigel Dobson, (the one who has shared many coffees v late into the night while I expounded utter crap and wisdom all in one) will be fielding your vociferous replies and shedding light into the deepest corners of Cyberterm permaspace. (ie answering queries and collecting proffered thoughts). Cheers for now, Michael Snoswell