Netplay protocol revision
12 views
Skip to first unread message
alight
Jan 21, 2011, 10:34:54 PM1/21/11
to nullpomino-dev
I decided it is worth hashing out a better protocol for netplay. I
wound up being a little more vague than syntax and listing commands
and responses, but this should be enough to begin discussing.
Design goals
The design goals in this case are pretty straightforward. The server
must be able to:
· Provide a way for players to participate in games with each other
· Provide a way for players to communicate with each other
· Provide basic administrative functionality
· Maintain long-term mode-dependent data such as high scores
· Maintain long-term user-dependent data such as ratings
In addition to these things, I believe the following items are also
desirable:
· Independence from client version
· Easy to extend
· No functionality limited by protocol design
· Clan/team support [register and authenticate to clans as well as
users]
Fundamental choices
Certain decisions about what will be done and what is allowed/
disallowed may affect the design of the protocol. Here are the ones I
can think of:
· Protocol: binary or text-based?
· Authentication? Tripcodes? Both?
· Names: allow spaces? Other namespace restrictions?
· Games: server maintains gamestate? Server timestamps game messages?
· Lobby: required or optional?
Proposal
Here I will propose the basics of a protocol that I think would best
fit our needs. The protocol I have in mind will be based on IRC. I
have included features that can be implemented later but that I
believe are worth eventually including in the game.
Messages
All messages received from the server should include a timestamp and a
message type. The message type can be a numeric, ala IRC, in the case
of the server responding to a client’s request or action (such as
connecting), or it can be a string indicating a message being relayed
by the server on behalf of other clients. The data may include
additional parameters to lend specificity to the message type, such as
a game room or a username. These additional parameters will be defined
by the message type.
Message parameters will be separated by spaces and, in general, one
message per line. We may need or want extensions for quoting or multi-
line parameters or replies, in which case something along the lines of
HTTP would suit, with one parameter per line and a blank line to end
the command/response.
Connecting/Negotiating
A client establishes a connection to the server. The server should
reply with a message indicating it is a Nullpomino netplay server, the
protocol version, and the most recent client version that is
available. This last will be used to prompt automatic updates for
minor version revisions. The version numbers should be fine-grained
enough to differentiate between all possible clients that may connect.
Another message should follow containing a list of options the server
supports but does not enable by default. The client must enable these
options before login if it chooses to. Zip links is one that comes to
mind, but this functionality is mostly present for expansion in the
future if necessary. It could be expanded into some sort of handshake
if necessary.
Upon receiving the welcome message, the client must then authenticate.
There should be support for creating new accounts, recovering
passwords, and the like, if and when these features are desired. Only
commands related to these functions, enabling optional functions, and
updating (below) are allowed before authentication.
After authenticating, the server will respond with acceptance or
rejection. Standard three tries then disconnect or something can go
here, of course. If the user successfully logs in, the server should
issue a list of users and room summaries automatically; everything
necessary to display the lobby window, basically.
Updating
If the client requests an update, the server should reply with a URI
to the relevant version of Nullpomino. This may be hosted by the
server or somewhere else, it doesn’t matter – updates should not be
sent in-line, as netplay will be flexible enough to allow users to
connect and communicate even if they are unable to play.
Communication
This part should very closely model IRC. Channels with modes and
operators, as well as private messages. There should be a main lobby
channel that clients are automatically joined to by the server upon
authentication. Server administrators should have operator powers in
the lobby automatically.
The lobby should be represented internally, and protocol-wise, the
same as other channels; the only thing that makes it special would be
its status as the default chat room for newly connected players.
Whether clients can leave it or not is a separate issue and can be
implemented in the client or the server as desired.
All game rooms should be channels, but not all channels need be game
rooms. Chat-only channels should be creatable for things like private
multi-user conversations, clan chat rooms, organizational rooms, and
so on. Only very basic modes need be supported, but I suggest at a
minimum, private, invite-only and moderated. There should also be a
mode that enables the room as a “game room” and enables players to
join and play a network game.
Channels should not do any interpretation of settings, so it may be
the case that if a client requests the server to enable gameplay in a
channel, the server must deny the request. This would happen if there
are no settings stored – the channel was created but never configured.
If a client creates a game channel, the commands should go something
like: join <channel> / setrules <dump rules> / mode <channel> +g, or,
in words: join, configure, enable.
It may be desirable to instead design a system whereby the channel can
store arbitrary game settings. This could get complicated quickly, but
would allow something like server-side filtering of game rooms by
specific settings. It bears keeping in mind, and could be implemented
in parallel to something like “setrules / getrules” commands which
only dump the full settings data.
Channels can tie into clan support. I suggest that “normal” channels
and game rooms operate on the first-come first-op principle of IRC,
with the exception that if a room loses all operators, the oldest user
becomes opped. You may “register” one channel if you are an operator
in the room of that name, and this is how you create a clan. Clan
members can be added, and these can bypass invite-only modes and bans
at will. It may be necessary to implement some hierarchy, either
something like owner-op-member, or a numeric system like some channel
services have had, but it is important to design these features from
the perspective of clan features, not channel features. Requiring ops
in the channel is really just a way to avoid conflicts such as trying
to register a clan when someone else is in the channel of the same
name. Since this is about clans and not channels, you may only be the
owner of one registered name, and users that are a member of your
channel may not own other channels. If the owner leaves a clan, the
channel registration passes to the next oldest operator, then member,
unless there are no members in which case it is dropped. Periodic
cleanup might be called for too.
One "channel registration" per user lies a bit outside my statement of
"not limiting functionality by the protocol", but that depends in this
case on implementation. Suggested implementation should allow for
ownership of/membership in multiple channels, but I don't think it
should be enabled.
Server admins should have the expected powers: global messages, bans,
user account/clan management, etc. I am against allowing server
administrators to bypass invite-only or moderated rooms.
Gameplay
Gameplay rooms are channels with a mode set to indicate they are
playable. Private rooms will not show up in the list of available
games. Invite-only applies, too, of course.
Channels will need to store data describing gameplay settings, and
allow them to be altered without having to recreate the channel. A
couple ways to accomplish this are touched on in the previous section.
The game version stored by the channel should be the version of the
client being used that last updated the game settings. It is up to the
client to deny the user to join games of an incompatible version, but
there is no reason that a client with an incompatible version cannot
join a channel and chat in it. A client that has operator status
should be able to overwrite settings from an incompatible version with
its own version. Settings changes should be held if a game is in
progress until the game ends.
For actual gameplay, the server itself needs not take a very active
role. A special message type, other than the types used for chat, will
simply relay messages from client to client. The server should,
however, echo these messages to the client that initiated them. The
reason for this is that the server timestamps and orders the messages.
This enables clients to decide what to do in cases such as attack
messages crossing during network latency. (Who received, who
canceled?) It also gives clients a definite order of win/loss.
Game related messages such as who is playing/not playing can be
wrapped in this mechanism. The specific messages valid to a client
version can therefore safely be changed without affecting the server.
Clients should not process messages in a game room that is set for an
incompatible version. It might be possible to enable spectating for
such clients, if they ignore messages they don’t understand, but it
would require further error checking on the protocol messages to avoid
doing anything that might disrupt the client program.
The user that set the gameplay mode should be granted a special status
that restricts further settings changes to them alone. This status may
be retracted after a specified idle time, or when the user leaves or
disconnects. The status should pass on to the next most appropriate
member of the channel. This is to avoid things like multiple channel
operators fighting over settings, or somebody playing a single player
game getting suddenly dumped into multiplayer because another operator
changed the game type. This could be implemented like +o, to enable
the game master to transfer the status, but only one user should ever
have this status in a given channel at a time.
Information
Various bits of information should be stored by the server and
accessible to the players. This can include high scores, client
information (/whois), a list of clans and/or players, and so on. The
usual IRC command-response format can serve well here. Player
statistics such as win record or speed might be stored with
authenticated accounts, as well.
wound up being a little more vague than syntax and listing commands
and responses, but this should be enough to begin discussing.
Design goals
The design goals in this case are pretty straightforward. The server
must be able to:
· Provide a way for players to participate in games with each other
· Provide a way for players to communicate with each other
· Provide basic administrative functionality
· Maintain long-term mode-dependent data such as high scores
· Maintain long-term user-dependent data such as ratings
In addition to these things, I believe the following items are also
desirable:
· Independence from client version
· Easy to extend
· No functionality limited by protocol design
· Clan/team support [register and authenticate to clans as well as
users]
Fundamental choices
Certain decisions about what will be done and what is allowed/
disallowed may affect the design of the protocol. Here are the ones I
can think of:
· Protocol: binary or text-based?
· Authentication? Tripcodes? Both?
· Names: allow spaces? Other namespace restrictions?
· Games: server maintains gamestate? Server timestamps game messages?
· Lobby: required or optional?
Proposal
Here I will propose the basics of a protocol that I think would best
fit our needs. The protocol I have in mind will be based on IRC. I
have included features that can be implemented later but that I
believe are worth eventually including in the game.
Messages
All messages received from the server should include a timestamp and a
message type. The message type can be a numeric, ala IRC, in the case
of the server responding to a client’s request or action (such as
connecting), or it can be a string indicating a message being relayed
by the server on behalf of other clients. The data may include
additional parameters to lend specificity to the message type, such as
a game room or a username. These additional parameters will be defined
by the message type.
Message parameters will be separated by spaces and, in general, one
message per line. We may need or want extensions for quoting or multi-
line parameters or replies, in which case something along the lines of
HTTP would suit, with one parameter per line and a blank line to end
the command/response.
Connecting/Negotiating
A client establishes a connection to the server. The server should
reply with a message indicating it is a Nullpomino netplay server, the
protocol version, and the most recent client version that is
available. This last will be used to prompt automatic updates for
minor version revisions. The version numbers should be fine-grained
enough to differentiate between all possible clients that may connect.
Another message should follow containing a list of options the server
supports but does not enable by default. The client must enable these
options before login if it chooses to. Zip links is one that comes to
mind, but this functionality is mostly present for expansion in the
future if necessary. It could be expanded into some sort of handshake
if necessary.
Upon receiving the welcome message, the client must then authenticate.
There should be support for creating new accounts, recovering
passwords, and the like, if and when these features are desired. Only
commands related to these functions, enabling optional functions, and
updating (below) are allowed before authentication.
After authenticating, the server will respond with acceptance or
rejection. Standard three tries then disconnect or something can go
here, of course. If the user successfully logs in, the server should
issue a list of users and room summaries automatically; everything
necessary to display the lobby window, basically.
Updating
If the client requests an update, the server should reply with a URI
to the relevant version of Nullpomino. This may be hosted by the
server or somewhere else, it doesn’t matter – updates should not be
sent in-line, as netplay will be flexible enough to allow users to
connect and communicate even if they are unable to play.
Communication
This part should very closely model IRC. Channels with modes and
operators, as well as private messages. There should be a main lobby
channel that clients are automatically joined to by the server upon
authentication. Server administrators should have operator powers in
the lobby automatically.
The lobby should be represented internally, and protocol-wise, the
same as other channels; the only thing that makes it special would be
its status as the default chat room for newly connected players.
Whether clients can leave it or not is a separate issue and can be
implemented in the client or the server as desired.
All game rooms should be channels, but not all channels need be game
rooms. Chat-only channels should be creatable for things like private
multi-user conversations, clan chat rooms, organizational rooms, and
so on. Only very basic modes need be supported, but I suggest at a
minimum, private, invite-only and moderated. There should also be a
mode that enables the room as a “game room” and enables players to
join and play a network game.
Channels should not do any interpretation of settings, so it may be
the case that if a client requests the server to enable gameplay in a
channel, the server must deny the request. This would happen if there
are no settings stored – the channel was created but never configured.
If a client creates a game channel, the commands should go something
like: join <channel> / setrules <dump rules> / mode <channel> +g, or,
in words: join, configure, enable.
It may be desirable to instead design a system whereby the channel can
store arbitrary game settings. This could get complicated quickly, but
would allow something like server-side filtering of game rooms by
specific settings. It bears keeping in mind, and could be implemented
in parallel to something like “setrules / getrules” commands which
only dump the full settings data.
Channels can tie into clan support. I suggest that “normal” channels
and game rooms operate on the first-come first-op principle of IRC,
with the exception that if a room loses all operators, the oldest user
becomes opped. You may “register” one channel if you are an operator
in the room of that name, and this is how you create a clan. Clan
members can be added, and these can bypass invite-only modes and bans
at will. It may be necessary to implement some hierarchy, either
something like owner-op-member, or a numeric system like some channel
services have had, but it is important to design these features from
the perspective of clan features, not channel features. Requiring ops
in the channel is really just a way to avoid conflicts such as trying
to register a clan when someone else is in the channel of the same
name. Since this is about clans and not channels, you may only be the
owner of one registered name, and users that are a member of your
channel may not own other channels. If the owner leaves a clan, the
channel registration passes to the next oldest operator, then member,
unless there are no members in which case it is dropped. Periodic
cleanup might be called for too.
One "channel registration" per user lies a bit outside my statement of
"not limiting functionality by the protocol", but that depends in this
case on implementation. Suggested implementation should allow for
ownership of/membership in multiple channels, but I don't think it
should be enabled.
Server admins should have the expected powers: global messages, bans,
user account/clan management, etc. I am against allowing server
administrators to bypass invite-only or moderated rooms.
Gameplay
Gameplay rooms are channels with a mode set to indicate they are
playable. Private rooms will not show up in the list of available
games. Invite-only applies, too, of course.
Channels will need to store data describing gameplay settings, and
allow them to be altered without having to recreate the channel. A
couple ways to accomplish this are touched on in the previous section.
The game version stored by the channel should be the version of the
client being used that last updated the game settings. It is up to the
client to deny the user to join games of an incompatible version, but
there is no reason that a client with an incompatible version cannot
join a channel and chat in it. A client that has operator status
should be able to overwrite settings from an incompatible version with
its own version. Settings changes should be held if a game is in
progress until the game ends.
For actual gameplay, the server itself needs not take a very active
role. A special message type, other than the types used for chat, will
simply relay messages from client to client. The server should,
however, echo these messages to the client that initiated them. The
reason for this is that the server timestamps and orders the messages.
This enables clients to decide what to do in cases such as attack
messages crossing during network latency. (Who received, who
canceled?) It also gives clients a definite order of win/loss.
Game related messages such as who is playing/not playing can be
wrapped in this mechanism. The specific messages valid to a client
version can therefore safely be changed without affecting the server.
Clients should not process messages in a game room that is set for an
incompatible version. It might be possible to enable spectating for
such clients, if they ignore messages they don’t understand, but it
would require further error checking on the protocol messages to avoid
doing anything that might disrupt the client program.
The user that set the gameplay mode should be granted a special status
that restricts further settings changes to them alone. This status may
be retracted after a specified idle time, or when the user leaves or
disconnects. The status should pass on to the next most appropriate
member of the channel. This is to avoid things like multiple channel
operators fighting over settings, or somebody playing a single player
game getting suddenly dumped into multiplayer because another operator
changed the game type. This could be implemented like +o, to enable
the game master to transfer the status, but only one user should ever
have this status in a given channel at a time.
Information
Various bits of information should be stored by the server and
accessible to the players. This can include high scores, client
information (/whois), a list of clans and/or players, and so on. The
usual IRC command-response format can serve well here. Player
statistics such as win record or speed might be stored with
authenticated accounts, as well.
Zircean Draconnia
Jan 21, 2011, 11:31:52 PM1/21/11
to nullpomino-dev
Re: Fundamental questions:
I think that the new system will have to use authentication. We were
planning on tossing tripcodes anyway, as far as I know. It would make
it easier to add the titles/achievements, XP, and Nullpoints or
whatever else we were going to do to make the game worth grinding a
little more, and it would also solve the problems of lost tripcodes
and such.
I think that the new system will have to use authentication. We were
planning on tossing tripcodes anyway, as far as I know. It would make
it easier to add the titles/achievements, XP, and Nullpoints or
whatever else we were going to do to make the game worth grinding a
little more, and it would also solve the problems of lost tripcodes
and such.
Wojtek Kowaluk
Jan 22, 2011, 2:01:31 AM1/22/11
to nullpom...@googlegroups.com
i have few questions.
so what's wrong with current protocol? how you design is different
from current protocol? Any reason why you think features you mention
can't be added with current protocol? what's benefit of allowing older
version to connect (i mean compared with descent auto-update feature
for example)?
myndzi
Jan 22, 2011, 2:30:01 AM1/22/11
to nullpomino-dev
> so what's wrong with current protocol?
Copypasta'd from IRC:
22:53.32 < myndzi> why would you want to change it? let me count the
ways... inflexibility, feature lack, rigid constraint to client
version?
22:54.26 < myndzi> want to add a feature to netplay? you have to edit
the server protocol, what's that about?
22:54.28 < myndzi> can't pm users
22:54.41 < myndzi> can't administer the lobby in any particularly
useful way
22:54.52 < myndzi> can't create chat subgroups of any form
22:54.55 < myndzi> can't create private rooms
23:00.02 < myndzi> oh yeah, i forgot tripcodes being sort of a
halfassed solution, particularly when we want high scores and ratings
etc.
23:00.16 < myndzi> putting all the information in the name list
because there's no way to request information about a user
> how you design is different from current protocol?
seems like it could use some direction, as well as the aforementioned
missing functionality. To my admittedly limited knowledge, the current
protocol appears to have been written mostly on the fly without the
kind of discussion I am attempting to encourage here, with the result
that there is not really an overarching structure to it or guiding
design principles. I welcome comment from someone more familiar with
it.
It is unknown if 1) the consensus agrees with how I think a good
system would be, 2) what the result of forthcoming conversation will
be and 3) the result of that conversation will require fundamental
changes or can be grafted on to the current solution.
> Any reason why you think features you mention can't be added with current protocol?
what we want, then let's look at how to get there.
> what's benefit of allowing older version to connect (i mean compared with descent auto-update feature for example)?
version, then the server doesn't need to be messed with in order to
roll out a new client version. Other advantages include the ability
for people to test or play development versions on the same server as
stable, roll back to older versions in case of unforeseen problems, or
simply chat while they wait for a new download to complete. It allows
the server to be much more hands-free than the current one has been,
as well as flexible enough to support whatever may come in the future,
if designed well.
Reply all
Reply to author
Forward
0 new messages