1 Reply Latest reply on Nov 20, 2008 10:46 PM by Ron Sigal

    Streaming transport

    Matthew Hibberd Newbie

      Hi All,

      Just a quick question with regards to transport available for streaming.

      I want to be able to stream files from a client to a server. But cannot have the server initiate a new connection back to the client, as the client will most likely be behind firewall(s) etc etc. Is it possible to have streaming use bisocket transport (for example) in any current production version of Remoting?

      The above links suggests the answer to my question is no, but it is dated quite old so was just curious if this was still the case.


        • 1. Re: Streaming transport
          Ron Sigal Master

          Interesting question. I've never tried it, but I'm guessing that you can use the bisocket transport. See the org.jboss.remoting.Client method

           * Takes an inputstream and wraps a server around. Then calls the target remoting server and
           * passes proxy for an inputstream to the server's handler. When the server handle calls on this
           * proxy, it will call back on this server wrapped around this inputstream. The InvokerLocator
           * passed is used to create the internal Connector used to receive the calls from the server
           * side.
           public Object invoke(InputStream inputStream, Object param, InvokerLocator streamServerLocator)
           throws Throwable

          You can request the use of the bisocket transport through the InvokerLocator parameter.

          The bisocket transport was designed specifically to support pushing callbacks from the server side to the client side without opening a port on the client side. There is a callback Connector on the client side, and the server side pushes callbacks by making invocations on the callback Connector. In the case of streaming a file from the client side to the server side, there is also a Connector on the client side which streams the file by responding to invocations from the server side requesting more bytes. So I think that the infrastructure set up for callbacks can probably be reused for streaming, though you might have to trick it a little.

          There are a couple of subtleties that I can think of off hand.

          1. The version of Client.invoke() listed above creates the streaming Connector. You need to tell the streaming Connector not to open a port, which you do by setting the "isCallbackServer" parameter to "true", which you can do on the InvokerLocator.

          2. The mechanism that enables creating connections from the server to the client without a port on the client is initialized when you configure push callbacks, i.e., when you call Client.addListener(). So you'll need to set up a dummy callback connection to get things started. If you want to be clever, you could use the same Connector for callbacks and streaming by using the versions of Client.addListener() and Client.invoke() that allow you to pass in a preconstructed Connector.

          3. On the server side, the Client that connects to the streaming Connector needs to think that it's involved in push callbacks so that it doesn't try to create a connection to the client side by calling a Socket constructor. It will think that if it finds a "listenerId" parameter, with any value, in its configuration, so you should add something like "listenerId=dummy" to the streaming Connector's InvokerLocator.

          Nasty, huh? I'm not promising this will work, but I think it might. If you play with it, let us know.