Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
CVSROOT: /cvs Module name: cvsnt Changes by: arthur.barrett at march-hare.com Fri May 21 04:38:39 2010 On host: 2002:71c0:aa2:1:20c:29ff:fe0d:b365 Directory: cvsnt/cvsapi M SocketIO.h CVSNT_BRANCH_2_8_01_3761 1.1.2.7.4.4.2.1 -> 1.1.2.7.4.4.2.2 Bug Id: 5923 Directory: cvsnt/cvsapi/unix M SocketIO.cpp CVSNT_BRANCH_2_8_01_3761 1.1.2.24.4.7 -> 1.1.2.24.4.7.2.1 Bug Id: 5923 Directory: cvsnt/cvsapi/win32 M SocketIO.cpp CVSNT_BRANCH_2_8_01_3761 1.1.2.14.4.9.2.1 -> 1.1.2.14.4.9.2.2 Bug Id: 5923 Directory: cvsnt/mdnsclient M mdnsclient.c CVSNT_BRANCH_2_8_01_3761 1.1.2.26.4.1 -> 1.1.2.26.4.1.6.1 Bug Id: 5923 Directory: cvsnt/protocols M common.cpp CVSNT_BRANCH_2_8_01_3761 1.37.2.34.6.6.2.1 -> 1.37.2.34.6.6.2.2 Bug Id: 5923 M enum_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.1.2.7.4.3 -> 1.1.2.7.4.3.2.1 Bug Id: 5923 M ext_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.4.2.16.6.3 -> 1.4.2.16.6.3.2.1 Bug Id: 5923 M fork_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.4.2.17.6.3 -> 1.4.2.17.6.3.2.1 Bug Id: 5923 M gserver_protocol_ad.vcproj CVSNT_BRANCH_2_8_01_3761 1.2.2.16.6.3 -> 1.2.2.16.6.3.2.1 Bug Id: 5923 M pserver.cpp CVSNT_BRANCH_2_8_01_3761 1.25.2.19.6.2.2.1 -> 1.25.2.19.6.2.2.2 Bug Id: 5923 M pserver_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.4.2.17.6.3 -> 1.4.2.17.6.3.2.1 Bug Id: 5923 M server_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.2.2.17.6.3 -> 1.2.2.17.6.3.2.1 Bug Id: 5923 M sserver_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.1.2.17.6.4 -> 1.1.2.17.6.4.2.1 Bug Id: 5923 M ssh_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.2.2.16.6.3 -> 1.2.2.16.6.3.2.1 Bug Id: 5923 M sspi_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.4.2.22.4.4 -> 1.4.2.22.4.4.2.1 Bug Id: 5923 M sync_protocol.vcproj CVSNT_BRANCH_2_8_01_3761 1.1.2.1 -> 1.1.2.1.2.1 Bug Id: 5923 Directory: cvsnt/src M buffer.cpp CVSNT_BRANCH_2_8_01_3761 1.16.2.6.8.12.2.1 -> 1.16.2.6.8.12.2.2 Bug Id: 5923 M client.cpp CVSNT_BRANCH_2_8_01_3761 1.84.2.141.6.100.2.3 -> 1.84.2.141.6.100.2.4 Bug Id: 5923 M client.h CVSNT_BRANCH_2_8_01_3761 1.21.2.11.8.9 -> 1.21.2.11.8.9.2.1 Bug Id: 5923 M login.cpp CVSNT_BRANCH_2_8_01_3761 1.15.2.12 -> 1.15.2.12.10.1 Bug Id: 5923 M main.cpp CVSNT_BRANCH_2_8_01_3761 1.71.2.151.6.54.2.4 -> 1.71.2.151.6.54.2.5 Bug Id: 5923 M server.cpp CVSNT_BRANCH_2_8_01_3761 1.106.2.210.6.99.2.7 -> 1.106.2.210.6.99.2.8 Bug Id: 5923 M zlib.cpp CVSNT_BRANCH_2_8_01_3761 1.16.2.18.8.6 -> 1.16.2.18.8.6.2.1 Bug Id: 5923 Directory: cvsnt/windows-NT M win32.cpp CVSNT_BRANCH_2_8_01_3761 1.72.2.150.6.44.2.10 -> 1.72.2.150.6.44.2.11 Bug Id: 5923 Directory: cvsnt/windows-NT/cvsdiag M cvsdiag.cpp CVSNT_BRANCH_2_8_01_3761 1.1.2.8.8.43.2.3 -> 1.1.2.8.8.43.2.4 Bug Id: 5923 Log message: Bug5923: make the closesocket() call in commonon-blocking. Lots of other timeout stuff. This update to the software has a lot of changes, but in particular it delivers five major items: 1) additional debugging of 'hang' conditions in particular I/O operations 2) client (requires build 9999) can now 'time out' and retry if authentication fails 3) the server attempts to close sockets during process shutdown much more aggressively 4) the client 'cvs login' command shuts down the socket before terminating 5a) protocols server, pserver, sspi and gserver on windows now use winsock2 with timeouts 5b) protocol ssh on windows uses winsock32 with timeouts 5c) protocols enum, ext, fork, sserver and sync are unchanged (winsock32/no timeout) Explanation of item 2) Environmental issues may cause a client 'hang' during authentication - this can be extremely frustrating to a customer because the product does not provide feedback to indicate if it is a) running; b) running slowly; c) doing nothing. This enhancement now means that if the server does not respond to the authentication in a timely manner than progress messages are displayed. If the progress is too slow the connection is dropped and a new connection established. If the new connection also fails then the process exits in an error state. This behaviour requires the latest client software. Explanation of item 3) For a windows server - if a client terminates without cleanly closing the socket it is possible (even common) for the server process to be unable to close the socket. The default behaviour of the Windows API is to leave the socket open and the put the server process into a wait state until either a) system resources become too scarce; b) some very long period of time has elapsed; c) another process connects to the socket (at which point the socket will be closed). On CVS Suite 2009 and CVS Suite 2008 and CVSNT Community Edtion this results in very different results - but the problem is apparent in both. The customer using CVS Suite 2009 will experience a problem where a client will connect to the server but immediately hang because the server then closes the socket - causing the 'problem' in reverse. Because the client (generally) has a person sitting in front of it - they will become frustrated and ctrl-c the process (terminating it) and try it again. The second attempt is usually successful because the server has destroyed the previous process and a new process is available to accept the connection resulting in the customer experiencing what seems to be a 50% failure rate. The customer using CVS Suite 2008 and CVSNT Community Edition will observe number of idle CVSNT processes on the server - the number of idly CVSNT processes will gradually increase over time. For CVS Suite 2009 or CVS Suite 2008 or CVSNT Community Edition customers the frequency of the problem will vary depending on the number of client operations which do not cleanly disconnect the socket. If the customer is using CVSNT 2.0.x (eg: CVSNT 2.0.41, 2.0.51, 2.0.58) clients then this will be less frequent than if the customer is using the latest CVS Suite 2009 (2.8.x) client. CVS 1.x clients, Eclipse, Netbeans and other clients will also affect how quickly the issue becomes apparent. CVS Suite 2009 customers may notice the problem more quickly because it affects the client due to how the server pool works. The same error occurs just as frequently with CVS Suite 2008 and CVSNT Community Edition but it does not affect the clients - the idle processes remain detached and idle on the server only. Explanation of item 4) All versions of CVSNT handle 'cvs login' as a special case. This command is generally only used with the pserver protocol - and older insecure protocol largely replaced with sspi. SSPI protocol does not use 'cvs login' - it uses the windows authentication token of the logged in user to authenticate with the server - this is more secure and more reliable. One of the side-effects of the 'cvs login' special case is that the client socket is not closed - this is left to the operating system to administer with the process exits. Older versions of CVSNT used this 'trick' often and 'cvs login' is one of the few 'verbs' where it is still used. It is more efficient for the operating system if the client cleanly closes the connection, so this has been fixed.