This content has been marked as final. Show 1 reply
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).