On Sun, 18 Mar 2012 18:18:43 -0400 Brian Hinz <bph...@users.sourceforge.net> wrote:
> However since this is the very first read that takes place in the > handshake, there should not be any data in the input buffer, and because > it's a checkNoWait a blocking read should cause the while loop to terminate > prematurely. Urgh. This code really showed off the poor handling of buffers in the RFB code. If the code was just that, then it would be incorrect yes. "Fortunately", it's a bit more convoluted. If you look at the callers of readVersion(), you'll see that they have a magical boolean called "done". If there is insufficient data, then readVersion() will return success and set done to false. This allows the system to resume reading the version once more data is available. I assume this is done to give some better handling of connecting to stuff that isn't a RFB server as it will prevent the client from locking up. If this breaks in the java version, then perhaps it isn't calling readVersion() the same way the C++ code does? Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
