MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0004178Zandronum[All Projects] Bugpublic2023-12-31 13:432024-03-07 08:26
Reporterduke 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0004178: Segmented launcher protocol issues
DescriptionThe new segmented launcher protocol that addresses 0004064 has been in use for some time in Zandronum 3.2 betas and is implemented by at least Doomseeker, but unfortunately there is still one oversight that makes client implementations more complicated than they were meant to be, and the current design also doesn't 100% prevent large packets.

I don't mean to complain or urge changes, I just wanted to have these issues documented at least in this ticket.

1) The first oversight in the segmented protocol is that SQF_NUMPLAYERS can end up being sent in a different packet from SQF_PLAYERDATA (and this does often happen in practice). This means clients are forced to collect all packets of the response, sort them (UDP doesn't guarantee order) and only then parse, otherwise they may not know how many SQF_PLAYERDATA sections are present. The new protocol tries to avoid this in another case within SQF_PLAYERDATA by adding a new "segmented only" flag, but the same problem with SQF_NUMPLAYERS was overlooked. I don't see it as a big problem that clients have to gather+sort response packets before parsing, but it does make the new "segmented only" flag in SQF_PLAYERDATA a pointless complication.

2) The second issue/limitation is that if you host a server with a large number of wads with long filenames, you can go over the packet size limit and the packet will not be split, because all SQF_PWADS are always sent in one packet. This would still prevent people with picky networks from joining these servers. It is not really a bug but deliberate design choice, but I think this limitation should be explicitly documented somewhere for server hosts.

While issue no. 1 already forces clients to gather+sort responses, the segmented protocol might as well work by simply splitting the packets into eg. 1200 byte chunks without regard to contents, and have the clients stitch them together and parse as if the response was never segmented. This way the new segmentation-related response fields could be dropped and both issues would be addressed.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2023-12-31 13:43dukeNew Issue
2024-03-07 08:26FusedNote Added: 0023307

Notes
(0023307)
Fused   
2024-03-07 08:26   
+1 on just sending packets in small burst and having the client collect them. I suppose as long as packets are guaranteed to arrive in order it's not an issue that things like playercount arrive earlier than actual players, but if this cannot be guaranteed there should be some guarantee in place that they arrive together. I have never seen an instance where this is not the case but from my understanding UDP does not have any guarantee that the order is maintained.