On 02/08/2011 12:38 PM, Perry Myers wrote:
On 02/08/2011 07:19 AM, Amit Shah wrote:
> Hello,
>
> On (Thu) 16 Dec 2010 [09:31:43], Ted Ross wrote:
>> There has been some discussion about what the strategy for
>> Qpid-over-virtio-serial should be. One of the newer considerations
>> is that the local broker (on the guest) should be optional and is
>> considered an optimization (for connection concentration). Not
>> using a local broker makes for a significantly simpler system
>> configuration.
>>
>> This leaves two possible approaches:
>>
>> 1) Build a virtio-serial plug-in for Qpid
>> 2) Build a tcp-socket proxy that multiplexes tcp connections over
>> virtio-serial
> OK, I went through the qpid code today and did a few test runs. The
> design of qpid is to have one broker listen on tcp sockets and any
> number of clients. Some of these clients could really be servers that
> can respond to requests they can handle from clients.
I'm not grokking this paragraph. The transport plug-ins provide
connectivity between client and broker or between broker and broker.
For TCP, the broker acts as a server (i.e. opens the "listening"
socket), but this is not required by the AMQP specification. All the
transport (pair of plugged-in modules) needs to do is establish
point-to-point connectivity by some means over some protocol and then
let the AMQP handshake begin (the first PDU is sent by the client).
> With this design, we can safely rule out using unix domain
sockets for
> communication (this could have been an option on the host for
> qemu<->broker connection).
I'm not sure I understand. Ted has always maintained that the tcp
transport for both the brokers and the core qpid libraries was contained
in a pluggable transport.
So of course the current implementation of the broker listens on tcp
sockets. The goal was to write a _new_ transport plugin so that the
broker could use a different transport other than tcp.
Can you explain further?
Ted, you've been the one indicating that we could swap out tcp for a
different type of transport (in fact you said you even had an example of
a serial port transport which I would assume doesn't have tcp anywhere
in the stack). Can you point Amit at your prototype serial port transport?
As Carl pointed out on this thread, there is an RDMA transport in the
Qpid project that is not TCP based.
The serial-port code I wrote is actually a bridge, not a transport. It
does not carry the AMQP protocol but carries message headers and content
between two AMQP clients.
It seems like we're overcomplicating things here by introducing
tcp into
the mix.
Perry
> with that in mind, we can only have a tcp connection from qemu on the
> host to the broker (which could be on another host). There are two ways
> of doing this from qemu:
>
> 1. qemu acts as a tcp client:
> - in this case, qemu connects to a broker. The conditions for this to
> work are: the broker must be started before qemu starts (else qemu
> will wait till the broker comes up), and if the broker goes down
> while qemu is running, the qemu instance won't be able to connect to
> a new broker again (this is fixable, but doesn't exist in current
> qemu and it'll take a while doing it upstream).
>
> 2. qemu acts as a tcp server:
> - In this case, some external program has to connect to qemu on one
> end and the broker on the other end and relay data.
>
> We can rule option 1 out given the constraints. So we'll need a small
> program to run on the host that connects to either end and relays all
> the information.
>
> On the guest side, we have the two options you enlisted above. I
> checked the Connection, ConnectionImpl and *Connector code that would be
> needed to get a virtio-serial connector. It's doable, but small program
> I mentioned above to run on the host can very easily also work without
> much of a difference on the guest as well, creating a tcp server on one
> end for clients/servers to connect to and connecting to the
> virtio-serial port on the other end to relay information in both
> directions.
>
> So it looks to me that option 2 that you mentioned above should be the
> way to go. It'll be trivial to code and should be ready quite soon.
> Let me know if you agree with this, and I'll get working.
>
> Amit
> _______________________________________________
> Matahari mailing list
> Matahari(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/matahari