Does VM Role allow UDP traffic?

Question

Hi,

So far I've found that neither Web Role and Worker Role can support UDP traffic. Then does any one know whether VM Role supports? I am planning to migrate my distributed windows service to Azure, but all my inter-process traffic are based on UDP, and some of them are even IP Multicast. Does VM Role support this?

Thanks!

Gambell

Answer 1

In the service model configuration for the vm role you cannot select udp, at least that's what the service definition schema says.

Answer 2

Hi,

This piece of information on MSDN mentions that UDP can only be used when combined with Azure Connect. See a snippet of this article below.

Note also that a server instance running in Windows Azure is subject to certain limitations that an on-premises installation of Windows is not. Some network-related functionality is restricted; for example, in order to use the UDP protocol, you must also use Windows Azure Connect. Additionally, a server instance running in Windows Azure does not persist state. If the server instance is re-created from the image, either because the operator requested a reimage or because Windows Azure needed to move the server instance to different hardware, any state associated with that instance that has not been persisted to a durable storage medium outside of the virtual machine is lost.

Hope this helps.

Edward

Answer 3

 

As far as I know, UDP traffic is currently blocked, and there is no way around it even with Admin Startup Tasks and VM Roles.

Also, I would not recommend using Windows Azure Connect tunnel for high-volume UDP communication between instances, because Windows Azure Connect itself uses a SSTP (SSL) connection internally.

 

The performance/latency with UDP over Windows Azure Connect will be much worse than if you just use plain TCP for inter-role communication.

 

Answer 4

Thanks, Edward. This is helpful!

Answer 5

Thanks, iquazee!

This is really a bad news for my project, which focus around performance improvement...  :(

 

Answer 6

You can vote for UDP endpoints here (currently it's the 11th most requested feature):

http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/400782-udp-endpoints?ref=comments

While adding internal UDP endpoints seems to be an easy enough task (just relax the packet filtering on the hosts), implementing public UDP endpoints will probably require some sticky session support on the load balancer (and currently, there is no sticky session support).

If incoming packets are delivered randomly to instances, two-way UDP communication will not work properly if there is more than one instance behind the Virtual IP.

Answer 7

UDP is a connectionless protocol.  As a baseline, sticky sessions should not be necessary although some higher level protocols layered on top of UDP will keep state and need to be adapted to use AppFabric Cache or another shared state mechanism.  

Internal UDP endpoints (particularly if local intra-role multicast works) would allow us to distribute state efficiently for the external ones but some apps could get away with AppFabric, SQL or Tables.  SQL and Tables would be too slow for game realms that need to see their neighbors and AppFabric would probably be overly convoluted and expensive if not too slow.

External gets you the ability to do DNS, game protocols, streaming protocols, DHT and any number of other useful things.

I personally have need for internal multicast (so intra-role IGMP support as well) and external unicast UDP support.  I'd be perfectly happy to deal with the state issues myself and I know a lot of people could probably get away with running a single-instance for some purposes which would obviate the need for sticky sessions or distributed state.

I also have need for sending ICMP EchoRequest outbound and receiving the variety of possible ICMP reply types (I don't care about unrequested inbound so this wouldn't even be an endpoint) and again I really don't care about sticky as I can work around that.  I really need the reliability and scalability Azure brings for the application I have in mind.  I've got several ideas for applications that could be really big only there's a major feature missing from either Azure or Silverlight that prevents each of them -- it's very frustrating. 

Why not just allow connectionless protocols without sticky as it should be relatively easy and see how many people care about adding sticky and to what protocols?  I'll bet you a fairly significant percentage of people that want this can work around not knowing where replies will end up.

One thing that irritates me about the lack of udp is even if we can work around it with REST, that greatly magnifies the bandwidth consumption which costs us money.  I'm hoping that doesn't factor into the decision to continue not supporting UDP as that would be highly unethical.  The same would go for flogging AppFabric rather than allowing us to do lightweight and far less expensive DHT caching in our own roles.

 

Things I'm still waiting on -- in no particular order: UDP, Dual-stack IPv6, CDN logging, outbound ping, reverse dns, blob/cdn adaptive streaming, and more complete socket support (Bind/Listen/additional protocols) for authenticode signed Silverlight apps.