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
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<!-- $Id$ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Venkita Subramonian">
<meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]">
<title>Fault Tolerant Real-Time Event Service</title>
</head>
<body>
<center>
<h2>
Fault Tolerant Real-time Event Service</h2></center>
<h3>
Introduction</h3>
The Fault Tolerant Real-time Event Service provides the fault tolerant
capability to the TAO Real-time Event Service. Essentially, it allows you
to start several event services in different machines. These event services
form an object group which can be treated as a logical event service by
clients. The clients only communicate with the primary (leader) of the
object group. The rest event channels in the object group are called backups.
Once the primary dies, one of the backups will assume the reponsibility
of primary and this process is transparent to the clients.
<p>The key to provide fault tolerance to event channels is to replicate
the states of primary to its backups. There are two kinds of states in
the event channels, transient and persistent. A transient state in the
event channels is the events which are yet to be delivered to the consumers.
Those events are hard to replicate because the time scale is too small.
They might be delivered late or out of scope if we tried to replicate the
events. However, the subscription information occurs at a suitable
<br>time scale for replication, and is in fact more essential for the delivery
of events since it establishes a kind of connectivity from suppliers to
consumers. Therefore, we only replicate the subscriptions
<p>Once the primary receives the subscription requests from the clients,
it will replicate the requests to the backup event channels.In order to
provide time bounds on replication, we introduce the concept of transaction
depth. If we say the transaction depth is n, that means a subscription
method invocation has to be blocked until the first n replicas complete
the subscription operation, illustrated by the assured-replicate arc in
the figure. Other replicas can get the state change via a so called soft-replicate
which conceptually means the replication is not assured to complete before
the subscription operation returns. So, if the soft-replicate fails
due to loss of the primary, we will have only the assured depth of replication.
The clients are allowed to configure the transaction depth to tradeoff
reliability and responsiveness. Furthermore, it is necessary to roll back
an operation in some replicas if the transaction depth can not be met.
In addition, we can use either two-way or AMI calls for assured-replication
and one-way operations for soft-replication.
<p><b><font color="#FF6666">Important Note</font> :</b> In current stage,
the Fault Tolerant Event Service can only be made under MPC build. The
conventional makefiles are yet to be supported.
<br>
<h3>
Programs</h3>
This directory contains the following programs:
<p>ftrt_eventservice : Implements the functionality of fault tolerant event
channel. It can be started directly or be started by the ft_factory.
<p>ftrtec_factory_service : A program used to spawn the ftrt_eventservice
process. The process it create can be controled through "test.cfg" whose
contents should begin with the repository id of EventChannel followed by
the executable path of ftrt_eventservice.
<p>ftrtec_gateway_service : An intermediator program between the ftrt_eventservice
and the clients which do not support FT CORBA.
<p>consumer : A shell script to start the consumer test program. The actual
consumer pragram is in orbsvcs/tests/FtRtEvent.
<p>supplier : A shell script to start the supplier test program. The actual
supplier pragram is in orbsvcs/tests/FtRtEvent.
<p>ftec : a shell script to start ftrt_eventservice.
<br>
<h3>
Quick start:</h3>
Run the applications as follows:
<br>
<p> 1. Start Naming_Service
<br> $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1
<br> or you can use the shell script NameService
in this directory to start it.
<p> 2. Start the ftrt_eventservice. Use the "-p" option to start
it as a primary and
<br> use the "-j" option to start it as a backup.
<p> $ ./ftec -p
<br> $ ./ftec -j
<br> $ ./ftec -j
<br>
<p> 3. Start the consumer and supplier.
<br> $ ./consumer
<br> $ ./supplier
<br>
<h3>
How do we add a new FTRTEC to the system?</h3>
Just use
<p> ./ftec -j
<p> The newly created process will contact to the naming service
and then join to
<br> the existing object group.
<br>
<h3>
Is there any adjustable options for FTRTEC?</h3>
Here is the list of options for the ftec script
<p> -sciop
Use SCIOP for CORBA communication
<br> -sctp
Use SCTP for fault detection
<br> -hb n
Specify the heart beat interval in sec
<br>
for SCTP connection, this option also activate sctp option.
<br> -ami
Use AMI call for replication messages (The default is
<br>
two-way CORBA call for replication)
<br> -p
activate as a primary replica.
<br> -j
activate as a backup replica.
<br>
<p> Below are some options that are used for the consumer and supplier
<br> test scripts.
<p> -sciop
Use SCIOP for CORBA communication. This requires that the Naming
<br>
Service and ftec are also started using SCIOP transport protocol.
<p> -d n
Specify the transaction depth. The transaction depth indicates the
<br>
number of replicas that must complete the subscription request before
<br>
the request can return.
<p> -t f.f
For supplier only. Specify the time interval between event sending
<br>
in seconds, this value should be a float point.
<p> If you the naming service are not running at the same machine
with above programs, you can always set the environmental variables NameServiceIOR
before starting the ftec, consumer or supplier.
<br>
<h3>
How do I start the FTRTEC using ftrtec_factory_service?</h3>
The ftrtec_factory_service is a small program that can instaniate a ftrt_eventservice
on demand. It exports the FT::GenericFactory interface to its client. There
are two ways that you can get the IOR for the factory object. 1)
specify the name you want the factory register to the naming service
and then get the IOR from the naming service by the name. 2) output the
IOR to a file when the factory starts. Here are the options
<p> ftrtec_factory_service :
<p> -i id_string
The id field of the name that is used to register to the naming service
<br> -k kind_string
The kind field of the name that is used to register to the naming service
<br> -o output_filename
The output file name for the factory IOR.
<p>Once you get the IOR for the factory, you can use create_object to intantiate
the ftrt_eventservice.
<br>Here are the parameters in create_object() to control how ftrt_eventservice
is created.
<p> type_id : this value should be "IDL:FtRtecEventChannelAdmin/EventChannel:1.0"
<br> the_criteria : the_criteria is a sequence of Property
which in term consists of "nam" and "value". Below a a list of possible
nam and values.
<br>
<br>
<table BORDER COLS=2 WIDTH="100%" >
<tr>
<td>nam</td>
<td>value</td>
</tr>
<tr>
<td>FTEC_MEMBERSHIP</td>
<td>PRIMARY
<br>BACKUP
<br>NONE</td>
</tr>
<tr>
<td>FTEC_DETECTOR_TRANSPORT_PROTOCL</td>
<td>TCP
<br>SCTP</td>
</tr>
<tr>
<td>FTEC_HEART_BEAT</td>
<td>the heart beat value in sec. (Note, you have to specify it using string,
i.e. the_criteria[0].value <<= "5");</td>
</tr>
<tr>
<td>FTEC_REPLICATION_STRATEGY</td>
<td>AMI
<br>(If not specified, the ftrt_eventservice use default two-way call for
replication)
<br> </td>
</tr>
<tr>
<td>NameServieIOR</td>
<td>the corbaloc representation for the naming service
<br> </td>
</tr>
</table>
<p> Any nam string started with "-" will be used as a command line
option to start ftrt_eventservice. For example, if you specfiy the name
as "-ORBEndpoint" and value as "sciop://" then the ftrt_eventservice can
be started using sciop.
<br>
<h3>
How do I use the ftrtec_gateway_service program ?</h3>
The FTRTEC uses some features in FT CORBA that requires every client to
use FT ORB to work. If your client is written based other ORBs other
than TAO. You cannot get the desired fault tolerance feature. In this case
you can have the ftec_gateway as an intermediator between the FTRTEC and
you client program.
<br>For example, if you have an existing client called my_supplier.
<p> # setting up the event channel group as previously
stated.
<p> $ftrtec_gateway_service -o gateway.ior
## start the gateway and output the IOR of the gateway to a file
<br> $my_supplier -i file://gateway.ior ## start
the supplier using the gateway
<br>
</body>
</html>
|
