Which QoS on meteor publish subscribe feature?

Hello

I am would like to know the QoS the meteor offers when publishing data due to possible ‘critical requirements’ of my future application. I can not find this info

At least once?
At most once?
Exactly once?

Persistence?

Thanks

P

Meteor delivers publication updates at least once, using a combination of MongoDB replication log tailing and clever polling. The client merges everything together so most of the time you don’t have to worry about multiple updates. The system relies on the persistent data existing in MongoDB.

You can also use the DDP pub/sub system directly without the database, in which case it’s more like a simple websocket transport with some nice features like reconnect and result aggregation. In that case it would be up to you to collect those updates from whatever source.

While the system is absolutely correct enough for any consumer app, there are a lot of things that can go wrong - disconnects from the database, various services going down, bugs in Meteor/Mongo/your hosting provider, etc. So any “guarantee” is always relative at the end of the day, and depends on the entire deployment environment. So it depends on what you mean by “critical”.

I was looking for an exactly once Qos… which means that the messaging infrastructure will guarantee that each message or pack of messages (records) will be delivered once (now or later) even if there are errors and reboots and crashes, etc at this time. Some say that I can control that on the receiving side but the idea is to rely on the infrastructure.

So, as far as I understood, meteor uses a best-effort QoS, is that right?
(may not be delivered, could be delivered, could be delivered more than once)

Does that even exist? Do you have an example of such a system?

I’m not really sure what kinds of systems we are comparing with here - other web frameworks? Databases? Medical control systems? In the space of web frameworks I’d say Meteor is “at least once” and tries pretty hard to do “exactly once” but doesn’t guarantee that in the case of disconnects.

There are lots of free/opensource messaging systems that support those 3 types of QoS. Example: Mosquitto(.net), where programmer can choose qos according to app requirements. I think they use a four or five handshake mechanism…

This post basically covers it:

No number of handshakes will get you exactly once.

Anyway, if you relax the idea of “exactly once” to “usually exactly once, unless something crazy is happening”, then Meteor does that.

God to hear that about “Meteor does that.”

However I do not agree with "No number of handshakes will get you exactly
once."
If we start from the principle that Messaging Systems are asynch systems
and do not guarantee you the time the message will be delivered (what they
are in reality, I think) It is completely possible to guarantee exactly
once, in my opinion… But it is ok, it iseems that meteor fit my needs.
Thanks