CODEWITHSUNDEEP
c#socketssslsslstream
Dave Hogan
Dave Hogan

Reputation: 3221

SslStream Delays after inactivity

I have written a client app to talk to a third party server app. Its comms is over a custom port with SSL usng the SslStream class.

The server allows permanent connections however I've found I have to ping the server with a command within 60 seconds to maintain a reasonable level of responsiviness. After 60 seconds the comms still works but there is a noticable delay in receiving a response. It's not dropping the connection and reconnecting. It just takes longer than usual. Sending another command within 60 seconds is quick again. Sending another command after 60 seconds causes delays.

It's as if after 60 seconds the SslStream re-negotiates with the server doubling the transit time. I know SSL is session based, could this be the cause? Is there anything I can do, other than sending unnecessary commands to the server App to keep it alive?

My code is the below (snipped):

 var client = new TcpClient();
 client.NoDelay = true;
 client.Connect("111.111.111.111", 6969);
 var sslStream = new SslStream(client.GetStream(), true, new RemoteCertificateValidationCallback(ValidateServerCertificate), null);
 sslStream.AuthenticateAsClient("111.111.111.111");

...

// The following method is invoked by the RemoteCertificateValidationDelegate.
private bool ValidateServerCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    if (policyErrors == SslPolicyErrors.None)
      return true;
    else
      return false;
}

Hope someone can shed some light on this!

My client app is written in: C# / .NET 2.0 & 4.0 Hosted on Windows 2003 and 2008

Thanks

Upvotes: 1

Views: 1005

Answers (2)

wal
wal

Reputation: 17739

If you want to know what is going on at a low level then instead of using SslStream try using the open source SSL library from Mentalis.org

They provide a class called SecureTcpClient which you can drop in to replace TcpClient.

WARNING: This library has been designed for the .NET 1.0 and 1.1 frameworks. It is not intended to be used on the .NET 2.0 framework; this framework supports most of the functionality that the Security Library offers. I would only use this to figure out what is going on.

Upvotes: 1

Eugene Mayevski 'Callback
Eugene Mayevski 'Callback

Reputation: 46060

In general, SSL supports renegotiation so this can really be the case. Another reason might be that the part of the code, executed by the server, is swapped to disk after a minute of inactivity, to free operating memory. When you send a request, this memory should be read again. If the block is large, this can take some time.

Upvotes: 1

Related Questions