Hi Yasassri, According to the 3.1 specification its allowed to have multiple subscriptions with the single connection,
In the SUBSCRIBE section under payload it specifies the following, "The payload of a SUBSCRIBE message contains a list of topic names to which the client wants to subscribe" Also we have a test case for this in the Paho interop test suite for this [1]. I couldn't run this recently but you should be able to verify against it on the functional behavior. Also ideally we need to port the test cases to our integration tests if something is missing WDYT ? @Pumudu/Ramith i am +1 for the approach and prioritizing 3.1.1 specification. [1] https://wiki.eclipse.org/File:Mqtt-test.zip Thanks, Pamod On Sat, Oct 3, 2015 at 4:25 PM, Yasassri Ratnayake <yasas...@wso2.com> wrote: > Hi Pamod, > > Do we allow multiple topic subscriptions with the same ClientID? As per my > observation we do not allow this. > > So if we do not allow this, there is no point in keeping a stale > connection. > > With Regards, > > On Sat, Oct 3, 2015 at 3:55 PM, Pumudu Ruhunage <pum...@wso2.com> wrote: > >> Hi All, >> >> @pamod, I also agree disconnecting is not the ideal solution. just >> thought from client side, since it's not getting any indication of not >> subscribing to the topic. >> >> Then implementation will be as follows. >> >> MQTT 3.1 - No error code send to client. >> MQTT 3.1.1 - Send error code 0x80 to client. >> >> Thanks, >> Pumudu >> >> On Sat, Oct 3, 2015 at 3:44 PM, Ramith Jayasinghe <ram...@wso2.com> >> wrote: >> >>> I think whats more relevant is to make v 3.1.1 case correct. >>> >>> >>> On Sat, Oct 3, 2015 at 2:03 PM, Pamod Sylvester <pa...@wso2.com> wrote: >>> >>>> Both versions of the protocol are supported at the moment AFAIK. >>>> >>>> So for 3.1.1 sending the error code is adequate. As mentioned in the >>>> previous mail there can be several topic subscriptions in one connection. >>>> So disconnection might not be the ideal solution IMO. WDYT ? >>>> >>>> >>>> On Saturday, October 3, 2015, Pumudu Ruhunage <pum...@wso2.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> Since we have to support both protocols we need implement both >>>>> behaviors based on protocols? right ? >>>>> IMO for 3.1 we need to indicate that it's not subscribed to the topic >>>>> by disconnection if it's not subscribed. otherwise it gives false >>>>> impression that client successfully subscribed to given topic. >>>>> >>>>> So can we agree on following implementation? >>>>> MQTT 3.1 - No error code send to client. Disconnect client >>>>> from broker. >>>>> MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ? >>>>> should we disconnect client from broker ?) >>>>> >>>>> WDYT ? >>>>> >>>>> Thanks, >>>>> Pumudu >>>>> >>>>> >>>>> >>>>> On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester <pa...@wso2.com> >>>>> wrote: >>>>> >>>>>> The CONNECT and SUBSCRIBE are two different command messages. The >>>>>> subscription phase comes after the connection. >>>>>> >>>>>> Also the other fact is a single connection could involve multiple >>>>>> topic subscriptions. So lets say if a given tenant sends a list of topic >>>>>> subscriptions there could be subscriptions which the tenant could be >>>>>> authorised among that list. So closing/refusing the entire connection >>>>>> might >>>>>> not be appropriate in this case. >>>>>> >>>>>> - 0x05 (Connection Refused: not authorized) is sent as an >>>>>> acknowledgement for CONNECT message (CONNACK). i.e a given client has >>>>>> provided unauthorised credentials etc. >>>>>> >>>>>> During this phase the subscription will not occur, we only could >>>>>> validate whether a given tenants credentials are correct or not. >>>>>> >>>>>> - When the subscription happens based on my understanding of the spec >>>>>> it has passed the CONNACK stage. The only way we could indicate an error >>>>>> related to subscription is through SUBACK. >>>>>> >>>>>> # The MQTT 3.1 specification has a limitation where error codes >>>>>> cannot be sent with SUBACK. Hence for 3.1 spec having subscription failed >>>>>> in silent mode is expected behaviour. >>>>>> >>>>>> You could find a similar discussion on [1]. Based on [1] what they've >>>>>> done is hacked the client and the server to accept error codes for 3.1 >>>>>> specification. This will not be clean and will not interop with other >>>>>> clients (even if we could hack the server to send error codes, the >>>>>> clients >>>>>> which has implemented according to 3.1 specification will not accept the >>>>>> error message). >>>>>> >>>>>> Another option is to initiate a disconnection from the broker to >>>>>> avoid stale connections. But then again as mentioned in the beginning if >>>>>> there're list of subscriptions for a connection, even the authorised >>>>>> subscriptions would not be able to consume. >>>>>> >>>>>> # The MQTT 3.1.1 specification there's an error code introduced >>>>>> 0x80 for forbidden subscriptions. So that should be the way we should >>>>>> ideally use for indication of an error IMHO. But it'll be available in >>>>>> 3.1.1. >>>>>> >>>>>> >>>>>> [1] https://issues.jboss.org/browse/ENTMQ-990 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya <hasit...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Yes, Connection Refused, not authorized is the best we can do. >>>>>>> >>>>>>> @Pamod, any batter alternative? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake < >>>>>>> yasas...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi Pumudu, >>>>>>>> >>>>>>>> MQTT spec doesn't talk about a permission model, So IMO the closest >>>>>>>> error we can propagate to the client is "0x05 Connection Refused, not >>>>>>>> authorized". >>>>>>>> >>>>>>>> >>>>>>>> With Regards, >>>>>>>> >>>>>>>> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage <pum...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> If a tenant don't have permission to subscribe to a given topic >>>>>>>>> (tenant 'a.com' try to subscribe to tenant 'b.com') currently it >>>>>>>>> will keep connected even though it's not subscribed, because user >>>>>>>>> authentication was successful. This is misleading to subscriber as no >>>>>>>>> return code sent and it's actively connected to broker. >>>>>>>>> AFAIK mqtt don't define how to handle tenancy scenarios in it's >>>>>>>>> spec. Couldn't find a definition in MQTT spec 3.1.0/3.1.1 on how to >>>>>>>>> reject >>>>>>>>> if permission denied to subscribe to a given topic(due to tenancy). >>>>>>>>> >>>>>>>>> One option to handle this scenario is to send return code 5 >>>>>>>>> (Connection >>>>>>>>> Refused, not authorized) to client if it doesn't have permission >>>>>>>>> to subscribe to given topic. This way client will disconnect if it >>>>>>>>> don't >>>>>>>>> have permission to subscribe. Is this acceptable or are there any >>>>>>>>> alternatives to handle this scenario? >>>>>>>>> >>>>>>>>> jira https://wso2.org/jira/browse/MB-1409 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Pumudu >>>>>>>>> -- >>>>>>>>> Pumudu Ruhunage >>>>>>>>> Associate Software Engineer | WSO2 Inc >>>>>>>>> M: +94 779 664493 | http://wso2.com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> Dev@wso2.org >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Yasassri Ratnayake >>>>>>>> Software Engineer - QA >>>>>>>> WSO2 Inc ; http://wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> *Mobile : +94715933168 <%2B94715933168>* >>>>>>>> *Blogs : http://yasassriratnayake.blogspot.com >>>>>>>> <http://yasassriratnayake.blogspot.com/>* >>>>>>>> * http://wso2logs.blogspot.com >>>>>>>> <http://wso2logs.blogspot.com>* >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Hasitha Abeykoon* >>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>>>> *cell:* *+94 719363063* >>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Pamod Sylvester * >>>>>> >>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>>>>> cell: +94 77 7779495 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pumudu Ruhunage >>>>> Associate Software Engineer | WSO2 Inc >>>>> M: +94 779 664493 | http://wso2.com >>>>> >>>> >>>> >>>> -- >>>> *Pamod Sylvester * >>>> >>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>* >>>> cell: +94 77 7779495 >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Ramith Jayasinghe >>> Technical Lead >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> E: ram...@wso2.com >>> P: +94 777542851 >>> >>> >> >> >> -- >> Pumudu Ruhunage >> Associate Software Engineer | WSO2 Inc >> M: +94 779 664493 | http://wso2.com >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Yasassri Ratnayake > Software Engineer - QA > WSO2 Inc ; http://wso2.com > lean.enterprise.middleware > *Mobile : +94715933168 <%2B94715933168>* > *Blogs : http://yasassriratnayake.blogspot.com > <http://yasassriratnayake.blogspot.com/>* > * http://wso2logs.blogspot.com <http://wso2logs.blogspot.com>* > -- *Pamod Sylvester * *WSO2 Inc.; http://wso2.com <http://wso2.com>* cell: +94 77 7779495
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
