Is Azure Web Role designed to host a permanently opened TCP connection?

Question

I have a Web Role deployed on Azure which open a TCP connection to a remote server using socket (C#). This connection MUST be always opened. After twenty minutes it seems the connection is lost.

So I'm wondering if a Web Role is designed/can host a such connection? Is there any automated process that could close the TCP connection (recycling for instance)?

The running code works fine on my computer and worked well when I was using a 'standard' Windows Service on a dedicated server.

Thanks for your help, Jerome.

Answer 1

I've finally found a solution that matches my requirements. My TCP connection was closed due to role recycling. Following the solution described here: Disable IIS Idle Timeouts in Azure Web Role, I was able to configure the IIS AppPool when I deploy my service.

So basically I need to disable:

• idle timeout (20 minutes by default)
• period role recycling (was set to 29 hours by default)

Thanks all!

Answer 2

You have to change your architecture when moving to the cloud. In the cloud, at least the most commonly used cloud there is no such thing as 100% availability at first place. So no "always opened".

Next, there are quite a lot of factors that could close your connection. Over some you have control, over others you don't. Here is some non-conclusive list:

• Role recycling due to hardware failure (you have no control)
• Role recycling due to OS update (you have control - set specific OS version, but not recommended)
• Idle connection timeout (you have control - keep connection alive by sending packets at regular or irregular intervals, but do not keep connection idle more than 60 seconds)
• something else

In order to provide all users equal opportunity to use cloud resources, every cloud provider will try to manage these resources at best possible way. One such resource is TCP Sockets.

With Azure if a connection (any connection) is idle more than XXX seconds (this number has changed over time, so I don't want to quote any specific number, just assume it is 1 minute) it is being terminated.

At the end - there are too many factors in the cloud that would close your connection, so begin thinking the cloud way - implement retry logic in your protocols, and implement healing logic in your service. Last but not least - never use a single instance role if you seek high availability.

One interesting reading on connection timeouts can be found here. Although it only refers to connection within same datacentre (within roles and VMs) it is still worth reading.

And interesting update you have added - "I am connected to financial markets". Even so, you have to question 100% uptime vs. 99.95% uptime, which is the standard SLA for WebRoles with 2 instances. Never said it is easy, but you could achieve 99.95% availability with a minimum of 2 instance of a webrole (or worker role) and some kind of a watchdog that monitors for the connection. Always keep only one connection, if that goes down - immediately (when detected) open another connection. Keep required data in a redis cache for instance, or Azure Cache, or In-role Cache configured for high-availability.

There are solutions for high availability in the cloud. But if you look for 100%, this is not your place. There is no 100% SLA in the cloud.

Answer 3

I suspect you're being disconnected because of the load balancer used in Azure. It used to disconnect idle connections after a minute, but I believe that this was changed to be 20 minutes (I can look for a reference for this later and update this answer accordingly).

The important part to note here is that it's only idle connections it terminates, so if you are using the connection it shouldn't disconnect you (although I have a sneaking suspicion that there may have been a maximum connection time as well).

Also note that by default IIS in an Azure role will recycle the App pool after 26 hours. This can be changed through changing IIS settings in a startup script.

Also any instance in Azure can be recycled at any time. It doesn't happen very often, but you can't stop it from happening. Your web role does receive an event to say this is happening though of you need to take some kind of action.

All this adds up to the fact that your remote server will need to be more flexible with the way it deals with this connection if you want to host in Azure.