Enhance live connection handshake interpretation in server #69

Merged
luca0N merged 2 commits from dev_server_live_handshake into dev 2026-05-07 23:10:26 +00:00
Owner

Enhance the live connection handshake in the server. This commit
removes the need to specify the protocol version in every packet sent by
clients, and instead relies on clients specifying the protocol version
right after connecting (the "handshake"). The server then goes on to
either accept the connection (if the protocol version is supported), or
to reject it (if the protocol version is unsupported).

Enhance the live connection handshake in the server. This commit removes the need to specify the protocol version in every packet sent by clients, and instead relies on clients specifying the protocol version right after connecting (the "handshake"). The server then goes on to either accept the connection (if the protocol version is supported), or to reject it (if the protocol version is unsupported).
luca0N self-assigned this 2026-05-05 23:18:44 +00:00
Enhance the live connection handshake in the server.  This commit
removes the need to specify the protocol version in every packet sent by
clients, and instead relies on clients specifying the protocol version
right after connecting (the "handshake").  The server then goes on to
either accept the connection (if the protocol version is supported), or
to reject it (if the protocol version is unsupported).
Author
Owner

This is marked as a WIP because, at this time, the server expects clients to write the protocol version directly as a string in the data field. A better approach would be to have a defined data structure (an object) which then has the version as a string.

This is marked as a WIP because, at this time, the server expects clients to write the protocol version directly as a string in the `data` field. A better approach would be to have a defined data structure (an object) which then has the version as a string.
Update the server live connection code, so that the server reads an
object (as opposed to a plain string) which contains a field called
`protocol_version', used to process the desired protocol version by the
client.

The way this is currently being handled is rather limited: the server
will only accept connections whose first packet contains its action
value equal to `HELLO'.  Although this is intended as part of the
handshake procedure, the refactor which has made the function
`readClientPacket' generic would prevent the server from reinterpreting
a client packet's data field with another type (if used under the same
settings).
luca0N changed title from WIP: Enhance live connection handshake interpretation in server to Enhance live connection handshake interpretation in server 2026-05-06 23:12:44 +00:00
Author
Owner

As explained in the message of commit e6353ca48a, the refactoring that was made in `readClientPacket' consumes pending input data from the WebSocket connection. This way, it becomes impossible to reinterpret the data of the packet with another type, because JSON unmarshalling is only handled once. I would like to iron out this issue before the first stable version (or, perhaps, before even merging this pull request).

As explained in the message of commit e6353ca48a, the refactoring that was made in `readClientPacket' consumes pending input data from the WebSocket connection. This way, it becomes impossible to reinterpret the data of the packet with another type, because JSON unmarshalling is only handled once. I would like to iron out this issue before the first stable version (or, perhaps, before even merging this pull request).
Author
Owner

@luca0N wrote in #69 (comment):

As explained in the message of commit e6353ca48a, the refactoring that was made in `readClientPacket' consumes pending input data from the WebSocket connection. This way, it becomes impossible to reinterpret the data of the packet with another type, because JSON unmarshalling is only handled once. I would like to iron out this issue before the first stable version (or, perhaps, before even merging this pull request).

I have decided to keep the code as-is for now because

  • refactoring this change is outside the scope of this pull request, and
  • the changes that will likely be made by this refactoring would likely change quite a few LoCs (more than what I would prefer for smaller changes outside of their dedicated pull request).
@luca0N wrote in https://git.luca0n.com/luca0N/lanbassador/pulls/69#issuecomment-1570: > As explained in the message of commit [`e6353ca48a`](/luca0N/lanbassador/commit/e6353ca48a), the refactoring that was made in `readClientPacket' consumes pending input data from the WebSocket connection. This way, it becomes impossible to reinterpret the data of the packet with another type, because JSON unmarshalling is only handled once. I would like to iron out this issue before the first stable version (or, perhaps, before even merging this pull request). I have decided to keep the code as-is for now because - refactoring this change is outside the scope of this pull request, and - the changes that will likely be made by this refactoring would likely change quite a few LoCs (more than what I would prefer for smaller changes outside of their dedicated pull request).
luca0N deleted branch dev_server_live_handshake 2026-05-07 23:10:26 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
luca0N/lanbassador!69
No description provided.