[Added new info – 05/31/2012] Around April-May 2012 time frame Windows Azure migrated to use software Load Balancers and because of that the 1 minutes problem is gone as the default timeout is larger then 1 minute depend on number of current connections.
If you are already a Windows Azure user you may have already know every application running in Windows Azure is running behind hardware based Load Balancer. Or if you are a new Windows Azure user, it is good to know about Windows Azure Load Balancer. It does not matter if you have 1 instance of more than 1 (hundreds or thousands), all of these instances are running behind Load Balancer.
Windows Azure load balancer manages communication between the your Windows Azure application, which is running in specific Data Center and external internet i.e. the user using the Windows Azure application.
So if you have your application running in Windows Azure i.e. yourservice.cloudapp.net and you ping to it, the IP address you will get is actually the Windows Azure Load Balancer IP address. Your Windows Azure application (all of instances) does not get a dedicated IP address instead you will get a virtual IP address (which remain same unless instance is deleted) hiding behind the Load Balancer.
Windows Azure Load Balancer uses 1 minute (60 seconds) timeout value which cannot be altered by any means so when you write your Windows Azure application (a simple web app, WCF service or anything else) you must consider the fact that if your network communication between the source machine and Windows Azure Application is idle for more than 60 seconds the connection will be disconnected. This may impact your application depend on your application scenario. For a Windows Azure application which is just a web role if you leave the browser open for more than a minute you will see the web browser shows the error “Internet Explorer cannot display the page”. Now you just refresh the page and the web content is back on your browser page. If you have had an authentication done in your webpage and the connection if idle for 60+ seconds now your connection is disconnected and if you wish to keep working on the same page, you would need to re-authenticate the connection again as 60 seconds timeout was executed by Load Balancer for the active connection and the connection is no more there. So there could be several examples to consider how 60 second Load Balancer timeout will affect your application.
For example, If you have ASP.NET Web Role running in Windows Azure, you can verify that after 1 minute of inactivity w3wp.exe process which is running your ASP.NET Web application, is gone in the Azure VM. If you refresh your browser from client machine the new connection is established to Azure Web Application via Azure Load Balancer and w3wp.exe process is active again.
In another example if you create a WCF based REST service and deployed this application to Windows Azure and configured correctly to work perfectly. The application will work absolutely fine if the HTTP request could be processed within 1 min.
If service takes more than 1 min to process the request then Load Balancer will resend the same request again. Because of it, load balancer will shut down the connection soon after it.
The time-out set at the load balancer, restricting the request time-out to 1 min. Based on the request to the data-center, if this time is exceeded to process the request, then it time out. So now the question comes how you can workaround this scenario if your application is impacted with it.
Here are some suggestions:
 – You can make sure the TCP connection is not idle. To keep your TCP connection active you can keeping sending some data before 60 seconds passes. This could be done via chunked transfer encoding; send something or you can just send blank lines to keep the connection active.
 – If you are using WCF based application please have a look at below link:
 – If you are using TCP Sockets then you can also try ServicePointManager.SetTcpKeepAlive(true, 30000, 30000) might be used to do this. TCP Keep-Alive packets will keep the connection from your client to the load balancer open during a long-running HTTP request. For example if you’re using .NET WebRequest objects in your client you would set ServicePointManager.SetTcpKeepAlive(…) appropriately.
More details on MSDN:
A few great articles and forum discussion on this topic:
Sincere thanks to Windows Azure Team to provide above information.