[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Messaging and Remoting - Multiplexed (Bidirectional) Transpo

We want to use the same physical TCP/IP connection to send data from client to server AND asynchronously, from server to client. Once this is available, the client won't need to create its physical callback server anymore. Callback servers cannot be used in firewalled environments, and even in common LAN environments they are liable to introduce complications. Tim wrote : | Another issue I have is the remoting core abstraction being a unidirectional connection. This forces remoting to have to introduce the concept of callback servers to be able to handle communication from the server to the client. | The "callback listener" model is a good abstraction to receive asynchronous notifications from the server, and it fits well with the whole remoting API. 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. Principle aside, there are also a lot of "practical" complications that arise when firewalls or funky host configurations come into play, and we had a good share of those reported by users. Tim wrote : | The current multiplex transport if I remember correctly has some significant overhead as compared to the standard socket transport. It's my understanding that this is due to having to design this in terms of virtual sockets so it can work with the core remoting abstraction of a unidirectional connection. | | If remoting had used a bidirectional connection this would have been much simpler IMHO. | | With a birectional abstraction, multiplex connections are not a hard problem to solve. After all you just need to encapsulate each lump of bytes written in a packet with the id of the logical connection and the length of the packet and simply correlate them on receipt according to the id and send them off to logical connections. (Actually when we get to AMQP we _must_ implement multiplex this way - we have no options since it is a requirement of the specification) | | I can see how this would become more difficult to implement if you only have a unidirectional remoting abstraction to work with, and have to somehow unite the two remoting connections (one in one direction and one in another) so they actually use the same connection. | I am sure this can be simplified, by leaving the current multiplex transport alone, and implementing a "light-multiplex" that doesn't try to offer anything like "virtual sockets", but it just carries bytes from client to server and vice-versa. I will start working with Ron or Tom on that. Tim wrote : | The fact is, that we can't afford any overhead in the multiplex transport since we'll lose in benchmarks because of this. | True. To me, this is one of the highest priority now. Tom Elrod wrote : | There is currently a multiplex transport (as Ovidiu noted) and how it works under the hood is explained at http://labs.jboss.com/portal/jbossremoting/docs/multiplex/multiplex.html . | Its performance is not great (see http://labs.jboss.com/portal/jbossremoting/docs/benchmark/performance_ben... for comparison benchmarks). Ron can probably comment more on how much more performance we can expect to sqeeze out of it. | Tim wrote : | I suspect this would require changes to the remoting API - specifically in the area of bidirectional connections as I have discussed. | Maybe not. Let's see what Ron has to say. Ron, you have the microphone. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979219#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...