Re: [mqtt] Limit of MQTT?

[Nicholas O'Leary]

Hi,

As a protocol, mqtt imposes no such limits.

Individual broker implementations may have limits, although most I know of don't have fixed limits and will be constrained only by the resources available, ie memory.

What happens when any such limit is reached is also not defined... Aside from on connect where the broker can refuse the connection with a suitable return code telling the client the broker is not currently available.

Nick

On Friday, May 17, 2013, Mit Dac wrote:

Hello, i'm newbie on MQTT and has some question need to help:

- Has limit for number of subscriptions per connection? What happen if a

client subscribes too many topic?

- Has limit for number of topics/connections on a broker?

Thank for any help!

--
--
To learn more about MQTT please visit http://mqtt.org
 
To post to this group, send email to mq...@googlegroups.com
To unsubscribe from this group, send email to
mqtt+uns...@googlegroups.com
 
For more options, visit this group at
http://groups.google.com/group/mqtt
 
---
You received this message because you are subscribed to the Google Groups "MQ Telemetry Transport" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Raphael Cohn]

Mit,

If it helps, I'll share our broker's strategy for managing this. We allocate a fixed size buffer space from a central quota for holding the subscription topic strings. (A string pool, if you like). This is per-connection. We manage it as a ring buffer, so when the size is exceeded we can either terminate the connection or silently replace the oldest. Being a fixed size means that it's impossible to predict how many topics would fit, but it's definitely usually in the 10s.

If you're subscribing to more than that for one connection, then it's a strong hint to examine the design of your topic hierarchy or to have more specialised per-connection processes (always a good thing in most designs, as it's easier to test).

Connection limits vary depending on the network stack design. Some brokers top out in the 1,000s; we can scale beyond 50,000. If your chosen broker has a low number of subscriptions for what you want, then a simple design is introduce multiple brokers as an intermediary, and do scale out or vertical partitioning of the topic space.

Raphael Cohn
Chief Architect, stormmq

Co-Chair, OASIS MQTT Standard

Secretary, OASIS AMQP Standard
raphae...@stormmq.com

+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com

[Dave Locke]

As Raphael mentions one of the important aspects of any pub sub system is the design of the topic space / hierarchy.  Wild cards can come in very handy. Taking an example a solution that contains set top boxes and  a number of devices connecting to each set top box.   A basic topic space might look like  device/<settopbox ID>/<device ID>    The set top box opens a single MQTT connection to a central MQTT server.  It could subscribe to an absolute topic for each device e.g.  device/STB1/Dev1  device/STB1/Dev2  and device/STB/DevN . With the use of wildcards the number of subscriptions can be reduced to one no matter how many devices there are e.g. device/STB1/#

The scalability of MQTT systems is improving all the time for example the recently announced IBM MessageSight appliance can handle 1 million concurrent MQTT connections at very high message rates.

All the best
Dave  

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU