Open woodiertexas opened 1 year ago
Any reason why this is an issue?
So the problem that's being referenced here is in a blanketcon-specific optimization where they use zstd compression on the networking stack. With the current behavior, the server can prepare uncompressed packets before the client's reply is handled. This means the client expects zstd-compressed packets and receives the uncompressed packets instead.
In other words, The QSL networking API is based on the assumption that login query packets do not have side-effects. Is that a reasonable assumption, (and the blanketcon usecase a one-in-a-million exception), or should we change the QSL networking API to send and handle login query packets one at a time?
Apparently QSL inherits the
ServerLoginConnectionEvents.QUERY_START
stuff from FAPI. What it should be doing is sending requests and responses one at a time instead of all at once.