Transporter communication across firewalls, any suggestions?

[ckopec]

Here is the scenario I am trying to solve:

Client --- Firewall1 --- Internet --- Firewall2 --- Servers

On the right side, the firewall can be configured as needed to support port forwarding. The client knows the ip address of Firewall2. The client has data that needs to be passed to the Servers and the Servers have data that needs to be passed to the Client. The Servers data is however time sensitive. There can also be quite a few Servers therefore making polling rather inefficient.

The Client and Servers each have external APIs that are available. The data being sent should be encrypted, preferrably SSL.

At this point I am looking for options as to if Remoting will suite my needs? I started off using the SSLSocket Transporter which allows me to export an interface on both sides and form the connections with clients on each. However since then I discovered that the Servers will not know the address of the Client's firewall. Therefore eliminating this approach. It seems the most logical approach would be to use a bidirectional socket.

Does Remoting allow for bidirectional sockets at the transporter level? I saw some implementation of bidirectional sockets and ssl sockets at the lower invoker level. If not, is this currently planned? Do you know of any other options that may better suite my needs.

Thanks for any help you all can provide.

[ron_sigal]

Couple of points.

However since then I discovered that the Servers will not know the address of the Client's firewall.

As of Remoting version 2.2.2.GA, there is an undocumented facility for getting the address of the client as it appears to the server. If you do something like this:

 Object o = client.invoke("$GET_CLIENT_LOCAL_ADDRESS$");
 InvocationResponse response = (InvocationResponse) o;
 InetAddress newAddress = (InetAddress) response.getResult();

on the client side, newAddress will hold the address returned by calling Socket.getInetAddress() on the server side socket that received the invocation. That address could then be communicated to the server side. Maybe that could help?

I started off using the SSLSocket Transporter

Note that Transporters are a convenient wrapping of the Remoting callback facility, but they're not as flexible. If there's something you can't do with Transporters, you might want to look at callbacks.

One possibility might be the use of callbacks over the bisocket transport. The bisocket transport doesn't create a ServerSocket on the client side and doesn't need a client address to send callbacks. Instead, all connections are created from the client to the server. See Section 5.4.16. "Bisocket invoker" of the Remoting Guide (http://labs.jboss.com/jbossremoting/docs/guide/index.html).

Does Remoting allow for bidirectional sockets at the transporter level? I saw some implementation of bidirectional sockets and ssl sockets at the lower invoker level. If not, is this currently planned?

The next generation of Remoting is currently being developed, and it should have a purer form of bidirectional connection. There's a lot of discussion about Remoting 3 on the "Design of JBoss Remoting, Unified Invokers" forum: http://www.jboss.com/index.html?module=bb&op=viewforum&f=176).