Thanks for the detailed response. Here's some answers hopefully can help clarify things a bit.
* Are messages delivered once and only once?
A: MQTT allows QoS 0 (at most once), 1 (at least once), and 2 (exactly once.) The performance numbers in the blog are for QoS 0.
However, SurgeMQ implements all three and there's unit tests for all three. I just haven't done the performance tests for QoS 1 and 2.
* Are messages are messages delivered at least once?
SurgeMQ supports it though the numbers posted are for QoS 0 (at most once)
* Can messages be dropped entirely under pressure? (aka best effort)
No. Currently no messages are dropped.
* If they drop under pressure, how is pressure measured? Is there a back-pressure mechanism?
* Can consumers and producers look into the queue, or is it totally opaque?
Not sure what this means..sorry..
* Is queueing unordered, FIFO or prioritised?
Ordered, FIFO...MQTT spec requires that messages from publishers to delivered in the same order to the subscribers.
* Is there a broker or no broker?
* Does the broker own independent, named queues (topics, routes etc) or do producers and consumers need to coordinate their connections?
Brokers uses topics to route. Publisher publishes to a topic, subscribers subscribe to multiple topics w/ optional wild cards.
* Is queueing durable or ephemeral?
Ephemeral currently. Though MQTT spec requires that any unack'ed QoS 1 and 2 messages be redelivered when the server restarts or client reconnects. So once SurgeMQ meets that spec, it could be considered somewhat durable.
* Is durability achieved by writing every message to disk first, or by replicating messages across servers?
* Is queueing partially/totally consistent across a group of servers or divided up for maximal throughput?
Currently SurgeMQ is a single server w/ no clustering ability. However, MQTT spec does mention the bridge capability that is a poor man's cluster. Not yet implemented.
* Is message posting transactional?
QoS 1 and 2 starts to be more transactional. QoS 0 is strictly fire and forget.
* Is message receiving transactional?
* Do consumers block on receive or can they check for new messages?
Block on receive.
* Do producers block on send or can they check for queue fullness?
Block on send.
I wasn't expecting to make you fill out a survey. I was just trying to show off scars I and others I know have accumulated over the years :)
> Not sure what this means..sorry..
I'm definitely an amateur on this topic, but I suppose he talks about privacy issues. If you're delivering secrets you don't want that every actor can read the messages of all the others.
Some queues let you "peek". It's not common because it weakens the whole concept of a queue and tends to be difficult to implement sanely.