When you are writing an application that interacts with Hudson, it is often convenient to be able to auto-discover Hudson deployments on the same network. This improves the overall user experience.
There are several ways to do this — one way to do this, which is supported for the longest time, since 1.282, is via the UDP broadcast to port 33848. You send an empty UDP datagram to 255.255.255.255 port 33848, and all the Hudson instances on the same network will reply an XML fragment UDP packet to you, that looks like this:
<hudson>
<version>1.354</version><!-- version of the Hudson -->
<url>http://server/hudson/</url><!-- the top page of the Hudson -->
<slave-port>12345</slave-port><!-- TCP port number for slaves and CLIs to connect to -->
... more elements may appear here ...
</hudson>
Starting 1.335, Hudson started using IP multicast socket to listen to this broadcast, so you can discover them by sending a broadcast packet to 239.77.124.213 instead of 255.255.255.255 — depending on how the network is configured, this can also reach beyond the same subnet.
Starting the upcoming 1.359, you can also discover Hudson via DNS multi-cast at “_hudson._tcp.local”. This also defines a convention that enables wide-area discovery of Hudson — such as “_hudson._tcp.infradna.com” for the Hudson deployed for infradna.com. The same version, url, and slave-port parameters are available as the key/value pairs associated with this DNS record, so you can find the actual URL of Hudson instances that way.
As we the engineers use more and more server applications for software development, more seamless integrations between them get more important, and I think the auto-discovery is a very important part of this.