1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
<!-- $Id$ -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; Linux 2.0.32 i486) [Netscape]">
<META NAME="Author" CONTENT="James CE Johnson">
<TITLE>ACE Tutorial 008</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 008</FONT></B></CENTER>
<CENTER><B><FONT SIZE=+2>Sending and receiving datagrams</FONT></B></CENTER>
<P>
<HR WIDTH="100%">
<P>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.
<P>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.
<P>So... how do the clients know where the servers are?
<P>Let 'em ask!
<P>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.
<P>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.
<P>
Kirthika's abstract:
<UL>
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.
<P>
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.
<P>
Thus, we get a fair glimpse of using another means of communication via
datagrams.
</UL>
<P><FONT SIZE=-1>* Actually, the servers <I>might</I> 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.</FONT>
<P><HR WIDTH="100%">
<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page02.html">Continue This Tutorial</A>]</CENTER>
|
