Post by Rob RatcliffIt's not deprecated, just not portable. The two options invoke the same code, its just that TAO had -ORBEndpoint before the spec
defined -ORBListenEndpoints. I don't think there is any need to strip out the old option.
The TAO Developer's Guide mentioned that it was deprecated and to start using -ORBListenEndpoints instead even though they take the
same list of arguments. (Looks like the spec just
Right. Portable options are favored over TAO-specific ones. But really
this is a side topic.
Post by Rob RatcliffRegarding your problem at hand, TAO does not have a way to bind a client side address to a port, which is what it sounds like you
want to do. Generally, client-side port binding is considered a bad thing to do, particularly if the server side is also binding to
specific ports. However, there is nothing technically preventing it, so if you would like to fund some research one of the
commercial support providers to research it, perhaps a solution could be found.
I asked one of the guys working on TAO and he mentioned that the -ORBListenEndpoints constrains the ORB to use the given port range
even for callback objects. Graham, have you tried just specifying the port range on the client side ORB? Phil are you sure that this
option doesn't constrain the port range of the callback object?
The only endpoint constraint that can be configured is that of
server-side binding. By default, TAO will let the system select an
ephemeral port on all interfaces. the -ORB[listen]endpoint[s] option
allows you to constrain the interface IP address, the TCP port, or both.
The portspan option can be used tell the server to select any port
from a narrow band, which allows a collection of servers to share a
limited group of addresses. None of this affects the client side.
With Bidir IIOP, the client side, outside the firewall say, still uses
an ephemeral port. It will also open a listen socket following the above
rules, but this socket is only used to supply an endpoint to the
callback objects profile. Part of the Bidir connection negotiation is
the client supplies the callback address as an alias. So the client may
have a listen socket open on address "CHost:45021" and the server is
listening on "SHost:12345." The client side of its connection to the
server might be on "CHost:50055" establishing a connection:
CHost:50055 <----> SHost:12345
This might be transport ID 100 to the server. The client will send a
Bidir service context to the server on some request message carrying the
alias "CHost:45021" whi server will then associate with transport ID
100. Effectively mapping the above connection to
CHost 45021 <-----> SHost:12345
Thus when the client sends the IOR for its callback object to the
server, and the server invokes on it, the server will find transport 100
in its cache since the IOR will include CHost:45021.
So if Graham's authentication requirement is that the endpoint the
callback goes to, (eg CHost:45021) be well-known, then he's golden.
However, if the scheme requires that the endpoint he connects from (eg
CHost:50055) is the well-known address, then an enhancement is necessary.
Post by Rob RatcliffRegarding client-side port binding, if you're not doing bidirectional IIOP where the outgoing connection can be reused for incoming
requests, I would think it would be almost required to be able to restrict the client-side ports to some port or range of ports in
order to be able to configure the firewall to allow these incoming connections on given ports. Why is it considered a "bad thing to
do"?
I'm not quite following the logic in the first request. Most firewalls
do not restrict access by inbound port number. If they did, configuring
a web browser would be a lot more complicated. They typically restrict
the port to which a connection is requested.
Why client side binding is considered bad, I suggest you review the
definition of a TCP connection, the TCP state machine, and the typical
behavior during socket closure. Since I'm sitting on my couch far away
from my Stevens vol 1. I'll give you a poor paraphrase...
A TCP connection is defined by the 4-tuple of (active host, active port,
passive host, passive port). There may only be one connection at a time
with any given combination. Frequently the passive port is some
well-known value. Since the hosts are constant, that means only the
active port can vary. If you bind the connector to a specific port, that
means no other process can use that port number to connect to the same
server host:port.
My point about the state machine is that TCP connections can continue to
exist for some time (could be minutes) after one side or the other shuts
down. Lets say your client application terminates while it still has the
connection open. The connection will end up taking time going through
fin wait 1, fin wait 2, and close wait before being reusable.
Finally, TAO is liable to open multiple client connections to the same
server. For example a multithreaded client wants to send two requests at
the same time, the second thread will open a new connection if the
existing connection is busy. Of course this behavior is configurable,
but it would be absolutely overridden if the client had to bind to an
already used port.
Post by Rob RatcliffIssues like these are why CORBA didn't flourish on the internet early on, the firewall problem wasn"t treated more seriously, not to
mention that the JRE's version of CORBA didn't support bidirectional IIOP. Now we're stuck with HTTP/Comet polling solutions, which
have pluses and minuses.
No, CORBA didn't flourish because MS didn't back it. And MS didn't back
it because it was an open standard. The firewall issue and the
definition of bidir was addressed fairly quickly, but CORBA wasn't
invented as an Internet infrastructure to begin with. Unfortunately it
has been overtaken by events, and so that's why firewall tunneling
hasn't been given the full treatment it requires. At one point, there
was a push to make a new "CORBA/i" specification which was to collect
the particular details for using CORBA in a broad Internet distribution.
However I've never seen anything beyond the initial announcement for that.
The JRE version of CORBA in general is pathetic, which is why JacORB and
other Java ORBs are so useful.
Best regards,
Phil
--
Phil Mesnier
Principal Software Engineer and Partner, http://www.ociweb.com
Object Computing, Inc. +01.314.579.0066 x225