Re: [Tigervnc-devel] The deferred update timer
On Thu, 01 Dec 2011 18:01:32 -0600 DRC dcomman...@users.sourceforge.net wrote: When the deferred update timer behavior was recently overhauled such that it pushes out updates whenever the timer is triggered rather than waiting for an update request from the client, the default DUT value was also changed to 10 ms (from 1 ms.) Unfortunately, setting the DUT to 10 ms results in a dramatic decrease in peak performance on high-speed networks. The reason is that, when the timer is set, all X updates that arrive between that time and the time it is triggered are coalesced. As soon as the timer is triggered, a framebuffer update containing all of the coalesced X updates is sent immediately, then the server is tied up sending the update and cannot process any new X updates until the update is sent. Once the update is sent, then the first new X update starts the deferred update timer again. Effectively, what this means is that the frame rate is capped to 1 / (deferred update time + encoding time), and since the encoding time is typically about 20 ms for a 1280x1024 screen, setting the DUT to 10 ms caps the frame rate at about 30 Hz for such a screen, whereas previously it was near 50 Hz when the DUT was 1 ms. Annoying. I did some work at making the thing more asynchronous, but more might be needed. If the problem is getting the data on the wire rather than the actual encoding, then a quick fix is increasing the outgoing buffer size. As long as your entire update fits in there, then X won't be throttled (and the update timer should also be more precise). Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] Can we *please* revisit the reply policy on this list?
On Wed, Nov 30, 2011 at 05:43:44PM -0600, DRC wrote: When we created this project a couple of years ago, it was decided (I was outvoted) that mailing list replies would go to the user rather than the list, but we are losing a lot of information this way. People will typically hit Reply rather than Reply All, and their response will go only to the poster, even though the information is relevant to the entire list. Thus, we are in some cases losing records of solutions to problems or vital diagnostic information that could be useful to someone searching for a solution to the same issue. Can we please re-visit this? I don't remember if we discussed this but you have my vote, all replies should go to ML by default. Regards, Adam -- Adam Tkac, Red Hat, Inc. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] TigerVNC + noVNC: Security options?
The missing parameters is an easy fix, I'll commit those changes for the java viewer tonight (FYI, the Fltk viewer does not currently have those parameters so if you need that functionality you should submit a feature request to get them added). As for password-less authentication, you know that X509none just uses X509 certificates to check the validity of the endpoints, right? It does not prevent a user with a valid (ie: non-revoked) certificate from accessing another user's session. Although I guess you could probably do something like use a different CA to generate each user (or group of users) certificate and thus limit access, but for anything other than a small number of users this is likely to become difficult to manage... -brian On Fri, Dec 2, 2011 at 9:45 AM, Dan Garton dan.gar...@gmail.com wrote: Many thanks for your replies, just catching up now On 30 November 2011 19:05, Martin Koegler mkoeg...@auto.tuwien.ac.atwrote: This mandates a minimum of a secure authentication stage, and then the client can be configured (but not forced) to encrypt the session traffic. No. The client may choose between one of them. Either the session is unencrypted (VNCAuth) or using the VeNcrypt+TLSVnc protocol (encrypted). Understood. This works in my situation as follows for the 2 different clients I am employing: 1) Tiger VncViewer.jar: - uses TLSVnc 2) noVNC: - does authentication with VNCAuth, and then session traffic is SSL encrypted using websockify ie. *noVNC*ssl*websockify*---clear---*tiger_server* which I think is OK as long as the communication between the websockify proxy and the tiger server is on a trusted network. I'm not aware of any transparent signon. TigerVNC only allows: * No authentification * Classic VNC authentification * Authentification with username/password (default authentification provider is the system authentification) It would be possible to extend SSecurityTLS/CSecurityTLS to send/verify client certificates and use this with X509None. This would result in a passwordless login solution based on certificates - but you would have to extend the code. Ok, I must admit this has confused me a bit. Your email at http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg01013.html suggested to me that X509None *already* allows for a passwordless login based on certificates, and you also listed the options used on both server and client sides for this. Though in a recent email conversation with Brian H, he told me that the trunk version of VncViewer.jar was still missing the parameter-passing logic for these options. I have a feeling that I'm still missing some understanding here though ... please feel free to correct me! :-) Thanks, Dan G -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
Re: [Tigervnc-devel] TigerVNC + noVNC: Security options?
On Fri, Dec 02, 2011 at 02:45:45PM +, Dan Garton wrote: I'm not aware of any transparent signon. TigerVNC only allows: * No authentification * Classic VNC authentification * Authentification with username/password (default authentification provider is the system authentification) It would be possible to extend SSecurityTLS/CSecurityTLS to send/verify client certificates and use this with X509None. This would result in a passwordless login solution based on certificates - but you would have to extend the code. Ok, I must admit this has confused me a bit. Your email at http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg01013.html suggested to me that X509None *already* allows for a passwordless login based on certificates, and you also listed the options used on both server and client sides for this. No. x509cert and x509key of the server are the crendentials, with which the server will prove its identity. x509ca + x509crl on the client are used to check the server identity. This is the same procedure, as any normal https website works. For passwordless logins, you need client certificates. The client needs a certificate and it's key and the server needs the ca + crl to verify it. gnutls has the support for this, but some glue code is missing. If you don't know the whole client certificates thing, I suggest to start reading the apache httpd mod_ssl documentation (especially SSLCACertificateFile). Regards, Martin -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
