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* *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
