Can IIS / ASP.NET make use of the TCP keepalive option to detect dead connections? Note that these connections do not have the HTTP Keep-Alive option in effect. These are connections, just abandoned by the clients, leaving IIS / ASP.NET threads hanging, waiting for data. Are there mechanisms in place by which IIS / ASP.NET handles such scenarios?
IIS has the option to open the connection as with TCP KeepAlives enabled, but all research suggests it uses the system setting for it. The system defaults to enabled with 2hr KeepAliveTimes.
http://support.microsoft.com/kb/120642 has references for registry values.
ASP.NET only handles HTTP data sent over the connection, the period where there is no HTTP happening, but the TCP connection is kept alive means nothing to it.
IIS will not keep the TCP connection alive indefinitely, but periodically checks them for idleness.
Related
The old SSL certificate has expired and I want to renew the SSL certificate. However, the server already has established multiple links with other clients. So, can I just bind the old sockets to the new ssl, which means I don't need to disconnect the old base tcp links?
Existing TLS connections don't need to get updated with a new certificate - the server certificate is only checked at the beginning of the TLS connection. If your specific server supports updating the server certificate without a restart and thus without closing established connections is unknown - some do and some don't.
I have written a basic TLS client for use in embedded systems (written in C). It uses TLS1.2, and it works great in 90% of situations. I have it working fine for HTTPS, and also have it working with various FTP servers using implicit and explicit FTPS. This week I've encountered an issue when using it with Cerberus FTP and proftpd though. TLS handshake goes through absolutely fine when opening the control channel on port 21, but when using passive mode and opening the passive port, my client sends the TLS Client hello (and I can see the server reply with a TCP ACK), but the FTP server never replies with a Server Hello. Does anyone know of a reason why that might be?-I'm guessing that there is something different in the way Cerberus and ProFTPd have implemented TLS that my client doesn't cater to. My client hello on both connections is identical (apart from port number in tcp headers) and I am not reusing the session data. I don't have this issue when testing against vsftpd or filezilla servers.
Found the reason for the lack of response, and it's an interesting one if anyone is ever writing their own FTP Client and need to use FTPS with it. The FTP Client I had written issued the PASV command, and then immediately opened the data channel port before then issuing the STOR command on the control channel. This behaviour is fine for all FTP servers when using un-encrypted FTP. However, as I discovered, you have to beware when using TLS. With proftpd and cerberus FTP, the FTP server doesn't seem to attach a listener to that port until you issue the STOR command (or equivalent), so it won't negotiate TLS on that port until you've issued the command, whereas other FTP servers like vsftpd and filezilla are happy to negotiate TLS as soon as the port is opened. SO the solution was to open the port after sending the STOR command.
I am working on a small application on an embedded platform which has to send some classified information to a server. This connection to the server is encrypted using SSL. The encryption is tunneled trough a proxy - in this case a Zentyal proxy. The embedded application is written in C and the connectivity part is done with wolfssl and lwip.
The application works fine with Zentyal 5.1. But recently the proxy server was updated to 6.1 and now the connection is falling all the time. Debugging the issue, I have found the problem occurs when the application ask the server for a tunnel connection. What I see happening is that the application sends the CONNECT request to the proxy ...
... to which the the proxy answers with a 200 Connection Established.
But after that packet is received the proxy send another message with Proxy-Coneection:Close. Whith has the effect that the connection is shut down before the SSL handshake.
I have tried different configuration in the Zentyal (transparent proxy enable, disable cache, etc.) but the error remains the same. Also, I have added different HTTP headers like proxy-connection: Keep alive. But the connection is still being closed.
Maybe this is a problem with the 6.1 version. I have tried looking through the change log but there is no reference to any change in the processing of the connect request. Neither are there any known problems related to the way the connect is being handled.
Any advice?
During app loading a single user will add 10 connections to the pool. Then if I load another user I will have a total of 20 connections.
Why are new connections being added to the pool instead of reusing connections? I can see that that there are connections available that haven't been used in minutes yet it still opens new connections.
Its the same connection string
I ran SQL Sever Profiler I can see sp_reset_connection being called after every call.
Any help would be appreciated.
If the connections are coming from a different machine, the connections can't be pooled. A connection required both endpoints to be a connection. If you are using connection pooling correctly, applications instantiate a connection (from the pool), use the connection, then drop it as soon as exchange is complete.
If you a writing a single-threaded desktop app, another common and simple strategy is to open a connection, and just leave that connection open as long as the application is running.
You can control how many connections are created, etc. see MS article for more details related to connection pooling.
IIRC, connection pools are not shared unless the connection string is identical either.
I have setup a nagios distributed monitoring system environment and i am able to send passive checks to Nagios server using send_nsca. When i look at the handshake between Nagios Client and Nagios Server, i see that Nagios Client is establishing a tcp connection to Nagios server whenever it has something to send and terminating the connection once the client is done sending the information. I want the tcp connection to stay up forever instead of terminating every time after data transfer is done. Could anyone please let me the know the process to make this happen?
You cannot do this without modifying the standard NSCA daemon. Normally, it will time out and that's why the NSCA client reestablishes the connection.
I've implemented send_nsca in both Perl and Ruby, and in both cases cannot make a persistent connection work.
A better solution, though, if you are using Nagios 3.x is to install the livestatus module (part of check_mk). This allows passive checks to be submitted, but supports a persistent connection and a whole lot more. We've moved to using this instead for many cases.