USERDB Protocol Review

[»doc flabby]

View the Protocol below

 

 

Subspace II USERDB Protocol VERSION 1

----------------------------

Skybill5 is the offical USERDB Server.

 

Overview

--------

 

Responsibilities

----------------

Authenticating Network Service

 

Create new player account.

Authenticating a Player

Changing password

Forgot password

Deleting Unused Players

 

Protocol Detail:

 

MUST SUPPORT IPV6

 

Only network services are allowed to connect to the USERDB Service.

These are authenticated using IP.

 

NOTE the <> are just there to improve readability, they do not form part of the protocol unless stated otherwise.

 

Hand Shake

----------

 

> CONNECT::

< CONNECTOK:

> BEGIN

 

Everything after this is encrypted with

 

key =

 

Using AES

 

After Hand Shake

----------------

 

New Account

 

> Create:::

< CreateOK:

< Fail::

 

Authenticate Player

> Login::

< LoginOK:

< Fail::

 

Change password

> Change:::

< ChangeOK:

< Fail:::

 

Forgot password

> Forgot:

< ForgotOK:

< Fail::

 

 

Keep Alive

----------

 

> PING:

< PINGBACK:

 

Disconnect

 

> END:

Disconnects

 

Extensions

----------

All command extensions must be in the format:

 

EXT

 

COMMAND = Your custom command

 

You are encoraged to provide custom extensions back to the community.

 

 

Trailing COLONS ARE REQUIRED FOR COMMANDS WITH NO PARAMETER TO SHOW THE END OF THE COMMAND

 

 

 

any comments, critics welcome.

[»D1st0rt]

shouldn't it include which attempt is failing or succeeding in case you send another request before you get the response back

[»doc flabby]

shouldn't it include which attempt is failing or succeeding in case you send another request before you get the response back

The client must not send another request untill it has a responce back.

 

The server will ignore any requests it recieves that are not valid for the servers current state, a request changes the servers state. I probably should make that clear.

[Samapico]

What if the request packet gets lost or something?

[»doc flabby]

What if the request packet gets lost or something?

If the server never recieves a request it doesnt matter, as it wont respond. The client would have to handle this by sending a ping after a timeout period (say 5 secounds). And if it recieved a response to that ping in that time to resend the command. Alternativly it could drop the connection and reconnect.

 

Hmm another thing i left out. It uses TCP. Which means the packets will arrive in order and no packets should be lost.

 

I also probably should add each command is terminated by a new line character.

Also i need to add pings can be sent at any time. Even if a command is in progress.

 

 

 

Does anyone have any comments on the general overview?

 

The idea of this sturcture is to separate usernames from networks, so you can have one name for ALL networks. But networks and zones will not be able to see your password. Meaning its very easy to add new zones and networks without worrying about players names being stolen. Essentially if the same princible was applied now it would make it possible for ALL zones to be on SSC.... However individual networks and zones would decide bans, and name restictions.

Edited February 6, 2008 by doc flabby

[Smong]

You haven't mentioned anything about escaping colons or newlines.

 

Are the encrypted passwords ascii-armored?

 

You said everything is encrypted but have you tested this will work? TCP is a stream, there is no such thing as a packet with a beginning and an end (implying a length). Hopefully this is already covered by encryption APIs since it seems like a common thing.

 

What's the point of trailing colons if you're also using a newline (which you didn't specify, could be any combination of cr's and lf's). It makes the protocol look inconsistent.

 

Are command types case sensitive?

 

Also I suggest making the extensions of the form EXT: instead of EXT. This will make it easier to separate the message handler code by splitting on colons only, instead of the special case "check the first 3 characters".

[rootbear75]

TCP is a stream, there is no such thing as a packet with a beginning and an end (implying a length). Hopefully this is already covered by encryption APIs since it seems like a common thing.

i thought all TCP packets had a header and a footer therefore having a set length

[»Ceiu]

For the TCP packets themselves, yes. But there is no guarantee that the data being sent will be sent as one packet. In most cases -- especially with larger packets -- it will likely be broken up.

 

UDP, on the other hand, is designed to be sent/received as single data packets (hence the name, datagram).

[»doc flabby]

Taking on board the advice, i've completely changed the protocol. Using RPC calls now over HTTP (SOAP)

 

Ill document more later.... And will do a file release, tired at the moment so probably do it later this week....

 

http://www.playsubspace.com:3080/ss2userdb.asmx

[»doc flabby]

FULL SRC AND BIN RELEASE NOW ONLINE https://sourceforge.net/projects/subspace2/

 

I doubt many people will find this useful, but i think its important for me to release this as the rest of the project is based quite heavily on some of the code...

[rootbear75]

wait? a working demo?

[»doc flabby]

wait? a working demo?

I need to be clearer, don't get excited. This is part of the boring stuff, im releasing Essentially its SSC2, central, secure user auth, which a big diffence, it allows untrusted networks to connect without fear of a players passwords being stolen...

 

this is part of the backend stuff, that i need to complete before the client can go much further....

If you want to see it in action visit http://www.playsubspace.com:3080/ss2userdb.asmx

its as boring as it looks

 

i doubt i will be working on the client for a couple of months, whilst is sort this stuff out...

 

Gotta adjust ASSS to work in 3D

Edited February 20, 2008 by doc flabby

[rootbear75]

so this is the server side stuff.... Edited February 20, 2008 by rootbear75

[»doc flabby]

so this is the server side stuff....

ya thats why i posted it here. Basically its the result of the work done and discussion that has gone on in this thread.

 

if it was a client release it would have got its own thread.

[rootbear75]

[Samapico]

Awesome... I can't comment cause I have no knowledge in networking stuff... but it's good to see the project is still going

 

By the way, I didn't give up either... DCME, 17th Parallel and school kept me pretty busy

[»doc flabby]

Awesome... I can't comment cause I have no knowledge in networking stuff... but it's good to see the project is still going

 

By the way, I didn't give up either... DCME, 17th Parallel and school kept me pretty busy

Thats the idea behind this project really, and why I made it OSS as you can dip in and out as you wish, depending on your real life circumtances.

[tcsoccerman]

sweet.