On Tue, Nov 18, 2014 at 1:07 PM, Andrew Stitcher <[email protected]> wrote:
> On Tue, 2014-11-18 at 17:41 +0000, Gordon Sim wrote: > > On 11/18/2014 05:29 PM, Andrew Stitcher wrote: > > > On Tue, 2014-11-18 at 09:35 -0500, Rafael Schloming wrote: > > >> 2. Given that we have a distinct configuration phase regardless, it is > > >> simply unnecessary to force people to choose client vs server up > front. We > > >> can simply default the mode to client and have people set it to server > > >> during the configuration phase if that is what they wish. > > > > > > As clients and servers are fundamentally different in usage it makes no > > > semantic sense to me to create a client then "turn it into" a server. > > > > This is the context that I think I'm missing: why are they fundamentally > > different? > > Despite the AMQP protocol being symmetric once established, the > establishment cannot be symmetric. One party must initiate the > connection (the TCP client) and one must be listening (the TCP server). > That's a difference in the driver, not the transport. > > Clearly with respect to sasl, the distinction is important in order to > > infer their roles. Likely the same is true for ssl. The JIRA alsoclie > > mentions a server being able to automatically adjust to clients selected > > layers if desired, which sounds nice. > > Fundamentally a client must know which protocol layers it is going to > use, and a server can adjust the layers to whatever the client is using. > > > > > However this doesn't seem fundamental to me, it seems like a > > configuration of the handshaking behaviour after which usage will be > > pretty much exactly the same. > > I'm thinking that this handshaking behaviour *is* fundamental to the > purpose of the transport, as the major purpose of the transport is to > coordinate the layers that are used to process the incoming byte stream. > The transport client/serverness is not fundamental to the messaging > semantics layered on top of it though. > I think you're pointing to a difference in implementation, not API. Once, once a transport is configured, it's observable semantics are absolutely identical -- it just functions as a source/sink for bytes to send to/from the wire. This is true whether it is configured to be a client or server, whether it is configured to have a fixed set of layers or to be adaptable. --Rafael
