It uses Diffie Hellman to come up with one-time session key, then have
the server sign this session key to allow the client to verify that
there's no man in the middle.
Use a ping timeout of 3/4 of the ping interval instead of the default
4 minute timeout.
This happens to workaround an issue in the remoting PingThread
implementation which causes the ping to busy wait for the timeout
period instead of keeping the channel alive.
When using HTTP full duplex connections the upstream channel can be idle for
long periods of time and the webserver will time the connection out. Jenkins
sees this and terminates the downstream channel causing the unexpected closure
of the read channel in the CLI client.
Timeout of 15 seconds is based on the 20 second default timeout as seen in
Ubuntu Oneiric Tomcat 6 installations.
Regrettably the CLI client and the CLI server are in the same package, and this doesn't work very well with i18n scheme as we end up having two classes of the same name (and one hides the other in the server.)
So I'm renaming the Messages class on the client, but not the classes itself for compatibility
The issue is that the CLI initiates the upload side of the connection and sends some small chunk, yet Apache never forwads that to Hudson, presumably because it's trying to buffer more contents from CLI, which never arrives.
A similar problem seems to exist for the download side, although various reports (like http://mail-archives.apache.org/mod_mbox/httpd-users/200509.mbox/%3C20050927152742.GA8726@redhat.com%3E) suggests that this is fixed in a relatively recent version of Apache.
Other pages, like http://httpd.apache.org/docs/2.2/mod/mod_proxy.html , seems to suggest that Apache can be configured not to do this buffering, but my attempt to configure them failed, both on Ubuntu and OpenSolaris. It could be my mistake, but the lesson for me is that even if Apache can be configured not to interfere, it's still rather error prone.
On top of that, it's not hard to imagine that other forward/reverse proxy have similar problems --- IIRC, Dean Yu reported a similar problem.
So I decided to let CLI talk to Hudson via a conventional TCP/IP connection, if possible. An extra bonus is that this is more resource efficient on the server side (which was tying 2 request handling for pushing and pulling before this change.)
The downside of this change is that if the client is behind the proxy, or if the server is behind a reverse proxy, this needs an extra set up. I thought this is a lesser evil, as Hudson tends to run inside a corporate network, and this issue is already better understood since JNLP slaves have the same issue.
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@19378 71c3de6d-444a-0410-be80-ed276b4c234a
Kohsuke Kawaguchi