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
|
$Id$
This is a simple CORBA example that makes a grid of user defined size.
The grid can be imagined as a matrix with cells that can hold values.
This example creates a simple grid server with user defined sizes. If
the user does not define the size a default grid is created. The user
can give a value to be held in the grid.
run_test.pl : This is a perl script to run the server and client as :
------------
server -o ior_file
client -f ior_file
This perl script runs the server and client and shuts down the server
when it is done.
Passing the Server IOR to Clients:
---------------------------------
To keep this example simple, the server advertises its IOR in the
following manner - The server program writes its server object's IOR
to a ior_file. Later on, the client reads this IOR from the specified
ior_file and uses the <string_to_object> method to obtain a reference
to the server object.
For this mechanism to work, the file must be readable and writable. If
it doesn't exist, a new file is created by the server. Moreover, the
file path must be accessible to both the client and server.
If the client and server are on different machine, then there must be
a shared directory accessible by both. On UNIX system's this is
typically done via the NFS mount command. On Windows, the 'explorer'
application provides an option to share drives.
In general if no such file sharing option is available, then using the
the Naming Service mechanism is the only alternative, as described by
the -n option below.
server:
-------
server [-d] [-o <ior_output_file>] [-n]
Options:
-------
-d Debug flag (It is additive more -d flags will give debugging).
-o Outputs the ior to the file
The ior is the reference using which the client can interact with
the target server object.
-n Use the naming service
When the server is started, you should see as the first line of output
something that looks like
iiop:1.0//danzon.cs.wustl.edu:10015/P35ad159600081a38/child_poa/server
(-ORBobjrefstyle url)
or
IOR:000000000000001649444c3a43756269745...
(-ORBobjrefstyle ior)
Using -d turns on debugging messages. This option 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] [-x] [-f <Server_ior_file>] [-n iterations] [-k ior] [-n] [-p]
[-q] [-w] [-h] [-v]
Options:
-------
-d Debug flag
-x Tells the server to shutdown at the end of the test.
-f Reads the server ior from the file
-n no. of iterations
-k IOR or The IOR can also be given in the format like file://[file.ior]
with the full path
-n Use the naming service
-p A horizontal position of the grid where the value [v] is stored
-q A vertical position of the grid where the value [v] is stored
-w Width of the grid
-h Height of the grid
-v Value that needs to be stored in the grid.
The last four options ie. p,q,w,h,v have default values. So, if the client
is invoked without these options then default values of one or all are
taken.
You can either cut and paste the IOR from the server to the client
(with the -k option), have the client read the IOR from a file using
the -f option (this file is produced using the -o option of the
server), or use the naming service (with the -s option).
|
