[omniORB] transports

[Duncan Grisby]

On Wednesday 22 January, "Renzo Tomaselli" wrote:

> - 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".

That is determined by the client and server side transport rules. You
can make the rules anything you like in the configuration file. You
would just set something like clientTransportRule="* foo,unix,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?

In theory, you ought to be able to do that with the encodeIOR
interceptor, but at the moment you can't prevent IOR encoding from
putting the globally registered endpoint information in there.

> - 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 ?

Yes, although you may find that the tcp transport can't quite be used
that way, since it isn't what it was designed for.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --