Re: callbacks in TAO

Phil,

Thanks for the nice explanation on inner workings of bidirectional IIOP. (I've been meaning to buy a copy of Stevens' books as well.)

On 09/18/2011 02:20 PM, Phil Mesnier wrote:

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.

Just to clarify, when I mentioned inbound it is the server attempting to connect to the client's socket not vice-a-verse. I believe
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.

Why client side binding is considered bad...

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.

The client also has to notice a server dropping or network going bad. The only way I know of to actively detect stale connections is
to actively "ping" the connection. If the server needs to actively "ping" the client to ensure that it hasn't dropped.


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.

I think many times the client is some type of GUI that wants to receive asynchronous updates from the server via a single callback
object. I have created clients with multiple callback objects using other proprietary protocols where the client used multiple
client-to-server connection as its callback connection, but I would hope that bidirectional IIOP would work in this case...never
tried that.


<off-topic>
The long HTTP poll approach that today's "Comet" applications use with HTTP + Ajax has one advantage that if the connection goes bad
(network glitch say), the server state has to be setup for the client to reconnect and continue on. That may encourage more robust
logic. It suffers though from server timeouts forcing the client to reconnect and browser connection limits. Can you think of other
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.

I think CORBA is still about the most mature and feature-complete multi-lingual messaging layer out there. Google Protocol Buffers
and the like don't address the full solution like CORBA has. (CORBA could use a refresh on the Java bindings though or a more
flexible bindings scheme similar to JAXB and JAXWS.)

The JRE version of CORBA in general is pathetic, which is why JacORB and other Java ORBs are so useful.

Yes, it would be nice if the JDK just adopted JacORB as the Java ORB. Then bidirectional IIOP would be fully supported as well as
all the other nice features and robustness.

Perhaps with the modularization of the JRE in Java 8, it will be easier to replace the default ORB.

</off-topic>

Thanks,

Rob

.

Relevant Pages

  • Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
    ... That's the problem tunneling (port forwarding) solves. ... >>can't get past the client firewall. ... > I don't understand why the server would be making the ... server initiates another connection to the client -- in this ...
    (Debian-User)
  • Re: Using Remote Desktop From an SBS Domain
    ... when you tried to RDP while attached directly to a port on your router? ... So if 3389 needs forwarded on the client end too then that is what the ... Hopefully next week I can attempt a connection while my ISP watches the ...
    (microsoft.public.windows.server.sbs)
  • 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: callbacks in TAO
    ... have you tried just specifying the port range on the client side ORB? ... 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. ... Part of the Bidir connection negotiation is the client supplies the callback address as an alias. ...
    (comp.object.corba)
  • Re: HTTP DDoS attack on our servers
    ... A quick googling for TCP port 45836 turns up the following page at ... The worm creates a remote access server by listening on TCP ... > Basically,> 8.000 IP numbers are sending HTTP requests to our server on ... > connection after the first sent line, ...
    (Incidents)