Dear Mike, >> You have the new, patched nxproxy on both ends of the connection? >> The encoding of the data has changed. > ... > nxagent and nxproxy are installed onto different systems from > different sources ... > So, this should be handled by your code then, I guess.
The encoding must change: some lengths must be sent; with BIG-REQUEST they can be larger than 16 bits; and (for super-efficiency reasons?) they were encoded into just 16 bits. I see no work-around other than to change the encoding to 32 bits, as I did in my patch. Please let me know if you can think of some other way. The best that could be done is for nxproxy to detect the version used on the other end, and refuse to talk if they did not match. Please let me know if you think that would be worthwhile to pursue. In the past, I see exactly similar, incompatible version changes, e.g.: - dxpc 3.9.0 being incompatible with earlier versions http://www.vigor.nu/dxpc/README - NX 3.5.0 issues with NoMachine 4 https://www.nomachine.com/AR10I00603 I guess such is the price of progress, of having made the wrong design choices (as seen in hindsight). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
