blob: 771e113e9618aa730f26401d504b7b5093e060df (
plain)
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
|
<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 009</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 009</FONT></B></CENTER>
<CENTER><B><FONT SIZE=+2>Sending and receiving datagrams again</FONT></B></CENTER>
<P>
<HR WIDTH="100%">
<P>In this tutorial we've expanded on Tutorial 8 to provide a more discriminating
server application. The changes to the clients were trivial, amounting
to not much more than the addition of a timeout when reading a server's
potential response. The server change was a bit more since it had
to compare the clients' query with it's own signature.
<P>In a "real" system, the signatures you swap would probably include version
information. You could even use a major/minor scheme where an exact
match isn't necessary. Another upgrade might be to have a set of
signatures at one or both ends of the conversation. The level of
service provided by the server would be determined by the signature pair
match.
<P>Here's the final file list:
<UL>
<LI>
<A HREF="Makefile">Makefile</A></LI>
<LI>
<A HREF="server.cpp">server.cpp</A></LI>
<LI>
<A HREF="directed_client.cpp">directed_client.cpp</A></LI>
<LI>
<A HREF="broadcast_client.cpp">broadcast_client.cpp</A></LI>
</UL>
<HR WIDTH="100%">
<CENTER>[<A HREF="..">Tutorial Index</A>]</CENTER>
</BODY>
</HTML>
|
