[omniORB] transports
Renzo Tomaselli
renzo.tomaselli@tecnotp.it
Wed Jan 22 14:26:01 2003
Hi,
I'm planning to add my own transport to handle security issues, thus a
few questions arise (ssl looks good to borrow ideas from).
- I noticed that the transport rule actions are listed in the user manual as
a static list, while transports are dynamic entities we can add at runtime
without affecting an already build OmniORB library suite.
How can we prioritize the action list toward a new transport ? Say I want
transport "foo" to be more relevant than "tcp".
- I need to have a server process which publishes IORs containing either one
of two possible transports - e.g. either "tcp" or "foo" - according to
security runtime criteria. This seems to fight against the process-wide
nature of the ORBendPoint way of specifying transports. I cannot specify
both, since some objects have only "foo", others only "tcp". Now, since long
time I use a genior-style way to syntethize special IORs, beside the
standard _this() way. Would be this a way to overcome this limit, after
specifying "giop:tcp:host:port" for the default tcp transport?
- just to avoid reinventing the "socket wheel": would it be a reasonable
strategy to pipeline transport "foo" to/from transport "tcp" - e.g. to
delegate low level communications ?
Thanks,
Renzo Tomaselli