Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 16 in printed book and digital formats -- plus a one-year subscription (beginning with 17.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Recent issues

Article Preview

Buy Now

Issue 2.2


Auto-Discovery Via UDP

How to automatically find other instances of your applications across a local network.

Issue: 2.2 (October/November 2003)
Author: Aaron Ballman
Author Bio: Aaron Ballman is the official networking guru of REAL Software. All your base are belong to him.
Article Description: No description available.
Article Length (in bytes): 13,023
Starting Page Number: 27
Article Number: 2212
Resource File(s):

Download Icon 2212.zip Updated: 2013-03-11 19:07:57

Related Link(s): None

Excerpt of article text...

There are many situations where it would be useful to find out who else on your internal network is running a copy of your application. This is useful for things like doing network checks, or maybe you would like to add a chat feature to your application. There are any number of reasons you might like to have this sort of functionality. With the UDPSocket, this is a fairly easy thing to do.

When you want to discover what other applications are on the network, you need to send out a simple query over the network that any interested applications can hear. To do this, we need to come up with a protocol for your application to implement to do these queries and their appropriate responses. Let's start by trying to understand the process of what goes on when you need to automatically discover an application.

Auto-discovery, by its nature, is an asynchronous process. You have to start the ball rolling and see what occurs some time later. There are a few initialization and finalization issues you need to contend with, but those are fairly trivial. The first thing your application needs to do is, in its Open event, register itself to a multicast group and send out a message saying "I am here! Who else is here?" That is all the initialization you need to do. This lets other copies of your application know that something interesting has happened (you signed on), and allows them to respond (by telling you who they are). You will also need, in your Close event, a message that says "I'm leaving!" and remove yourself from the multicast group. This allows the other applications to take note of the interesting event. If one of the applications on the network crashes, it isn't a problem. We solve this possible problem with intermittent queries to see what applications are still responding. These queries can either happen at specific intervals (like every five minutes), or they can happen just before you need to do something interesting. For instance, you can query the network before saving a file to see if any other applications appeared, so you can see if this copy is perhaps pirated. Don't worry about the details yet; just be aware that we will have all situations covered.

The second part of what your application needs to do is be able to handle certain messages that it may receive from other applications on the network. Just like when we sent out an "I am here!" message, we may be on the receiving side at some point. The best thing to do when we get a message letting us know that someone has joined or left the group is to update some internal representation of who the current group members are, and respond to the message if it is appropriate. We do this by keeping a list of currently known members. When we get a message letting us know that someone new is here, we will add the proper information to our list. If the message is requesting us to answer back with who we are, we will then respond directly to the querier. When we get a message letting us know that someone has left, we will remove the appropriate information from our list. The information in this case is the IP addresses of people in the group so we can query them directly if needed. This will save us the trouble of always talking to the entire group, and we can instead focus on just a single member.

The last part of what our application needs is a generic querying mechanism. We need a way to be able to either blast a message to the group (as well as a way to handle receiving that message from the group) and a way to send (and receive) a message to a single entity in the group. This lets us do things like send a message saying "who all is here?" so we can keep our group list up-to-date, or a "quit NOW pirate!" message to a single member that is running an unlicensed copy of our application.

...End of Excerpt. Please purchase the magazine to read the full article.