> 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.
I'm talking of the broker listening for connections on the host. I
gather it has to listen on tcp sockets, else (in the case of unix
sockets) it'll be accessible only from that particular host, which may
not be desirable. Is this correct?
We don't need the host broker to listen on tcp for external connections.
We can tell the host broker to connect externally to another outside
broker that is listening. This model makes more sense since it is
probably easier to configure all hosts with info on what central broker
to connect to vs. configuring the central broker with the address of
every host that it needs to connect to.
Also, if the transport is pluggable, why couldn't we have a broker that
can use tcp to connect to an external broker and also use sockets
specifically for host/guest communications? That is where I thought we
were going with this from our initial discussions w/ tross.
> 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?
>
> It seems like we're overcomplicating things here by introducing tcp into
> the mix.
On the contrary, I think things just become simpler by having much less
code and the same piece of code working on the host as well as the
guest.
However, if it's desirable to have non-tcp connectors in qpid for other
reasons, we can have a virtio-serial connector for the guest.
If you think it is simpler overall, then I agree. I just had the
impression from prior discussions that utilizing tcp would be
heavyweight (as compared to sockets) and introduce additional
configuration complexity.
But if it's as simple as you're indicating, then go ahead and proceed.
Perry