4 ms·

Guaranteed delivery is super easy. Oh, then why do you propose a wrong solution right there in your next paragraph? you call and the server with your payload,

by moe 14y ago

Guaranteed delivery is super easy. Oh, then why do you propose a wrong solution right there in your next paragraph? you call and the server with your payload, and inspect the server response. Wait, what if the response gets lost on the way? Are your messages idempotent? Do they depend on state on the other end? How long are they valid? Is each message atomic? You may want to take a look at http://en.wikipedia.org/wiki/Two_Generals%27_Problem http://en.wikipedia.org/wiki/Two_Generals%27_Problem and http://en.wikipedia.org/wiki/Atomic_commit http://en.wikipedia.org/wiki/Atomic_commit Guaranteed delivery can become quite tricky depending on which constraints you can and cannot enforce in your system.

ojilles 14y ago
Completely agree. One small correction: "Guaranteed delivery can become quite tricky" should roughly be: "Guaranteed delivery ARE quite tricky, if not, you have not run into all contraints yet."
- Spearchucker 14y ago
  Can you actually list these constraints? If not all, at least some examples? I've not encountered any I'm not handling [1]. My code has been running on various device types and under all sorts of loads for years, and have yet to encounter something not handled as described above. [1] If you're referring to guaranteed delivery in the sense of guaranteeing that your message is delivered to a person that is guaranteed to action the message, then this is not the same problem that message queues attempt to solve. Such a scenario requires non-delivery timeouts and re-routing along a routing table, culminating in what the military world calls a "guaranteed action point", which is staffed by real people 24 hours a day. I built a prototype based on Exchange and SharePoint once that tries to do this. It's difficult, but not impossible. The real issue we faced was cultural, in that a commander sending a message just "felt better" when sending a courier on a motorcycle, as opposed to clicking send in Outlook.
Spearchucker 14y ago
Messages are indeed idempotent. As I mentioned, if the response is lost you resend, until you do get a response. The server will accept the same message over and over, until the client stops sending the message (i.e. the server response was received by the client). The server simply discards any subsequent messages. That message integrity is verified with a hash value goes without saying. The two generals problem is a non-problem. Messages don't equate to messenger's lives, in that there is no cost equivalent to a loss of life when resending a message. Also, the probability of not receiving a server response after n attempts is virtually null. Ref. how the internet continues to work. Atomicity is only relevant where there's a batch. Delivery of all messages in a batch is taken care of as described in the previous paragraph, and I'm therefore satisfied that transmission will work. Persistence on the client and server is therefore where atomicity applies, and is subject to the same constraints that any database transaction is subject to (again, the risk impact is high, but the probability so low that while I could, I don't even bother[1]). I don't see a problem here. [1] Hardware is quite sufficiently reliable these days. If I ever had to work in a scenario in which the cost of loss is sufficiently high (even considering the low probability of loss), then I'm still not sure what you suggest I do, because messages aren't placed onto a queue as a single operation. They're discreet. If they weren't I'd bundle them as a single message, and so wouldn't face the problem in the first place.

by moe 14y ago

ojilles 14y ago

Completely agree. One small correction: "Guaranteed delivery can become quite tricky" should roughly be: "Guaranteed delivery ARE quite tricky, if not, you have not run into all contraints yet."

Spearchucker 14y ago
Can you actually list these constraints? If not all, at least some examples? I've not encountered any I'm not handling [1]. My code has been running on various device types and under all sorts of loads for years, and have yet to encounter something not handled as described above. [1] If you're referring to guaranteed delivery in the sense of guaranteeing that your message is delivered to a person that is guaranteed to action the message, then this is not the same problem that message queues attempt to solve. Such a scenario requires non-delivery timeouts and re-routing along a routing table, culminating in what the military world calls a "guaranteed action point", which is staffed by real people 24 hours a day. I built a prototype based on Exchange and SharePoint once that tries to do this. It's difficult, but not impossible. The real issue we faced was cultural, in that a commander sending a message just "felt better" when sending a courier on a motorcycle, as opposed to clicking send in Outlook.

Spearchucker 14y ago

Messages are indeed idempotent. As I mentioned, if the response is lost you resend, until you do get a response. The server will accept the same message over and over, until the client stops sending the message (i.e. the server response was received by the client). The server simply discards any subsequent messages. That message integrity is verified with a hash value goes without saying. The two generals problem is a non-problem. Messages don't equate to messenger's lives, in that there is no cost equivalent to a loss of life when resending a message. Also, the probability of not receiving a server response after n attempts is virtually null. Ref. how the internet continues to work. Atomicity is only relevant where there's a batch. Delivery of all messages in a batch is taken care of as described in the previous paragraph, and I'm therefore satisfied that transmission will work. Persistence on the client and server is therefore where atomicity applies, and is subject to the same constraints that any database transaction is subject to (again, the risk impact is high, but the probability so low that while I could, I don't even bother[1]). I don't see a problem here. [1] Hardware is quite sufficiently reliable these days. If I ever had to work in a scenario in which the cost of loss is sufficiently high (even considering the low probability of loss), then I'm still not sure what you suggest I do, because messages aren't placed onto a queue as a single operation. They're discreet. If they weren't I'd bundle them as a single message, and so wouldn't face the problem in the first place.