Einstein@Home keeping TCP connections open?
27 Jan 2013 14:46:48 UTC
Topic 196772
(moderation:
Hello,
I have just noticed that the Einstein@Home program seems to be keeping TCP connections open. More precisely, the TCP connections to the Einstein@Home servers stay in CLOSE_WAIT, apparently forever, even if only the Boinc Client is currently running and no workunits are being crunched.
This being Linux, I use "netstat" to dump the connections, so for example I see:
tcp 1 0 192.168.1.63:39248 130.75.116.34:80 CLOSE_WAIT tcp 1 0 192.168.1.63:39249 130.75.116.34:80 CLOSE_WAIT
i.e. two connections from the local machine to 130.75.116.34:80 (einstein4.aei.uni-hannover.de), staying CLOSE_WAIT.
Probably a bug whereby the connection is not closed locally for some reason. See:
http://www.sunmanagers.org/pipermail/summaries/2006-January/007068.html
"The problem is your program running on the local machine is not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the
connection open."
P.S. Could anyone look into increasing the width of this textarea? 55 chars wide is ridiculously small on anything that's past VT220.
Einstein@Home keeping TCP connections open?
)
Well, the Einstein@Home application normally shouldn't connect to the outside at all (in some BOINC Windows API signal handlers there is something to load the symbols from a project symstore, but only if the program crashes).
einstein4 is the server results get uploaded to by the BOINC Client. It is certainly possible that there is a bug in the upload routines there.
BM
BM
It's very common to see loads
)
It's very common to see loads of connections in CLOSE_WAIT, especially for HTTP where all sorts of interesting proxying is done by ISPs and carriers, with HTTP 1.1 persistent connections and mobile devices adding to the fun.
There's 8 (4 BRP, 2 Gamma, 2 BOINC) on this box to e@h:80 as I type, with 5 and 4 on a couple of other local hosts. On webservers, I often see much larger numbers of connections in this state.
I'm seeing this as
)
I'm seeing this as well:
The funny thing is that the stuck connection is to boinc.ucd.ie (FMAH), so it seems that the boinc client occasionally forgets to close a descriptor used for server communication and gets inherited by all science apps.
RE: Well, the Einstein@Home
)
Without knowing how it works internally, I'm guessing that the BOINC/application interface results in the application owning the file descriptor - so although there may be no explicit connection, connections are made in the context of the application and *appear* to come directly from it (at least as far as 'netstat' is concerned, anyway - see below).