[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