summaryrefslogtreecommitdiff
path: root/docs/tutorials/001/page02.html
blob: 24672f85cbfd98177508349a7243e4779ad02194 (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
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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
   <TITLE>ACE Tutorial 001</TITLE>
   <META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (Win95; I) [Netscape]">
   <META NAME="Author" CONTENT="James CE Johnson">
   <META NAME="Description" CONTENT="A first step towards using ACE productively">
</HEAD>
<BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff">


<CENTER><P><B><FONT SIZE=+2>ACE&nbsp;Tutorial 001<BR>
A Beginners Guide to Using the ACE&nbsp;Toolkit</FONT></B></P></CENTER>

<P>
<HR WIDTH="100%"></P>

<P>From here, I want to move on to the main program loop. In a way, we're
starting at the final product when we do this, but it is a very simple
piece of code and a good place to start.</P>

<P>The main program is really quite simple. The real work is done in the
ACE derived classes.</P>

<UL>
<PRE>1. #include &quot;acceptor.h&quot;

2. ACE_Reactor g_reactor;

3. const unsigned int PORT = 10000;

4. main()
{
        5. ACE_INET_Addr addr(PORT);

        6. Client_Acceptor * ca = new Client_Acceptor(addr);

        7. g_reactor.register_handler(ca,ACE_Event_Handler::READ_MASK);

        8. for(;;) g_reactor.handle_events();

        9. return(0);
}
</PRE>
</UL>

<P>Here's a blow-by-blow account of what's being done:</P>

<OL>
<LI>Include the header file where our client acceptor is defined.</LI>

<LI>For simplicity, we create our reactor in the global address space.
In later tutorials we will do something more clever and appropriate. However,
the purpose of this tutorial is to introduce a connection acceptance and
handling, not the full capabilities of a reactor.</LI>

<LI>A TCP/IP server can listen to only one <I>port </I>for connection requests.
Well-known services can always be found at the same address. Lesser-known
services are generally told where to listen by a configuration file or
command-line parameter. For this example, we're satisfied with simply hard-coding
a random but known value.</LI>

<LI>Define the program entry point. Obviously, we are ignoring any command
line parameters at this point. We may explore other options later.</LI>

<LI>Like the Reactor, I'm skimming over the details of the <I>ADDR</I>
object. What it provides is an abstraction for addressing services in the
network. All we need to know at this point is that we are creating an address
object which specifies the TCP/IP&nbsp;<I>port</I> on which the server
will listen for new connection requests.</LI>

<LI>Using the address object created above, we now create an acceptor object.
This is all it takes to create the TCP/IP&nbsp;server and get it ready
to listen on the specified port. As I understand it, no connections will
yet be established because the object isn't &quot;open for business&quot;
at this time. Which brings us to the next line...</LI>

<LI>where the acceptor object is registered with the reactor. Upon registration,
the reactor <I>open</I>s the object. For an acceptor, this means that client
requests for connection will now be allowed. In the registration, we also
tell the reactor that we are interested in <I>read</I> events. A read event
for an acceptor is a request for connection. When the reactor sees one
of these events, it will invoke the <I>handle_input</I> member function
of the acceptor object. The <I>handle_input</I> function will then do whatever
is necessary to deal with the new connection request. This is discussed
in detail on the next page of this tutorial.</LI>

<LI>The reactor's <I>handle_events</I> member function is responsible for
looking at all registered objects and invoking their member function when
anything of interest occurs. When an event is processed, the <I>handle_events
</I>function returns. In order to get all events, we embed this in an infinite
loop.</LI>

<LI>This is redundant since the <I>handle_events</I> infinite loop will
never exit. Some compilers will complain if it isn't there though, so in
it goes.</LI>
</OL>

<P>As I said, the main program is really quite simple:</P>

<UL>
<LI>Create an address for the <I>port</I> we want to listen to</LI>

<LI>Create an acceptor which listens on that address</LI>

<LI>Register the acceptor with a reactor to respond to the connection requests</LI>

<LI>Enter an infinite loop to let the reactor handle the events</LI>
</UL>

<P>On the next page, we will take a look at the acceptor and how it responds
to new connection requests.</P>

<P>
<HR WIDTH="100%"></P>

<CENTER><P>[<A HREF="../../Tutorial">Tutorial Index</A>] [<A HREF="page01.html">Previous
Page</A>] [<A HREF="page03.html">Continue This Tutorial</A>] </P></CENTER>

</BODY>
</HTML>