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
|
// $Id$
This directory contains the files that implement the TAO
Naming server.
To Run:
======
% Naming_Service [-ORBnameserviceport nsport]
[-o ior_output_file]
[-p pid_file_name]
[-s context_size]
[-t time]
[-f persitence_file_name]
Optional Command-line Arguments:
===============================
nsport
Multicast port for listening for requests from
clients trying to bootstrap to a Naming Service
through the use of multicast.
output_file
The name of the file, in which to store the IOR of the
root Naming Service context.
pid_file_name
The name of the file, in which to store the process id
of the Naming Service server.
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.
time
How long (in seconds) the server should listen for
client requests before terminating.
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.
Environment Variables:
=====================
NameServicePort
Multicast port for listening for requests from
clients trying to bootstrap to a Naming Service
through the use of multicast.
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.
Implementation Policies:
=======================
- 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.
- 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.
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. 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 option -ORBnameserviceior 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 -ORBnameserviceior 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. TAO implements Interoperable Naming Service. So, most of the
initialzation options provided by INS can be used to
bootstrap to the Naming Service (see TAO's releasenotes for the
status of INS implementation).
|
