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
|
// $Id$
This is the cubit example that uses the TAO IDL compiler to generate
the stubs and skeletons. Additional features include presence of a
factory to create Cubit objects and testing the _bind call to get the
factory object reference.
You can either run the server in the background in the same window as
the client or open a separate window for the client and server.
The client and server by default make use of the Naming Service.
The cubit server now has its own NamingServer implementation and hence
you don't have to start the NamingService before starting the client
and server.
You just have to use the -s flags on both the server and
client if you don't want to use the naming service.
server:
-------
% server [-d] [-s] [-ORBhost <serverhost>] [-ORBport <portnum>]
[-n <number-of-cubit-objects>] [-o <ior_output_file>]
Options:
-------
-s Tells the server not to register the cubit-factory object
with the Naming Service.
-d Debug flag (It is additive more -d flags will give debugging).
-o Outputs the cubit_factory ior file to the file
-n Number of cubit objects exported by the server
The server cubit factory maintains num_of_cubit objects (default =
1). They are assigned keys that look like "key0", "key1", ...
When the server is started and you have used the -d flag, you should
see as the first line of output something that looks like
iiop:1.0//swarm:10015/Persistent/886013035/850128/RootPOA/RootPOA_is_BAD/factory
(-ORBobjrefstyle url)
or
IOR:000000000000001649444c3a43756269745...
(-ORBobjrefstyle ior)
Using -d turns on debugging messages. It is additive, i.e., the more
-d options provided, the more debugging you can get. At the moment,
only 2 levels of debugging are implemented, and more than 2 -d options
are ignored.
client:
-------
% client [-d] [-s] [-x] <-f cubit_factory_ior_file> <-k cubit_factory_ior> -n <iterations>
Options:
-------
d Debug flag
s Don't Use the Naming Service
x Tells the server to shutdown.
f Reads the cubit factory ior from the file
k Reads the cubit factory ior from commandline
n no. of iterations
There are 3 ways of giving the CubitFactory IOR to the client:
1. From a file using the -f option. (This file can be produced using
the -o option of the server.)
2. Directly on the commandline using the -k option.
3. Get it from the Naming Service (which is the default client
behavior).
IDL_Cubit_Test:
--------------
This is a simple test program which tests the server and
client using the default options of the server and client. To test
using this just run
%IDL_Cubit_Test
Sample Run- Using files to communicate IOR:
------------------------------------------
1. Start the server.
% server -s -ORBport 20000 -ORBobjrefstyle url -o theior
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
The IOR is: <iiop:1.0//tango:20000/Persistent/887665222/647179/RootPOA/RootPOA_is_BAD/factory\00\00>
2.Start the client.
%client -s -ORBport 19998 -f theior
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
Factory received OK
.
.
.
Sample Run-Using Naming Service:
--------------------------------
1. Start the server
%server -ORBport 19999
2. Start the client
%client -ORBport 19998
if you don't want the server to shutdown.
%client -ORBport 19998 -x
if you want to shutdown the server after this request.
3. If Multicast is not supported the naming service can be reached by
the following 2 methods.
a) use the -ORBnameserviceior flag to the client to give the
naming service ior outputted by the server.
b)set the ENVIRONMENT variable "NameService"
This might be helpful if more than one person is running the
Naming service in which case Multicast might cause confusion with some
other Naming Service trying to answer your call.
|
