Date   : Wed, 07 Nov 2001 06:41:30 -0800 (PST)
From   : Thomas Harte <t.harte@...>
Subject: Re: 2 player gaming

In order to keep the conversation alive, I have drafted a possible protocol
for this sort of thing and uploaded it to
http://electrem.emuunlim.com/smp.htm . Although that document is highly
unlikely to make much sense (my first drafts rarely do), I'll summarise the
ideas here.

A shared machine is considered to be one Electron/BBC/whatever to which
multiple users are affecting the state of the inputs, and a session is an
instance of a shared machine. A server handles arbitrarily many sessions.

To each machine architecture is assigned a discreet (in the mathematical
sense) way of the inputs. Also some way of breaking down the state of the
entire machine into small-ish packages is defined. The period between input
samplings is defined also. The server is acting in a dumb architecture
neutral manner, making it easy to experiment and define new architectures. 

All an emulator has to be able to do once a connection is established is to
be able to sample its input and communicate its machine state. In general
what will happen is that every discreet input step the server will send out
a request for the input state at all the connected clients. That state is
collated by the server into a total state and communicated back to the
clients. Additionally, from time to time, some random part of the machine
state is requested from all clients to make sure a state desynchronisation
has not occurred. If one has occurred, the set of clients in the minority is
rebroadcast the entire machine state.

There is also a mechanism for 'bouncing' messages off the server to all
connected clients, and for polling for available sessions. The first of
these includes a server set flag if the message is from the client that
created the session. That client is known as the session leader. The
intention is that a particular architecture can define it so that if a
particular message comes from the session leader, all other clients
effectively await a new machine state. Which is principly a means of
supporting 'multiload' games.

The concept of an architecture and input state is sufficiently open ended
that most machine architectures could be connected via sessions from just
one dumb server - the servers are not Acorn/BBC specific. In the draft
specification, not machine architectures are defined, principly because that
isn't the focus of the specification right now.

Anyway, comments, help with a second draft, anyone?

-Thomas





_______________________________________________________
 Get 100% private, FREE email for life from Excite UK
 Visit http://inbox.excite.co.uk/