From: snoswell@itd.adelaide.edu.au (Michael Snoswell)
Newsgroups: sci.virtual-worlds
Subject: TECH: Cyberterm Protocol
Date: 22 Jul 92 06:34:05 GMT
Organization: University of Washington
Originator: hlab@milton.u.washington.edu



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