Tom wrote : | Although a callback server is needed on the client side, this does not necessarily mean a server socket is needed. | Why would be a callback server exposed in API and required to be explicitely created on the client side? You only need to create a client for a specific server and then declare that you want to receive push callbacks from that server. All you need from an API point of view is to call client.setListener(CallbackListener) The server knows exactly what client added the callback listener, so if the connection happens to be over a bidirectional transport, the server knows how to get back to it. No need to expose the callback server in API in this case, it only adds extra complexity. For a unidirectional socket transport, yes, fine, but we want to improve the API, not stick to something that doesn't exactly fit our needs. Ron wrote : | There is another solution to the firewall problem. | 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. | ... and it will be horribly slow. Why complicate things? Bidirectional TCP socket connection, it's all we need. And polling for HTTP, but there is no way around that there. Ron wrote : | 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, | Tim wrote : | Ron wrote : | | 2. I'm not sure what a bidirectional channel would look like in Remoting, | | | I was thinking something vaguely similar to the Channel interface in Java NIO, except it would need to support both synchronous and asynchronous invocations. | I'll very soon publish some suggestions to amend the Remoting API. It only adds things to it, and keeps everything else pretty much as it is, so current application won't break. It'll be a wiki document, I'll link it here. Tim wrote : | Also, what does the current wire format of the multiplex transport look like? Is it based on frames? Or some other way of doing it? | I don't think we should even touch the current multiplex transport. It doesn't make sense to do that for AMQP. In AMQP we don't control the client, the concept of invocation is irrelevant, we just get a bunch of bytes on the wire, so we need to add a protocol handler on the server that "generates" invocations out of the protocol stream. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979558#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...