views:

55

answers:

2

Hi SO,

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

+1  A: 

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.

Eugene Mayevski 'EldoS Corp
Thanks for your comments - I can't see it being moved to the swap so soon. The socket / footprint is very small and data comms between the two are only a few kb.Do you have any suggestions on how to check what's happening with the memory in .NET?
DaveHogan
Do you mean that data comms after a minute are only a few kb? I.e. did you check renegotiation case, taking (or not taking) place after a minute of inactivity?
Eugene Mayevski 'EldoS Corp
@DaveHogan There are tools for tracking memory management activity in .NET but I am not aware of particular titles (not my area of expertise). Also, SSL/TLS itself is implemented in CryptoAPI, not in .NET so if anything happens on CryptoAPI / CNG level, .NET tools most likely won't track it.
Eugene Mayevski 'EldoS Corp
A: 

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.

wal