[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853704#comment-15853704
]
Rob Godfrey commented on DISPATCH-630:
--------------------------------------
I won't comment on how Dispatch should implement this, only that the notion of
enforcing a sole connection between two peers is also present in JMS (albeit in
JMS it is the second connection which should be denied, rather than the
original connection which must be terminated).
>From an AMQP perspective, the JMS client currently sends a desired capability
>"sole-connection-for-container".
I think we could extend this (as well as formalise - and possibly change - the
capability name) to the MQTT use case as well, by adding an associated boolean
connection property, something like "terminate-existing-connection-on-open".
Thus any client wanting JMS/MQTT-like sole connection behaviour MUST provide
this capability in the desired-capabilities of its open frame. If the client
further desires MQTT-like behaviour of closing the existing connection it must
also set the "terminate-existing-connection-on-open" property to true. If the
server is capable of providing "sole connection" behaviour it MUST include
"sole-connection-for-container" in the set of offered capabilities in its open
frame. The behaviour when a client establishes connections without the desired
capability and then establishes a connection desiring this capability is not
defined (i.e. the server only needs to be able to look up connections where
this capability was explicitly desired).
I'll try to write this up as a formal proposal for the AMQP technical committee
unless anyone has any strong objections.
> Detecting connections with the same container-id
> ------------------------------------------------
>
> Key: DISPATCH-630
> URL: https://issues.apache.org/jira/browse/DISPATCH-630
> Project: Qpid Dispatch
> Issue Type: Improvement
> Reporter: Paolo Patierno
> Priority: Minor
>
> Using the router in the EnMasse project and looking into the MQTT
> specification we have the following problem on the current EnMasse
> implemetation.
> The MQTT specification says the following ...
> Let's imagine that a client is connected to the broker with client id "1234"
> and that another client tries to connect with same client id. The broker will
> shut down the connection with first client opening the new one.
> Now with our MQTT support, the MQTT gateway can run as multiple instances
> (multiple pods) so this check can't be executed by the gateway locally
> because a client "1234" could connect to MQTT GW-1 and another client (always
> "1234") could connect to the MQTT GW-2 and the gateways don't know about each
> other. The common point they have is the router network inside EnMasse and
> the fact that for each MQTT client a new AMQP connection is created on the
> other side attaching a link with this name : $mqtt.to.<client-id>
> The following idea came ...
> If during the connection we use a container-id that is equals to the
> client-id, could the router have a feature for detecting connections with
> same container-id and providing a way to close the previous ones ?
> It should be an information shared (and cached ?) by routers in their
> inter-router protocol.
> If not at connection level, maybe at link attachment level ? (when two
> clients attach to the same $mqtt.to.<client-id> link)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
