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
|
<!-- $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">
<META NAME="Description" CONTENT="A first step towards using ACE productively">
<TITLE>ACE Tutorial 006</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 006</FONT></B></CENTER>
<CENTER><B><FONT SIZE=+2>Creating a thread-per-connection server</FONT></B></CENTER>
<P>
<HR WIDTH="100%">
<P>In <A HREF="client_acceptor.h">client_acceptor.h</A>, we've extended
our object just a bit. The primary reason is to allow us to select
the previous single-threaded implementation or our new thread-per-connection
implementation. Client_Acceptor itself doesn't use this information
but makes it available to the Client_Handler objects it creates.
If we wanted a single-strategy implementation, we would have made no changes
to the Tutorial 5 version of this file.
<P>
<HR WIDTH="100%">
<PRE>
<font color=red>// $Id$</font>
<font color=blue>#ifndef</font> <font color=purple>CLIENT_ACCEPTOR_H</font>
<font color=blue>#define</font> <font color=purple>CLIENT_ACCEPTOR_H</font>
<font color=red>/* The ACE_Acceptor<> template lives in the ace/Acceptor.h header
file. You'll find a very consistent naming convention between the
ACE objects and the headers where they can be found. In general,
the ACE object ACE_Foobar will be found in ace/Foobar.h. */</font>
<font color=blue>#include</font> "<A HREF="../../../ace/Acceptor.h">ace/Acceptor.h</A>"
<font color=blue>#if !defined</font> (<font color=purple>ACE_LACKS_PRAGMA_ONCE</font>)
<font color=blue># pragma</font> <font color=purple>once</font>
<font color=blue>#endif</font> <font color=red>/* ACE_LACKS_PRAGMA_ONCE */</font>
<font color=red>/* Since we want to work with sockets, we'll need a SOCK_Acceptor to
allow the clients to connect to us. */</font>
<font color=blue>#include</font> "<A HREF="../../../ace/SOCK_Acceptor.h">ace/SOCK_Acceptor.h</A>"
<font color=red>/* The Client_Handler object we develop will be used to handle clients
once they're connected. The ACE_Acceptor<> template's first
parameter requires such an object. In some cases, you can get by
with just a forward declaration on the class, in others you have to
have the whole thing. */</font>
<font color=blue>#include</font> "<font color=green>client_handler.h</font>"
<font color=red>/* Parameterize the ACE_Acceptor<> such that it will listen for socket
connection attempts and create Client_Handler objects when they
happen. In Tutorial 001, we wrote the basic acceptor logic on our
own before we realized that ACE_Acceptor<> was available. You'll
get spoiled using the ACE templates because they take away a lot of
the tedious details! */</font>
typedef ACE_Acceptor <Client_Handler, ACE_SOCK_ACCEPTOR> Client_Acceptor_Base;
<font color=red>/* Here, we use the parameterized ACE_Acceptor<> as a baseclass for
our customized Client_Acceptor object. I've done this so that we
can provide it with our choice of concurrency strategies when the
object is created. Each Client_Handler it creates will use this
information to determine how to act. If we were going to create a
system that was always thread-per-connection, we would not have
bothered to extend Client_Acceptor. */</font>
class Client_Acceptor : public Client_Acceptor_Base
{
public:
<font color=red>/*
This is always a good idea. If nothing else, it makes your code more
orthogonal no matter what baseclasses your objects have.
*/</font>
typedef Client_Acceptor_Base inherited;
<font color=red>/*
Construct the object with the concurrency strategy. Since this tutorial
is focused on thread-per-connection, we make that the default. We could
have chosen to omitt the default and populate it in main() instead.
*/</font>
Client_Acceptor (int thread_per_connection = 1)
: thread_per_connection_ (thread_per_connection)
{
}
<font color=red>/* Return the value of our strategy flag. This is used by the
Client_Handler to decide how to act. If 'true' then the handler
will behave in a thread-per-connection manner. */</font>
int thread_per_connection (void)
{
return this->thread_per_connection_;
}
protected:
int thread_per_connection_;
};
<font color=blue>#endif</font> <font color=red>/* CLIENT_ACCEPTOR_H */</font>
</PRE>
<HR WIDTH="100%">
<P>Ok, so far we haven't done much to change our concurrency strategy.
Let's move on to the Client_Handler and see if it has changed any.
<P>
<P><HR WIDTH="100%">
<CENTER>[<A HREF="../online-tutorials.html">Tutorial Index</A>] [<A HREF="page04.html">Continue This Tutorial</A>]</CENTER>
|
