Hi,
For a given application is there a limit to how many simulationous subscriptions can be made? As of March 2018, htdvisser suggested there isn’t, but I think we are encountering an issue related to that for one of our applications.
We were experiencing similar issues over the last days, but the issues resolved magically today. I suspect some stability issues of the TTN MQTT broker to cause that.
Over the last year we deployed multiple mechanisms to protect our application from these stability issues. See e.g. MQTT disconnects for other failure modes.
just curiousity ’ how many simultanious descriptions are we talking about ’ ?
hope @htdvisser can shed his light on this again
Unsure, as I never got a response from ops on slack. A student cohort (30 groups, 110 students) were consuming data from a network of our sensors that were hosted on TTN to demostrate their competence with message passing systems and processing/visualising raw data. We hit a problem whereby new subscriptions to a specific topic were failing. With the limited information we had, we suspected some dodgy student code was hanging connections and opening new ones and we were then hitting a max limit for a given topic (potentially even negatively effecting other TTN users as well). As we got no response from TTN ops whilst this problem was occuring, we instead put as much migitation ourselves by hosting our own internal broker and mirroring messages from our TTN topic on it. TTN’s broker doesn’t support bridging, so we simply did this by writing a small program that subscribed to our topic and then published messages on our own broker, we revoked the student access keys so their connections gradually dropped off from TTN’s broker.
2 Likes
So hundreds of active subscriptions coming from one IP ?
Again, as we couldn’t get any information from ops we simply do not know. Students work on and off a university campus. On campus we are a /16 (class B) network and therefore our network machines each have their own public IPV4 address, from an allocated block. Either singular IP addresses were creating multiple connections (bad practice by students) or we were always going to hit an upper limit just because of cohort size and unique IP addresses creating singular connections. Hence when this problem started occuring we asked on slack if there was a limit and following that, on this forum in order to try and understand which of the two scenarios we were most likely encountering so we could mitigate the problem better. From a security standpoint, we actually found hosting our own broker and mirroring TTN better - students could then see data, but wern’t going to be capable of publishing their own messages to the sensors! Also top tip - fuzz the sensor’s latlon a bit so they don’t get knicked!
1 Like