[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Multiplexed (Bidirectional) Transport

[ron_sigal]

1. There is another solution to the firewall problem.

anonymous wrote : 
  | What I don't agree with is the need to have callback servers, as in pieces of code wrapped around server sockets on the client side . Once you have a TCP/IP connection from client to server, use that and don't open another one from server to client
  | 

Tom implemented a polling callback mechanism [I think it was requested by the Messaging group] which simulates the use of a callback server on the client side.  I've used it on the Branch_HTTP_Experiment Messaging branch to avoid client side server sockets with the HTTP transport, but it would work with the socket transport as well.  There's some latency according to the (configurable) polling frequency, but it also has the advantage of bundling up all pending callbacks in a single transmission.

2. I'm not sure what a bidirectional channel would look like in Remoting, but there's a sense in which Remoting connections are close to a bidirectional channel.  From client to server, there's the option of an invocation which is asynchronous at the application level, i.e., it returns immediately, and with the NIO transport it will be asynchronous at the transport level.  From server to client, callbacks are not too conceptually different from asynchronous invocations.  A payload is passed to Remoting and on the other side it lands on an application level handler.  It may not be as elegant as a bidirectional channel, but I'd guess performance trumps elegance right now.  And I'd say that Tim has done a pretty virtuoso job of working with the materials at hand.

3. As for the performance of the current multiplex transport, the only honest answer I can give is that I don't know how much better it can be.  I went through one round of optimization a few months ago, but in the absence of customers it wasn't clearly productive to keep squeezing.  There is certainly overhead in lifecycle operations, but the real issue is pushing bytes on the network.  I don't think the presence of virtual sockets is really a problem - there's a lot of code there that makes them look like real sockets but isn't in the line of fire most of the time.  If there's room for improvement, I think it must be at the layer below virtual sockets.  Right now a VirtualSocket.write() operation leaves some bytes on a queue, from which they are retrieved by another thread which writes them to the actual socket.  The point was to allow the write() to return without waiting for the network i/o to finish.  But in the optimization phase I switched to NIO sockets (except for SSL connections), so that issue is moot, and maybe there's some improvement to be gained by directly accessing the socket.  

It does seem to me that, in terms of i/o, virtual sockets shouldn't be significantly slower than real sockets.  I'd be happy to have another go at it.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979282#3979282

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979282