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