On Wed, 17 Oct 2007 10:43:51 -0400, Steve Bireley <[EMAIL PROTECTED]> wrote:
>The most expensive part of the connection is the public key exchange during the SSL negotiation. This negotiation occurs every time the control or data port is opened. In a multiple file transfer scenario, each file transfer results in the data port being opened and closed. Man y small files being transferred should use more CPU than one large file being transferred. I am not sure if SSLServ supports session caching (reuse of the session keys) to lessen the CPU impact of the key exchange, or if the FTP clients can even support it. I will check the RFC for that . > >Steve Bireley >Vice-President >Product Development >BlueZone Software >1-404-364-1731 >www.bluezonesoftware.com >"BlueZone Secure FTP is now Free" > I'm concerned with TN3270, not FTP, but I think the principle is the same . The Performance Report says about session caching: "Telnet Connect/Disconnect The SSL protocol allows a cache of recently generated handshake output in order to eliminate much of the handshake overhead in cases where a given client makes repeated connections. The first time the clien t connects, the client and server go through the complete handshake and the resulting handshake output (session id plus associated information) is saved in the server's cache. This is referred to as a new session. The next time that client connects, it may pass the session id to the SSL server and if a valid copy of it is found in the server's cache, most of the handshake is bypassed. This case is referred to as a resumed session. Whether or not this resumed session optimization is used is up to the client. Clients that include connect/disconnect in their mainline path (such as http browsers) are likely to use this optimization. Clients such as FTP and Telnet that establish a connection and then use it for a (potentially) long conversation are less likely to support this optimization. It turns out that IBM's eNetwork Personal Communications terminal emulator application (PCOMM) does both. When a disconnect and connect are done manually from the Communication menu, the optimization is not used and consequently all sessions are new sessions. When the disconnect is done implicitly by logging off the remote system and the auto-reconnect option is checked, the optimization is used and all sessions except the first are resumed sessions. This characteristic allowed us to measure both the new and resumed cases." We don't have PCOMM, but QWS3270 Secure, so I don't know what our situation will be. It appears I can count conntects simply by counting these messages in the TCPIP service machine log: DTCSTM163I Telnet server: Conn 1:Connection opened 10/18/07 at 00:19:08 DTCPRC150I Foreign internet address and port: net address = 165.44.75.39, port= 1774 DTCSTM132I Conn 1: Ldsf device 0000000A created Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
