5 ms·

Use it right. It's not a message bus. XMPP is a chat protocol. Message delivery is not guaranteed.

rakoo 10y ago
Same old, same old: Core XMPP doesn't provide guaranteed delivery, but Extensions do, and today XMPP is more or less unusable without Extensions. I'm talking about XEP-0184 (https://xmpp.org/extensions/xep-0184.html https://xmpp.org/extensions/xep-0184.html) which is pretty much used in all maintained clients and servers. Note that XEP-0184 provides end-to-end delivery receipts; if you're only interested in hop-to-hop delivery, you're going want XEP-0198. I believe this one is a bit less widespread though.
- SamWhited 10y ago
  For guaranteed delivery you really want XEP-0198 (http://xmpp.org/extensions/xep-0198.html http://xmpp.org/extensions/xep-0198.html) which effectively provides TCP like ack's and session management at the wire protocol level. It's fairly straight forward to implement, and works really well for both chat and message bus style applications where acks are required.
  - rakoo 10y ago
    I think it really depends about what we mean by "guaranteed delivery". If you are more interested in the infrastructure and consider each piece as a different part then yeah, hop-to-hop reliability is important to you and you want XEP-0198. That's like "guaranted delivery of a packet". If however you are more interested in the application that sits on top of the infrastructure, then what you really care about is whether the recipient did receive your message: that's XEP-0184. That's more like "guaranted delivery of a message". Of course both are complementary (and to me both should be implemented)
thom_nic 10y ago
IQ messages are "guaranteed" at the protocol level. E.g. recipient is required by the protocol to reply, so pretty much all XMPP libraries make it easy to handle an IQ send with a reply timeout. This is not quite the same as "guaranteed delivery" but if you get a reply for your IQ you know it was received. So XMPP gives you request/reply as well as one-way fire-and-forget semantics. This, in conjunction with presence (so I have a good idea if recipient is currently online) give fairly strong toolkit for reliable M2M messaging.

rakoo 10y ago

Same old, same old: Core XMPP doesn't provide guaranteed delivery, but Extensions do, and today XMPP is more or less unusable without Extensions. I'm talking about XEP-0184 (https://xmpp.org/extensions/xep-0184.html https://xmpp.org/extensions/xep-0184.html) which is pretty much used in all maintained clients and servers. Note that XEP-0184 provides end-to-end delivery receipts; if you're only interested in hop-to-hop delivery, you're going want XEP-0198. I believe this one is a bit less widespread though.

SamWhited 10y ago
For guaranteed delivery you really want XEP-0198 (http://xmpp.org/extensions/xep-0198.html http://xmpp.org/extensions/xep-0198.html) which effectively provides TCP like ack's and session management at the wire protocol level. It's fairly straight forward to implement, and works really well for both chat and message bus style applications where acks are required.
- rakoo 10y ago
  I think it really depends about what we mean by "guaranteed delivery". If you are more interested in the infrastructure and consider each piece as a different part then yeah, hop-to-hop reliability is important to you and you want XEP-0198. That's like "guaranted delivery of a packet". If however you are more interested in the application that sits on top of the infrastructure, then what you really care about is whether the recipient did receive your message: that's XEP-0184. That's more like "guaranted delivery of a message". Of course both are complementary (and to me both should be implemented)

thom_nic 10y ago

IQ messages are "guaranteed" at the protocol level. E.g. recipient is required by the protocol to reply, so pretty much all XMPP libraries make it easy to handle an IQ send with a reply timeout. This is not quite the same as "guaranteed delivery" but if you get a reply for your IQ you know it was received. So XMPP gives you request/reply as well as one-way fire-and-forget semantics. This, in conjunction with presence (so I have a good idea if recipient is currently online) give fairly strong toolkit for reliable M2M messaging.