Azure supports the UDP networking protocol but does not support UDP broadcasting. If you are a networking super hero, then you have no problem understanding what that means, but if your networking skills have become a bit dusty or they are on your todo-list, here follows a short description of what works and what doesn’t work in Azure when it comes to the UDP network protocol.
UDP protocol
The UDP protocol differs from TCP in that you don’t have a connection between the sender and receiver. The sender simply fires away datagrams and has no knowledge if the receiver gets the data or actually even listens. The DNS and DHCP protocol are two common protocols that uses UDP. The similarities with TCP is that it still requires ip addresses and a port number. DNS uses port 53 for instance and computers does a name lookup via sending a UDP message to an ip address of a DNS server. UDP differes from TCP in that it can send its message not just to one ip address, like a web server, but send it to anyone who listens on the network. The DHCP protocol uses this broadcast function of UDP when a computer with dynamic ip address asks for the availability DHCP servers. This type of sending data is called UDP Broadcasting, because the sender sends it to anyone listening.
UDP Broadcasting on a local LAN
I’ve written a small C program that acts both as a sender and a listener that will demostrate what works locally and what works in Azure (see github link below).
In the below screenshot the client sends four messages. The first is directed to localhost, the second to the ip address of my machine (192.168.156.124), the third is a broadcast message to all listeners on my subnet (this is why the last octet is .255) and finally the fourth is a brodcast to *.*, ie to whoever might be listening on the port.
The server output is as follows. I start the server program on the same machine and tell it to bind to ip address 0.0.0.0 which basically means “listen on this port on whatever NICs are available on this machine”.
The messages received matches what is sent. The first received message is from 127.0.0.1 as it is specifically sent to localhost. The second is no surprise as it was sent to the specific ip address. The last two are broadcast messages that are picked up by the server program since it is listening to the port. Other programs on other machines that were listening to the same port would have picked up the last two messages also.
So, locally on my LAN, direct UDP and UDP broadcasting works.
UDP Broadcasting on Azure
In my Azure environment I have two Linux Ubuntu servers running the same UDP test program. The server has ip address 10.10.1.4 and the client has 10.10.1.5. When repreating the test on Azure, this is the output:
Since they are on two separate machines, I skip the 127.0.0.1/localhost test since it is meaningless. I do send three UDP messages where the first is direct to the listening server (10.10.1.4), the second is a broadcast on the subnet (10.10.1.255) and the third is a broadcast to the world.
On Azure I only receive the first message that was sent directly to the listening server since Azure do support the UDP network protocol but do not support UDP broadcasting. This is the difference.
Summary
If you plan to move applications to Azure that use the UDP protocol you need to know it it is using UDP broadcasting or not, because if it does it will not work on Azure. The UDP network protocol in itself is not a show stopper.
References
udptest sample program on github
https://github.com/cljung/udptest
The sample program compiles on Windows with Visual Studio, Linux and on Mac OS.