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).
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;
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?
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.
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.
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.