Message Boards

Topic: New protocol design ideas  (Read 20518 times)

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
New protocol design ideas
« on: July 24, 2008, 01:47:53 »
We have a bit of a situation regarding the launcher protocol it seems, here is a small list of issues I have outlined below:

  • Client uses exactly the same information as the launcher does, (probably implementation from the old csdoom days), so if we change information for the launcher, we could break the client (or vice versa) if we change it
  • Current protocol has no real versioning and is a mess, period.

So firstly we need to create a new function in the server for new protocol requests and keep the old one for backwards compatibility between old clients and launchers (0.4.0 and 0.4.1 for now)

After that, it gets trickier, you can have a look at the current proposed solution for above when I post it soon

EDIT: Just to clear things up, there is no intention of getting rid or changing the latter, the old function will still exist and remain the same until we decide to dump it.
« Last Edit: July 24, 2008, 05:06:29 by Russell »

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #1 on: July 24, 2008, 03:11:52 »
Here it is (in odt format)

Offline Voxel

  • Developer
  • Posts: 22
    • View Profile
    • Voxelsoft
Re: New protocol design ideas
« Reply #2 on: July 24, 2008, 18:39:43 »
Client uses exactly the same information as the launcher does, (probably implementation from the old csdoom days)

fyi, csdoom client didn't have this feature, but it is quite old :)

Offline Voxel

  • Developer
  • Posts: 22
    • View Profile
    • Voxelsoft
Re: New protocol design ideas
« Reply #3 on: July 26, 2008, 03:35:36 »
also, i like the protocol doc you put together

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #4 on: July 26, 2008, 08:08:22 »
Cool :)

A bit of work went into the versioning thing, which allows us to have:

255 major versions
255 minor "    "
255 patch "    "
and 65535 launcher protocol versions under 1 minor version.

More or less ;)

I don't know what to include in the contents of the packet yet for the first version, the arbitrary length cvar field was included at the last minute. It makes a couple of things above it redundant though.

So, open to ideas :P

Offline GhostlyDeath

  • Posts: 25
  • Democrats will destroy this flag!
    • View Profile
    • ReMooD
Re: New protocol design ideas
« Reply #5 on: July 26, 2008, 22:19:52 »
I agree...

Also, you may want to include masking, maybe 2 32-bit fields for 64-flags that it can be kept simple. The Server list the main page doesn't care for scores and all, maybe send RQ_SERVERNAME and just get the server name back, same can also go for launchers (i.e. partial refresh instead of a full one) then send the mask back of what is actually in that packet data. Can also save some space for useless stuff like in DM who cares for team scores yknow?.
ReMooD Project Leader - http://remood.sf.net/
Strawberry Doom Project Leader
Odamex Team Member

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #6 on: July 26, 2008, 23:59:23 »
I agree...

Also, you may want to include masking, maybe 2 32-bit fields for 64-flags that it can be kept simple. The Server list the main page doesn't care for scores and all, maybe send RQ_SERVERNAME and just get the server name back, same can also go for launchers (i.e. partial refresh instead of a full one) then send the mask back of what is actually in that packet data. Can also save some space for useless stuff like in DM who cares for team scores yknow?.

Omission/inclusion of fields based on masks can complicate:
1) We may or may not include a field in the next protocol version (eg included/removed team scores), then we have to say that the flag is available/not
2) If that were the case, we would also have to maintain a list of flags supported for each protocol version in the current minor version we are working with

However, you are right in that it would leave more space for certain game modes to have more information available later on.

It isn't necessarily a bad idea and it can always be added in later on (thanks to versioning)

EDIT: I found an article today which is "similar" to what we are discussing here: http://blogs.msdn.com/johnmil/archive/2006/01/11/511527.aspx
« Last Edit: July 27, 2008, 00:21:30 by Russell »

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #7 on: August 09, 2008, 08:23:53 »
New draft up

Comments and critique welcome.

Ant P.

  • Nobody
Re: New protocol design ideas
« Reply #8 on: August 09, 2008, 16:17:05 »
I can't see any obvious errors in it, though I have a suggestion for the master protocol if anyone's interested:

If it was changed to send each IP once with an array of ports, instead of sending a full ip+port for each server, the current server list would be about half the size. It's not much of a difference now but it might be useful later on.

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #9 on: August 10, 2008, 09:19:40 »
Yeah, one of the other ports ran into a fragmentation problem with packets stepping over the boundary if I remember correctly.

This sounds like a good idea and I have uploaded a (very) rough idea of an implementation:

Code: [Select]
Current list Format:
--------------------

4 bytes = Tag

2 bytes = Server count

Data block: 4 bytes (ip) + 2 (port) = 6 bytes

1) 10.0.0.2:10666
2) 10.0.0.2:10667
3) 10.0.0.2:10668
4) 10.0.0.2:10669
5) 127.0.0.1:10666
6) 127.0.0.1:10667
7) 192.168.0.1:10666
8) 192.168.0.1:10667
9) 192.168.0.1:10668
====================
8 ip/ports * 6 bytes = 60 bytes total


