Re: callbacks in TAO

On 09/18/2011 01:21 AM, Rob Ratcliff wrote:
On 09/17/2011 10:58 AM, Phil Mesnier wrote:


It'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.

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


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


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

Relevant Pages

  • Re: callbacks in TAO
    ... most firewalls will allow you to poke a hole in it by port number and then redirect the request to some internal server with a given ... port and internal IP address. ... In this case the -ORBListenEndpoints command line argument is useful on the client side. ... client-to-server connection as its callback connection, but I would hope that bidirectional IIOP would work in this case...never ...
    (comp.object.corba)
  • Re: Passive means what during FTP?
    ... > server or the client that opens the data connection. ... the client tells the server what IP ... Vsftpd drops root after binding to port 21 entirely, ...
    (comp.os.linux.setup)
  • Re: Still cant connect to RWW or OWA remotely
    ... it certainly appears to be something about the SBS configuration. ... Meridian.local Ethernet adapter Local Area Connection: ... Windows SMALL BUSINESS SERVER 2003 Windows IP Configuration ... 192.168.254.254) directly to a port on the router and then ...
    (microsoft.public.windows.server.sbs)
  • Re: Still cant connect to RWW or OWA remotely
    ... it certainly appears to be something about the SBS configuration. ... Meridian.local Ethernet adapter Local Area Connection: ... Windows SMALL BUSINESS SERVER 2003 Windows IP Configuration ... 192.168.254.254) directly to a port on the router and then ...
    (microsoft.public.windows.server.sbs)
  • Re: forwarded-tcpip vs. direct-tcpip
    ... "direct-tcpip" is initiated by the client at any time with no ... network connection to some address and port number, ... "forwarded-tcpip" is sent by the server to the client after the ...
    (comp.security.ssh)