If you experience problems with your Windows Azure development fabric (the compute emulator) that gets really slow at opening new outbound TCP connections, then it might be because the TCP connection pool are getting filled with TCP connections stuck in the TIME_WAIT state. TCP connections are a limited resource so only a limited number of connections can be opened at any given time, this number can be increased, read here for how to. But that is typically not the right solution because connections if closed properly they shouldn’t be hanging in the TIME_WAIT state.
You can check which process that is using excessive numbers of TCP connections by running netstat -ao from the command prompt. If you see a lot of connections in state TIME_WAIT to port 15095 then you are most likely experiencing the same problem that I have been having lately on my development laptop.
Port 15095 is used as the management service port for the windows azure development fabric (C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\devfabric\DevFX.exe). The windows azure SDK tool, DFAgent.exe is trying to connect to port 15095, on my machine that was working fine when I was on the domain network, but on a the public network this was blocked by the windows firewall. I don’t know why the windows azure SDK only configure the appropriate firewall exceptions for the network you are attached to when you install it, but adding adding the firewall exception to the public network, fixed my issue with excessive TCP connections opened to port 15095 on my machine.
Another issue that you might have with the Windows Azure dev framework is that you are unable to start the emulator from Visual Studio after you have had it started before. This can be fixed by manually terminating the process DFMonitor.exe from the task manager, as it’s not always closed properly when the emulator is shut down.