It can fire from the network thread before we have had a chance to increase the limit.
Will need to apply to 0.3 too..
Here is a very simple test case:
=================================================================== --- src/xpra/server.py (revision 1046) +++ src/xpra/server.py (working copy) @@ -1140,6 +1140,8 @@ modifiers = capabilities.get("modifiers", []) log("setting modifiers to %s", modifiers) self._make_keymask_match(modifiers) + large_buffer = " "*(1024*1024) + self._send(["dummy", large_buffer]) # We send the new-window packets sorted by id because this sorts them # from oldest to newest -- and preserving window creation order means # that the earliest override-redirect windows will be on the bottom,
By that point, we have already sent the hello back so a 1MB packet ought to be fine... but we see on the client:
connection lost: invalid packet: size requested is 1048576 (maximum allowed is 32768), dropping this connection!
What makes this much more likely to fire is r1014: we wait before sending the hello to get the real screen dimensions... which means we allow cursors and new window packets to be sent before the hello!
They should all come after it!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/160