2.7.5 protocol updates

[NoseyNick]

Mostly "note to self" and a place to discuss 2.7.5 changes.

The docs describe a client heartbeat that is used by (at least) helm/weapons/eng so the server can spot half-dead TCP connections and avoid those consoles being locked out. Assume this has a new packet?

Some of the not-so-new Elite Abilities are now officially documented.

Any other updates?

[NoseyNick]

BADUnknownPacket:0x4c821d3c is presumably the new ClientHeartbeat. I shall reverse-engineer the JamCRC shortly. Early investigation implies that it's sent every 3 or 4 secs, and if the server doesn't hear it for about 12-15 seconds it stops talking to you. It doesn't DISCONNECT, it just doesn't talk to you any more. This tends to imply that EITHER Thom doesn't know how to disconnect sockets, nor how to detect disconnections, OR, giving him the benefit of the doubt, he's probably using a TCP library that makes it bizarrely awkward - some of the gaming libraries are more sucky than you'd imagine when it comes to TCP. :confused:

efbeadde 1c000000 02000000 00000000 08000000 # HEADER c2s len=28 3c1d824c 24000000 # payload

[JordanLongstaff]

Couple of questions here:

1. Supposedly the server listens for these heartbeat packets from some client consoles, but not all of them. What are all of those client consoles? Just Helm, Weapons and Engineering?
2. What is the meaning of the payload 24000000? Is that telling the server the "client ID" or the console types?

[JordanLongstaff]

Actually, never mind on question 2. It's the packet subtype.

[NoseyNick]

I'm being dumb. 0x4c821d3c is valueInt

So the new valueInt subtype 0x24, WITH NO ACTUAL INTEGERS is the client heartbeat. :laughing: ... Which I think means we're missing a valueInt subtype 0x23 as well?

[NoseyNick]

Haven't determined which clients send it. I suspect ALL clients do, because if I connect and just "do nothing", I get the usual stream of unsolicited objectUpdates and everything for about 12-15sec, then it just stops dead.

[NoseyNick]

My first few example captures (available on my usual archive site): 31 ClientHeartbeat 37 heartbeat 22 ClientHeartbeat 22 heartbeat 24 ClientHeartbeat 18 heartbeat 11 ClientHeartbeat 15 heartbeat 361 ClientHeartbeat 399 heartbeat So they're not quite 1:1 but they're well within an order of magnitude.

[JordanLongstaff]

What's with all the random-looking numbers?

[NoseyNick]

Packet counts in 5 files - EG one "game" had 31 ClientHeartbeat and 37 (server) heartbeat

[rjwut]

I think we should rename HeartbeatPacket to ServerHeartbeatPacket and name this one ClientHeartbeatPacket, and I think both should document the behavior of the stock software when it loses the heartbeat.

As for why it doesn't drop the connection when the heartbeat is lost, I suspect that it may have been an intentional design decision by Thom. Clearly he can make the software disconnect if he wants it to, as there is a button to do exactly that! It could be that in the case that there's still a connection but no heartbeat, Thom simply wanted to let the humans make the call if they actually want to disconnect. After all, if the connection recovers you can jump back in more quickly than if the connection flat-out dies and you have to reconnect.

[NoseyNick]

As long as we're clear that neither HeartbeatPacket nor ServerHeartbeatPacket correspond to the JamCRC hashes (I'm pretty sure that's already clear), I'm good with this! :+1:

[NoseyNick]

Apart from the ClientHeartbeat, I'm not aware of any other 2.7.5 protocol changes BUT I'm deeply suspicious that there's another valueInt subtype 0x23 we haven't found yet. Presumably a client2server packet. I am notoriously bad at testing c2s compared with s2c. server2client I can just run a server in AI mode for a few hours and expect to see everything. client2server, I have to actually do stuff in the official client :laughing:

It's also possible some Object enumerations have new values, but almost certainly no new object bits/fields.

[rjwut]

I don't know if this is new behavior or since what version, but it appears that there are changes to when gameStart (0x3de66711) and simpleEvent:0x0f (0xf754c8fe:0x0f a.k.a. AllShipSettingsPacket) are sent:

• gameStart: Previously I think this was sent only at the start of the simulation or when you connect to a simulation already in progress. Now appears to be sent regularly during the simulation, including during the "Game Over" screen.
• simpleEvent:0x0f: Previously I believe this was sent when you first connect to the server, or when a ship config has been updated. Now it is also sent regularly during the simulation, including during the "Game Over" screen.

[NoseyNick]

simpleEvent:0x0f is AKA "All Ship Settings" right? I used to see that appear in EVERYONE'S streams when ANY new client connected. When you say "sent regularly", is it possible something it connecting regularly? Not sure if the same is also true of gameStart, I don't recall.

[rjwut]

It's happening pretty consistently for me, and I know there isn't anything else trying to connect. I wonder if there's a packet that I'm sending that is now used to request an update to the game and ship state. Is this not happening for you?

[rjwut]

So I figured it out: When the game starts, it sends not only gameStart but also simpleEvent:0x0f (a.k.a. AllShipSettingsPacket), probably to ensure that everybody has the current ship configurations. But in my test client, I was sending valueInt:0x0d (SetShipPacket) valueInt:0x0e (SetConsolePacket) and valueInt:0x0f (ReadyPacket) in response to AllShipSettingsPacket, and it turns out that gameStart and simpleEvent:0x0f (AllShipSettingsPacket) are also sent in response to valueInt:0x0f (ReadyPacket) if the game is already running, so the result was that my client was getting stuck in an endless loop.

We should update the docs to reflect that gameStart and simpleEvent:0x0f get sent when the game starts AND when the server receives a valueInt:0x0f when the game is in progress.