Proposed New List Format
------------------------

4 = Tag

Data block: 4 bytes (ip) + 1 byte (port count) + 2 (ports) = 7 bytes

10.0.0.2410666106671066810669127.0.0.121066610667192.168.0.13106661066710668
    4   1  2    2    2    2      4    1   2    2     4      1  2    2    2
====================
37 bytes total


What we do now:
1) We omit duplicate ips
2) We omit the server count field
3) We include a byte field after the ip, indicating how many subsequent ports exist

Pro's:
1) Saves data (example above proves a 23 byte saving)


Con's:
1) More complicated parsing required (but not much more)
2) We may or may not save space, especially if every ip address had only 1 port number

Hopefully my calculations aren't wrong, it is 2:30am.. :S
« Last Edit: August 13, 2008, 04:35:29 by Russell »

Ant P.

  • Nobody
Re: New protocol design ideas
« Reply #10 on: August 10, 2008, 10:04:06 »
From what you've got there, the total size only increases if the ip:server ratio is less than about 1:1.3. After that it's a gain.

I was thinking of it using 16-bit array sizes when I said about half in my first post, but nobody's ever going to run that many servers from one IP anyway.

Offline Russell

  • Developer
  • Posts: 70
    • View Profile
Re: New protocol design ideas
« Reply #11 on: August 10, 2008, 22:38:26 »
denis is going to dump the current master list setup it at some point anyway, he mentioned using http so we might aswell not waste time on that.


Offline Nes

  • Developer
  • Posts: 31
    • View Profile
Re: New protocol design ideas
« Reply #12 on: November 08, 2008, 16:21:57 »
I think the layout of our server response packet structure could use a bit of organization for 0.5.

Code: [Select]
//--- Main Response
Tag - Unsigned 32bit Integer
Version - Unsigned 32bit Integer
Protocol version - Unsigned 32bit Integer

//--- Server information Related
Password MD5 hash - ASCIIZ String
Current map - ASCIIZ String
Time Left - Unsigned 16bit Integer

//--- CVAR Related
Cvar Count - Unsigned 8bit Integer
+Cvar name (Cvar Count) - ASCIIZ String
+Cvar value - ASCIIZ String

//--- WAD Related
WAD Count - Unsigned 8bit Integer
+WAD filename (WAD Count) - ASCIIZ String
+WAD MD5 Hash - ASCIIZ String

//--- Team Related
Teams Enabled - Boolean
Team Count - Unsigned 8bit Integer
+Team Name - ASCIIZ String
+Team Color - Unsigned 32bit Integer
+Team Score - Signed 16bit Integer

//--- Player Related
Player Count - Unsigned 8bit Integer
+Player Ping - Unsigned 16bit Integer
+Player Time - Unsigned 32bit Integer
+Spectator - Boolean
+Player Team - Unsigned 8bit Integer
+Player Color - Unsigned 32bit Integer
+Player Score - Signed 32bit Integer
+Player Fragcount - Unsigned 16bit Integer
+Player Deathcount - Unsigned 16bit Integer

You might notice some odd changes in here. They're optional, but here's why I did them:

* Now that we've made the team structure a little less hardcoded (with our teamsinplay cvar), we can treat the number of teams like we would number of cvars/wads/players. We should also be prepared if we want to make teams customizable to the server. (Custom names and colors... but CTF will still remain RED/BLUE)
* If it won't increase the size of the packets too much, I was thinking that the server could submit the color of each team and player to the launcher. I'm not sure if wx's Color (or Colour, it's very picky sometimes) supports RGB values, but it would be nice to support it. (Maybe add a color square next to the name a la the odascoreboard)
* Replaced player killcount with player score so we can use it for other game modes. Making it 32bit is overkill, I know, I'm just putting it in there in case we decide to further implement my "replace monster kills with damage inflicted" patch.
* I was thinking maybe we have player fragcount an unsigned value that doesn't decrease due to suicides and use player score for DM matches. (where it's the fragcount - suicides) Ralphis kinda doesn't like the idea of the scoreboard showing Score / Frags / Deaths instead of Frags / Deaths, so we could either disguise the scoreboard Frags as Score or make it optional to display Score / Deaths.

Offline GhostlyDeath

  • Posts: 25
  • Democrats will destroy this flag!
    • View Profile
    • ReMooD
Re: New protocol design ideas
« Reply #13 on: November 08, 2008, 16:30:15 »
I suggest placing things in field so things are no longer dependent on where it is located and this would allow new things to be added. 4 bytes should enough.

Example: PLYS could mean players, then the player related data is placed in. Then maybe in the future you might want to create something new (new feature or you forgot something). Then also indicate how big the data is. Otherwise, you may end up throwing up everything in the end. If there is a new and improved packet, the new version should throw in both (in the case of old launchers) then the next version, remove it completely!
ReMooD Project Leader - http://remood.sf.net/
Strawberry Doom Project Leader
Odamex Team Member

Ant P.

  • Nobody
Re: New protocol design ideas
« Reply #14 on: November 14, 2008, 12:24:35 »
Would this be of any use here?