In a lot of IPC programming, the clients know where the servers are.  A mail client, for instance, has a configuration file that says where the mail host is.  Your web browser has a "location" field that you type into to give it a destination.

What if you have written a server application and then you execute it on several systems in your network?  All of the instances are probably more or less equal to the client's point of view, so you don't want to "configure" the clients to a single server each.  Likewise, you want the ability to add and remove servers at any time so you can't just give the clients a list to choose from.

So... how do the clients know where the servers are?

Let 'em ask!

Datagrams are great for this.  You can toss a datagram out onto the network and any servers listening at the correct port will* hear it.  Like ACE_SOCK_Stream that we've seen before, you can get the peer address from a datagram.  With that, the server can  send a response back to the client.  The client, in turn, can pull the peer address out and know exactly where the server lives.

In this tutorial we'll develop three applications:  a server listening for datagrams, a client that can send to a known host and a client that can send to the entire (sub)network.  In the next tutorial, we'll expand on this to make the server a bit more prudish.

Kirthika's abstract:

Here, we play with datagram sockets and use it for server discovery by the client. Datagrams are used by UDP, which is an unreliable and connectionless protocol. Datagrams packets are generally very small in size and aren't designed to be used to handle serious communication between the server and the client.

The server waits for datagrams to arrive at a fixed port. The client either sends to a datagram to the server at a known host, which is not really the case generally, as the client needs to discover the server and so it needs to broadcast its datagram request in its subnet. Then, all servers listening at that interface receive it. The appropriate server will then handle the request. Remember that no solid connection is made. On the recv() itself the server obtains the address of the remote client and then communicates with it.

Thus, we get a fair glimpse of using another means of communication via datagrams.

* Actually, the servers might hear the datagram.  Datagrams are rather unreliable.  (Sort of like some operating systems I know.)  Still, if the network traffic isn't too bad, they generally get through.  Your clients can always send out more queries if there aren't any responses in a timely fashion.