Paul Donohue wrote: > He's essentially looking for the ability to encapsulate packets from another > network connection in an RFB message, which doesn't really have anything to > do with encryption (I think the only reason ssh was mentioned is because ssh > just happens to have the ability to encapsulate network packets in an SSL > stream, which from a user's perspective appears to be similar functionality). > > The RFB protocol really wasn't designed to do this kind of thing ... RFB is > built around framebuffer updates, and it is assumed that very little data > other than framebuffer updates will be transfered. That's not to say that > you can't use RFB to encapsulate another network connection, but the > encapsulated traffic and framebuffer updates will be constantly fighting for > the connection, so latency will likely be high for both.
Sharing a single real TCP connection for multiple embedded connections shouldn't necessarily cause problems - it works fine for ssh, after all. The main problem I see is that RFB framebuffer updates are sent as a single large message, which can cause latency problems for other traffic. For my purpose this is not a huge issue. > However, I agree this would be a useful feature for those times when you > don't really care if it is a horribly ugly and inefficient hack as long as it > gets the job done (kinda like file transfer via RFB). Why does it have to be horribly ugly and inefficient? Do you also consider the port-forwarding mechanism in ssh to be a horrible ugly hack? Other than the large framebuffer update messages causing latency problems for other traffic, I don't see what the issue is. I've started looking at embedding an implementation of the ssh channel concept described in RFC 4254 in RFB. Cheers, Thomas ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
