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
|
DIOP - UDP Based Pluggable Protocol
===================================
NOTE: The file that were in this directory have been moved to
$TAO_ROOT/tao/Strategies/.
This directory contains all of the code needed to use the UDP
Pluggable Protocol (DIOP). It is work-in-progress that when complete
will be integrated with the other standard pluggable protocols in
$TAO_ROOT/tao/Strategies/.
Notes on the DIOP implementation:
- The DIOP implemenation uses connectionless UDP sockets.
- The server DIOP implementation bypasses the actual TAO Acceptor
and opens always a UDP socket on start-up.
- The address of that UDP socket can be configured via -ORBEndpoint,
e.g., -ORBEndpoint diop://:1303
If nothing is specified, the implementation will select a port and
open a socket on all network interfaces. This is the default ORB
behavior and can be overwritten using the -ORBEndpoint switch.
- Because no connections - no state - exist, all client requests
from different clients arrive at the same socket!
- The client DIOP implementation bypasses the actual
TAO Connector. It installs a connection handler on the first
invocation on a remote CORBA object.
DIOP Installation (this will be simplified when DIOP is integrated in the
$TAO_ROOT/tao/Strategies/ directory):
- Compile TAO/examples/PluggableUDP/DIOP to create the DIOP library.
- Uncomment the following line in TAO/tao/corbafwd.h:
#define TAO_TAG_DIOP_PROFILE 0x54414f04U /* UDP */
- The application using DIOP should have a svc.conf file with the
following entry:
dynamic DIOP_Factory Service_Object * TAO_DIOP:_make_TAO_DIOP_Protocol_Factory() ""
static Resource_Factory "-ORBProtocolFactory DIOP_Factory"
Limitations:
- No preconnections are supported.
- No thread-per-connection is supported.
- Requests from multiple clients are received on the same socket.
- Only oneway invocations operations are supported.
Using exclusive connections (see ORB configuration) twoways might
work, but are not supported yet. Please note that you need to use
timeouts in combination with twoways in order to avoid deadlocking
your application.
Open Issues:
- Default port is the same on client and server, therefore
the client ports need to be explicitly set by -ORBEndpoint option.
Maybe there is a way to find free ports?
- GIOP invocations containing more than ACE_MAX_DGRAM_SIZE bytes of header
and invocation data will not be sent to the remote side, they will
be dropped without error notification. The reason for this is that
we want to ensure all invocation information is received at once by
the server. Supporting multiple UDP packets would require keeping
state in the server and is therefore avoided.
A hook might be provided in the future in order to notify
applications about dropped invocations.
Disclaimer:
This UDP Pluggable Protocol has been developed for a particular
set of assumptions:
- Almost 100% reliable UDP communication, e.g., IP over ATM.
Even if it would be less reliable you can manage it by using
one-way request operations and one-way response operations in
combination with application level timeouts.
- TCP is inappropriate due to its sluggish on sudden disconnections,
e.g., it must be possible to "plug & play" CPU cards without
impacting any ORB communicating to a CPU. This is the main reason
why we do not keep any state in the client of the Pluggable Protocol.
- Every GIOP message (and therefore every IDL signature) message is
<= 4kB, i.e., ACE_MAX_DGRAM_SIZE. Support for fragmentation, as
GIOP 1.2 supports it might help, this is a future option.
Thus, no data sent via DIOP can be larger than ACE_MAX_DGRAM_SIZE.
|
