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
|
// $Id$
This directory contains the files that implement the TAO
Naming server. The TAO Naming Service uses IP Multicast to process
client "resolve_initial_references()" requests.
To Run:
======
% Naming_Service [-ORBobjrefstyle url]
[-ORBnameserviceport nsport]
[-o ior_output_file]
[-p pid_file_name]
[-s context_size]
[-t time]
[-f persitence_file_name]
Arguments:
==========
port
The ORB port.
nsport
Multicast port.
output_file
The name of the file, in which to store IOR of the
root Naming Service context. (This file can then be
used by clients instead of multicast, to obtain the
Naming Service IOR).
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 upon the creation of
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 the server should listen for requests before
exiting.
persistence_file_name
The name of the file to use to store/read from the
persistent state of the Naming Service.
Environment Variables:
=====================
NameServicePort - Multicast port to listen on for
"resolve_initial_references" requests.
Persistence:
===========
TAO Naming Service has an optional persistence capability. By
default, a non-persistent version of the Naming Service is used.
Supplying "-f" command-line option to the server causes a persistent
version of the Naming Service to run.
The file, which name is supplied along with the "-f" option, is used to store the
persistent state of the Naming Service, i.e., all Naming Contexts and
all their bindings. When "-f" option is specified:
1. If the specified file does not exist, the file 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. A
noncorrupted version of the file must be used.
b) If no Naming Contexts exist, an initial
(root) Naming Context is created.
c) If one or more Naming Contexts exist, the
state stored in the file becomes the state of
the Naming Service.
Sample Run:
==========
% Naming_Service -ORBobjrefstyle url -ORBnameserviceport 19999
starting up daemon <unknown>
opening dynamic service Resource_Factory
did dynamic on Resource_Factory, error = 0
opening dynamic service Client_Strategy_Factory
did dynamic on Client_Strategy_Factory, error = 0
opening dynamic service Server_Strategy_Factory
did dynamic on Server_Strategy_Factory, error = 0
listening as object <iiop:1.0//tango:20000/P35194c690003809cRootPOA/child_poa/NameService>
The multicast server setup is done.
NameService Client:
==================
A client of the TAO Naming Service will use the ORB
resolve_initial_references() method to resolve the "NamingService"
object service. By default, this resolution is performed using
Multicast. This behavior can be overridden in the following ways:
1. Pass the argument -ORBnameserviceior ior.
This ior is got from the output of the Naming_Service from
line 'listening as object <iiop:..>'.
For example, If a client wants to use the Naming_Service
from the sample run it could use:
% client -ORBnameserviceior <iiop:1.0//tango:20000/P35194c690003809cRootPOA/child_poa/NameService>
2. Set the environment variable `NameServiceIOR' (minus the
quotes), as follows in csh or tcsh:
% setenv NameServiceIOR <iiop:1.0//tango:20000/P35194c690003809cRootPOA/child_poa/NameService>
and then run the client,
% client <.. client's arguments>
These two techniques may be needed in an environment where
1. There is more than one NamingService, to avoid the
confusion of a server registering its object with one
NamingService and the client getting the reply from some
other NamingService.
2. The OS platform doesn't support multicast.
3. The client or server isn't written using TAO, and therefore
doesn't use TAO's multicast NameService resolution protocol.
|
