[
https://issues.apache.org/jira/browse/DISPATCH-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15853904#comment-15853904
]
Rob Godfrey edited comment on DISPATCH-630 at 2/6/17 12:25 PM:
---------------------------------------------------------------
{quote}
We've effectively got two similar but different cases where we want to ensure
the "client application" the spec gives example of as a container as being
essentially a lone connection at a time. I dont think we satisfy that simply by
saying the spec outlines things such that this shouldnt happen.
{quote}
I don't think we are actually saying different things at this point, just
looking at it from different perspectives.
In practice:
* A server consisting of a single process should always check a new connection
against existing connections with the same container id... If there exists a
connection with the same container id, and *either* connection has the sole use
capability, then
# if both connections desire the new connection to be refused, the new
connection should be refused
# if both connections desire the existing connection to be terminated, the
existing connection should be terminated
# if there is a mismatch between the desires of the old connection and the new
connection, then the new connection should be refused
* In the case of a cluster/network server then cases 1 and 2 should be honoured
to the best of its abilities, and the behaviour of case 3 is essentially
undefined, though if both connections want some sort of uniqueness but the
nature of the failure case is different we would expect the server to terminate
one of the connections
I think implementation guidance should be given to the above effect, but that
spec should be written to allow for network/clusters to be compliant for the
case of well-behaved clients. Neither of us expects a network/cluster to be
able to actually fully implement connection uniqueness in the face of "badly
behaved" clients I think.
was (Author: rgodfrey):
{quote}
We've effectively got two similar but different cases where we want to ensure
the "client application" the spec gives example of as a container as being
essentially a lone connection at a time. I dont think we satisfy that simply by
saying the spec outlines things such that this shouldnt happen.
{quote}
I don't think we are actually saying different things at this point, just
looking at it from different perspectives.
In practice:
* A server consisting of a single process should always check a new connection
against existing connections with the same container id... If there exists a
connection with the same container id, and *either* connection has the sole use
capability, then
# if both connections desire the new connection to be refused, the new
connection should be refused
# if both connections desire the existing connection to be terminated, the
existing connection should be terminated
# if there is a mismatch between the desires of the old connection and the new
connection, then the new connection should be refused
* In the case of a cluster/network server then cases 1 and 2 should be honoured
to the best of its abilities, and the behaviour of case 3 is essentially
undefined, though if both connections want some sort of uniqueness but the
nature of the failure case is different we would expect the server to terminate
one of the connections
> 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]
