Ideas for the master server protocol

[orbitaldecay]

I've posted a file that I typed up which contains my ideas so far for
the master server protocol. I'd like to begin coding it this week, if
you all could find the time to read over it I would appreciate your
opinions. Thanks :)

Bob

[Richard42]

Hi Bob, good job writing up the protocol spec. It's a good start, but
there are a few extra things which you should at least consider
including in the communication:

1. Protocol version number - you mentioned this at the end of the
spec, and it should definitely be in there.

2. Players and time information: you might want to set up a game to
start once X players have joined, or else start after Y minutes
regardless of how many players have joined. So you might want to add
fields for things like "Required # of players" or "time remaining
until game start"

3. More compatibility information: ensuring that the ROM MD5s match is
not sufficient for maintaining the game synchronization, so I would
add fields for Mupen64Plus Version number, R4300 core used, and video
plugin used. There are many different ways that you might handle this
information (for example, by forcing the local R4300 core and video
plugin to match the ones being used for the game), but the first step
is to communicate this information.

Richard

[orbitaldecay]

Thank you for your feedback :D I should have been a little clearer
about my intentions with the master server, I only intended for the
master server to act as a repository for game server addresses. All
further information concerning the game server in question can be
obtained by querying the game server itself. This will solve two
problems; it will reduce the bandwidth used by the master server and
it will reduce complications involved in ensuring that the master
server is constantly informed of the status of each game server. I
was thinking the process would go like this:

1. Contact master server and request list of game servers running rom
X
2. Contact each game server in the list to retrieve data (time until
game starts, core info, plugin info, etc.)

Is that more clear?

Bob

[Richard Goedeken]

Okay, I see. The more detailed handshaking can be done with the individual game
servers. So you don't need the plugin/core/mupen version info, but you still
probably should have a protocol version #.

One thing that you may want to consider -- the master server arrangement that
you have specified allows only for searching for servers for a given game. What
if the client (mupen64plus) wanted to search for all games being played, in
order to give the user the choice of which game (ROM) he/she wants to join?

Richard

[orbitaldecay]

Yeah, I had thought about that, my only concern was for bandwidth. If
the master server is tracking any considerable number of open games
then that could get pretty heavy pretty quickly. The same thing could
also be achieved client side by sending multiple game list requests
for all of the roms in the rom cache, but I agree; that's worth more
consideration.

On Jun 30, 12:04 am, Richard Goedeken

[Scott Gorman]

Do not count any on any more than 75 games being open at one time.

[Richard Goedeken]

If every client sent game list requests for every rom in their collection, that
would really kill the server. :) You would probably save bandwidth by
maintaining a separate list of unique rom md5s for games being played, and just
send that list for a 'directory'. There are a max of several hundred games that
people could ever practically be playing at one time (there aren't that many N64
games), and if the MD5s are only 16 bytes long then you could never send more
than a couple of ethernet frames worth of data for the whole list. As long as
the clients wait a few seconds to refresh the list it should be okay.

Richard

[orbitaldecay]

I think that's an excellent idea, I hadn't thought of that :) Thanks!

Bob

On Jul 1, 10:11 pm, Richard Goedeken <Rich...@fascinationsoftware.com>
wrote: