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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
|
// $Id$
This directory contains files that implement a server for the TAO
Naming Service. In addition, it contains files that run the TAO
Naming Service as a Windows NT Service. Both of these services are
described below.
How to Run the TAO Naming Service
=================================
1. Syntax
% Naming_Server [-ORBNameServicePort nsport]
[-o ior_output_file]
[-p pid_file_name]
[-s context_size]
[-t time]
[-f persitence_file_name]
2. Optional Command-line Arguments
-ORBNameServicePort nsport
Multicast port for listening for requests from clients
trying to bootstrap to a Naming Service through the
use of multicast.
-o ior_output_file
The name of the file, in which to store the IOR of the
root Naming Service context.
-p pid_file_name
The name of the file, in which to store the process id
of the Naming Service server.
-s context_size
Size of the hash table allocated for the root Naming
Context (if one is created). All contexts created
under the root will use the same size for their hash
tables. The default is 1024.
-t time
How long (in seconds) the server should listen for
client requests before terminating.
-f persistence_file_name
The name of the file to use to store/retrieve
persistent state of the Naming Service. Without this
option, Naming Service is started in non-persistent
mode.
3. Environment Variables
NameServicePort
Multicast port for listening for requests from clients
trying to bootstrap to a Naming Service through the
use of multicast.
4. Persistence
TAO Naming Service has an optional persistence capability. By
default, the Naming Service is started in a non-persistent
mode. Supplying "-f" command-line option to the server causes
a persistent version of the Naming Service to run.
The file specified with the "-f" option is used to store the
persistent state of the Naming Service, i.e., all Naming
Contexts and their bindings. When "-f" option is specified:
1. If the specified file does not exist, it is created and
used to store the state of the Naming Service. An initial
(root) Naming Context is also created.
2. If the specified file exists, it is scanned and:
a) If any inconsistency is detected in the stored
state, or the file is not recognized by the Naming
Service, the server exits. (This may happen, for
example, if a server or host crashed in the middle of
writing a record to this file on a previous run). A
noncorrupted version of the file must be used instead.
b) If the file is recognized and is ok, the state
stored in the file becomes the current state of the
Naming Service.
5. Implementation Policies
a. Destroying Binding Iterators
A binding iterator is destroyed when client invokes
<destroy> operation either on the iterator itself or
on the naming context it is iterating over. In both
cases, subsequent calls on the binding iterator object
will cause OBJECT_NOT_EXIST exception.
b. Dealing with orphaned contexts
This implementation of the Naming Service does not
include any form of 'garbage collection' for orphaned
naming contexts. It is solely the responsibility of
clients to clean up after themselves and not leak
server resources. All the resources, including
orphaned contexts, are released during the Naming
Server shutdown.
6. Clients: ways to bootstrap to the Naming Service:
There are several methods for a client to bootstrap to a
Naming Service, i.e., there are several mechanisms
<resolve_initial_references> can use when asked for
"NameService".
1. Multicast
By default (unless other options are specified - see
items 2 and 3 below), ip multicast is used to locate a
Naming Service. TAO Naming Server is listening for
client multicast requests on a specified port. On the
client side, <resolve_initial_references> sends out a
multicast request on the network, trying to locate a
Naming Service. When a Naming Server receives a
multicast request from a client, it replies to the
sender with the ior of its root Naming Context. Note,
the port used for this bootstrapping process, i.e.,
'multicast port', has nothing to do with the ORB port
used for CORBA communication. Other points worth
mentioning:
- A client and a server will only click through this
multicast protocol if they are using the same
multicast port. For both client and server
-ORBnameserviceport command-line option and
NameServicePort environment variable can be used to
specify the multicast port to use. If none is
specified, the default port is used. (The ability
to specify multicast ports can be used to match
certain clients with certain Naming Servers, when
there are more than one Naming Server running on the
network).
- If there are several Naming Servers running on the
network, each listening on the same port for
multicast requests, each will send a reply to a
client's request. The client's orb will use the
first response it receives, so the Naming Service
will, in fact, be selected at random.
Since this mechanism is proprietary to TAO (i.e.,
non-standard), it only works when both client and
server are written using TAO. There is no way to turn
multicasting off, but it is used only as a last
resort, i.e., any of the options below will override
it.
When OS platform doesn't support multicast, or client
or server isn't written using TAO, or a more reliable
location method is desired, etc., one of the options
below can be used to bootstrap to the Naming Service.
2. Command-line options
The "-ORBInitRef NameService=IOR:..." or environment
variable NameServiceIOR can be used on the client side
to specify the object that the call to
<resolve_initial_references> should return to the
client. (On the server side, -o option can be used to
get the ior).
Example (Unix, same host):
% TAO_ROOT/orbsvcs/Naming_Service -o ior_file
% my_client -ORBInitRef NameService=file://ior_file
On the first line, we start the Naming
Service, and output its ior to <ior_file>. On
the second line, we start some client, and
specify the ior <resolve_initial_references>
should return for the Naming Service in a file
format.
3. Interoperable Naming Service.
TAO implements the standard CORBA Interoperable Naming
Service (ING). Therefore, most initialization options
provided by INS can be used to bootstrap to the Naming
Service (see TAO's releasenotes for the status of INS
implementation).
How to use the NT_Naming_Service
================================
1. Syntax
% NT_Naming_Server [-i value]
[-r]
[-s]
[-k]
[-t n]
[-d]
2. Optional Command-line Arguments
-i value
Install this program as an NT service, with specified startup
-r
Remove this program from the Service Manager
-s
Start the service
-k
Kill the service
-t value
Set startup for an existing service
-d
Debug; run as a regular application
3. Usage
To see different stages of an NT service application, you have
to run the program several times, with different options.
Please note: run with only one option at a time.
a. First, you must initialize the service in the NT SCM
database. Run NT_Naming_Service with -in, where n is one of
the following startup options:
// Start Type (from WinNT.h)
//
#define SERVICE_SYSTEM_START 0x00000001
#define SERVICE_AUTO_START 0x00000002
#define SERVICE_DEMAND_START 0x00000003
#define SERVICE_DISABLED 0x00000004
If only -i is specified, SERVICE_AUTO_START is default option.
b. Now you are ready to run the actual service. Run
NT_Naming_Service again, this time with -s option. If the
service starts successfully, it will ring the system
bell every second or so until the service is stopped.
c. To stop service execution, run NT_Naming_Service with the
-k option.
d. To remove the service from the Service Control Manager
database, run NT_Naming_Service with -r.
In addition, once you have initialized this service (by using
the -i option) you can change its startup type to one of the
other values above. To do this, run NT_Naming_Service with
-tn option. n is as explained above for -i.
In order to debug the service's execution itself, use the -d
option.
|
