0004178: Segmented launcher protocol issues

Chat on our Discord Server Get the latest version: 3.2.1
Source Code

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004178

Zandronum

[All Projects] Bug

public

2023-12-31 13:43

2025-11-08 00:02

Reporter

duke

Assigned To

Priority

normal

Severity

minor

Reproducibility

always

Status

resolved

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0004178: Segmented launcher protocol issues

Description

The 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.

Attached Files

Relationships

Notes
(0023307) Fused (reporter) 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.

(0024645) duke (reporter) 2025-11-07 21:53	This has been addressed and should be marked fixed

(0024646) Doomjoshuaboy (developer) 2025-11-08 00:02	resolved from this commit:'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/bb95a756132569a8227e9c76746517d64530f5dd [^]'

**Issue Community Support**
This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2023-12-31 13:43	duke	New Issue
2024-03-07 08:26	Fused	Note Added: 0023307
2025-11-07 21:53	duke	Note Added: 0024645
2025-11-07 23:54	Doomjoshuaboy	Status	new => resolved
2025-11-08 00:02	Doomjoshuaboy	Note Added: 0024646

Questions or other issues? Contact Us.

Links

Doom and Doom II are the property of id Software.