Protocol vs Connection vs Channel

[bollhals]

In the light of #924, I'm trying to understand how they're connected and what is responsible for what.

From what I gather of the protocol creates the correct Connection & Model, but not the session, the session is done by the sessionmanager of the connection.

Is the connection implementation therefore protocol specific, but if so, then why is the connection using the protocol to resolve a channelclose command? (CreateConnection / CreateChannelClose / ChannelCloseWrapper)

Either I'm missing something, or the current separation is not strictly enforced. If so the question is, where do we want to end up?

[michaelklishin]

IIRC we have dropped AMQP 0-8-0 and 0-9-0 support, if not, we should. Even RabbitMQ 2.0 implements AMQP 0-9-1.

I also suggest that we do what Java client does and simplify to a Connection, ChannelManager (mostly maps and allocates channel IDs) and Channel which would be aliased as a Model for reasonable backwards compatibility.

[stebet]

Yeah, I thought about the same thing. It'd make sense to have the connection just take care of the handshake, socket handling,(de)serializing frames, channel creation and forwarding commands with channel ID > 0 to the appropriate channels (via a ChannelManager as suggested). That sort of splits the logic up between connection logic and actual message handling logic.

[michaelklishin]

@stebet that's what Java, Ruby, and Erlang clients do (the latter is more complicated because it supports two types of connections, one uses Erlang distribution and not a separate TCP connection per AMQP 0-9-1 connection). So this split is present in three otherwise moderately or very different clients.

[lukebakken]

Yes, the current code is much too complicated. I would like to remove ISession in 8.0 and just have Connections and Channels, pretty much.