[OASIS Issue Tracker] (AMQP-126) Sole Connection Detection Policy needs clarification

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQP-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66296#comment-66296 ] 

Rob Godfrey commented on AMQP-126:
----------------------------------

{quote}
What is interesting is that if the enforcing container uses the strong detection policy a remote node that does not implement this specification but is fully AMQP 1.0 compliant will have its connection refused (i.e., closed) with the "invalid-field"/"container-id" as the only indication as to why even though from an AMQP 1.0 point of view the given container-id is completely valid. 
The same thing can happen with both the weak and strong detection policy if the requesting container requests the "close-existing" policy while the existing connection does not implement this spec.
{quote}

So, remembering that the container id is supposed to be a unique identification of the container, either the remote container is suffering from temporary amnesia (since it previously knew about and requested the detection of the duplicate connection detection), or otherwise the same identity is being used for two distinct containers, which is an error in itself.  Note that the consequences of two containers "sharing" a container-id are very undesirable (e.g. link stealing) - enforcing detection is actually a much better situation than container-id collision.

> Sole Connection Detection Policy needs clarification
> ----------------------------------------------------
>
>                 Key: AMQP-126
>                 URL: https://issues.oasis-open.org/browse/AMQP-126
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Sole Connection
>    Affects Versions: soleconn-WD2
>            Reporter: Lorenz Quack
>
> I find Section 3.2.2 of the specification unclear.
> To wrap my brain around the rules and when a certain detection policy would trigger the enforement policy I consider 4 cases: an existing connection does/doesn't have sole connction enforement (SCE) permutated with the new connection having/not having SCE.
> Then my reading of the spec gives me this table:
>   | old conn |  new conn ||  "strong" | "weak"
> 1 | NO SCE   |  NO SCE   ||    no     |   no
> 2 | NO SCE   |     SCE   ||    no     |  yes
> 3 |    SCE   |  NO SCE   ||    yes    |   no
> 4 |    SCE   |     SCE   ||    yes    |  yes
> Do people agree with my reading of the spec?
> Was it intended this way?
> In the "strong" case I find the asymmetry between case 2 and 3 surprising.
> I find it surprising that the weak policy should trigger in case 2 where the "strong" policy does not.
> My guess is that the intention was that the strong policy also triggers in case 2.
> Overall, I find it hard to see a clear intention behind the two detectoin policies.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)