blob: 29153b044e800bf94e29aa38f76a25215c719b25 (
plain)
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
|
-*- indented-text -*-
$Id$
BACKGROUND
==========
This example tests the scenario of nested upcalls. For example, a
particular process may need to act in both the role of client and
server. This interaction is common in situations where the process
makes a twoway invocation on a remote servant, passing a local object
reference 'o' to that servant. In the process of servicing that
invocation, the servant makes a twoway invocation on 'o'.
In this example, we draw upon an interaction of this sort which should
be familiar to anyone who's used ACE: the process of registering a
handler with a Reactor. The EventHandler is the local object
reference, and the Reactor the remote servant. NOTE: This example in
no way should be construed as testimony that remote Reactors make
sense or are in any way useful. It is merely a motivating example!
EXECUTION
=========
server
------
$ server [orb options] [-d]
where
-d turns on debugging messages
client
------
$ client [orb options] [-d] [-f ior_file] [-k ior_string]
where
-d turns on debugging messages
-f specifies the name of a file in which the IOR
for the Reactor can be found
-k specifies a string which is the IOR of the Reactor
NOTES
-----
If running both on the same machine, it will be necessary to specify a
different port for each the client and the server using -ORBport on
the command line. This is because there is also a servant within the
confines of the client executable.
|
