Is Http Firewall tunneling in Remoting or Messaging ?

[fatbatman]

Hi,

I have an applet on a public webpage that needs to communicate with a server.
The applet needs to be able to make synchronous and asynchronous method calls on the server.
The server needs to send asynchronous (callback) messages from the server to client.

The applet may be behind a firewall that only allows outgoing http connections, so firewall tunneling is a definite requirement.
I was planning on using JBoss http Remoting but after playing around a little and reading the pages below, I've realised it doesn't support transparent http firewall tunneling, yet.

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91135&start=40
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensions
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensions_Deux

Are the JBossMessagingRemotingAPIExtensions related to http firewall tunneling being temporarily added to the Messaging project?, or are they being implemented directly into Remoting? Are their timeframes estimates for this?

I have a live multiplayer turn based gaming server, which currently uses a custom protocol over a bidirectional direct socket connection using nio.
The current solution doesn't support http firewall tunneling and I'd prefer to move to a "transparent" communication system such as Remoting rather than implement this myself. As such I'll be happy to test out the new features of Remoting, when available, as they have the potential to be very useful to me.

regards

James

[tom.elrod]

Guess the first question is what type of firewalls are you trying to by-pass? If is just a simple firewall that only allows outbound connections on any port but does not allow inbound connections, can use the remoting multiplex transport which will allow the server to communicate back to the client over the same physical outbound connection established by the client.

If the firewall actually checks the request header to verify it is indeed an http request, then would be forced to use the remoting http transport. Can still get callbacks from the server using the http transport, but would have to do using polling, so there would be a slight delay in getting those callbacks.

In the case of multiplex transport, remoting only supports synchronous callbacks at the moment (but are currently working on support for async callbacks as well).

[fatbatman]

Well it's an applet on a public website, so it should work behind all types of firewall/proxy server, however fussy they are.

Regarding firewalls that prevent all but outgoing http requests; remoting doesn't have to use polling. The client can make an http request that blocks on the server until there is data to be sent to the client, http keep-alive will keep the connection open (but you need a heartbeat message to check when this is dropped and reconnect). This allows real time calls to be made from server to client without polling, even when the firewall only allows outgoing http connections.
You would use a seperate connection for client to server calls.

This example shows the principle behind this, its using RMI but principle is the same;
http://wiki.java.net/bin/view/Communications/FirewalledClients
This solution isn't very scalable though as you need a thread waiting for each client, a better solution would be to have something similar to the nio "Selector" so you don't need a thread per client, at least not for async callbacks.
Saying that even this approach will fail with a few very awkward proxy servers, that cache data up only deliver it when there is more than say 16k to deliver. In that case polling is the only option. When establishing a connection it should perform some very quick tests to use whatever is possible.

Anyway, my point is as an application developer I don't want to be doing all this stuff, we just want a way of sending messages from client to server, and vice versa without having to worry about the protocol or the firewalls/proxies that are in the way. From my understanding that is what JBoss remoting will eventually offer, am I right?

[tom.elrod]

Well, there is only so much we can determine on our own about network environment (i.e. does firewall exist between client and server, is external address of server different than local one... i.e. NAT), so will have to be some configuration determined by the remoting user. For now, server to client communication using http transport can only be done by establishing a new connection from server to client (which firewalls won't allow) which we call "push" callbacks or via polling, which we call "pull" callbacks.

I'll look more into adding to the implementation something like you mentioned where establish client to server connection that keeps the channel open looking for data from the server. As for NIO behavior, we won't have anything like that till remoting 3.0.

[fatbatman]

Its possible to go through a series of steps when establishing a connection, to see what is possible. For example the client could firstly attempt a plain bidirectional TCP connection, if this fails, try the next approach etc, etc.

Obviously if you know in advance that only a certain type of connection will be possible then that could be specified, perhaps as a parameter for the "connectToServer" method or simiar.

[ron_sigal]

Hi James,

In response to your suggestion, a blocking version of pull callbacks has been introduced in Remoting. See the thread "New blocking mode for pul callbacks" (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057082#4057082) on the Remoting developers forum for some details.

-Ron

[ron_sigal]

I put the same information on the users forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111759&start=-10&postdays=postDays&postorder=postOrder&highlight=highlight.