4 ms·

I was wondering the complement. In what way is AMPQ more reliable than SMTP?

by cwp 15y ago

njharman 15y ago
I don't understand any of those placements, author must have way different definitions than I.
rwmj 15y ago
I'll try to answer the grandparent.. But note that I don't really know this topic in great depth so hopefully people who know will jump in and point out my mistakes. Firstly HTTP is unreliable because there is no guarantee that the website is up at any particular point in time. In other words you couldn't write a reliable program that depended on fetching data from a website because the website might be down when you requested it. You could try to wait and fetch the data later, but that would be effectively building another protocol on top of HTTP to make it more reliable. I have no idea about IIOP/CORBA but perhaps it added more reliability? AMQP isn't completely reliable. I mean, if you send a message to an AMQP broker and it's committed, that just means it's saved to some presumably reliable resource, eg. to a harddisk. If a plane falls out of the sky and wipes out the broker, then it's not reliable. [You can, if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents] I don't think in this respect that AMQP is more reliable than SMTP. But it's a lot more convenient than SMTP for what it's designed for: ie. messaging for programs. Getting email out of and back into programs is a whole lot more complex than just setting up an AMQP binding.
- timf 15y ago
  "if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents" For example, as of RabbitMQ 2.6, there is active-active broker clustering: http://www.rabbitmq.com/ha.html http://www.rabbitmq.com/ha.html
- cwp 15y ago
  It's important to distinguish between reliability in the protocol and reliability in the implementation. Spending time and money to be reliable in the face of disasters like falling planes is about the implementation. An example of reliability at the protocol level is TCP vs. raw IP. IP routers will try to get your packets to their destinations, but they'll also happily discard them if that's more convenient. TCP adds some reliability - the other side will let you know if they didn't get everything. The issue you bring up with HTTP is actually related to HTTP being synchronous rather than unreliable. If you wrote your program to fetch data by sending an email, it would probably work even if the SMTP server that had the data was down: your local SMTP server would store your message and forward it when the destination server came back up.

I was wondering the complement. In what way is AMPQ more reliable than SMTP?

by cwp 15y ago

I was wondering the complement. In what way is AMPQ more reliable than SMTP?

njharman 15y ago

I don't understand any of those placements, author must have way different definitions than I.

rwmj 15y ago

I'll try to answer the grandparent.. But note that I don't really know this topic in great depth so hopefully people who know will jump in and point out my mistakes. Firstly HTTP is unreliable because there is no guarantee that the website is up at any particular point in time. In other words you couldn't write a reliable program that depended on fetching data from a website because the website might be down when you requested it. You could try to wait and fetch the data later, but that would be effectively building another protocol on top of HTTP to make it more reliable. I have no idea about IIOP/CORBA but perhaps it added more reliability? AMQP isn't completely reliable. I mean, if you send a message to an AMQP broker and it's committed, that just means it's saved to some presumably reliable resource, eg. to a harddisk. If a plane falls out of the sky and wipes out the broker, then it's not reliable. [You can, if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents] I don't think in this respect that AMQP is more reliable than SMTP. But it's a lot more convenient than SMTP for what it's designed for: ie. messaging for programs. Getting email out of and back into programs is a whole lot more complex than just setting up an AMQP binding.

timf 15y ago
"if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents" For example, as of RabbitMQ 2.6, there is active-active broker clustering: http://www.rabbitmq.com/ha.html http://www.rabbitmq.com/ha.html
cwp 15y ago
It's important to distinguish between reliability in the protocol and reliability in the implementation. Spending time and money to be reliable in the face of disasters like falling planes is about the implementation. An example of reliability at the protocol level is TCP vs. raw IP. IP routers will try to get your packets to their destinations, but they'll also happily discard them if that's more convenient. TCP adds some reliability - the other side will let you know if they didn't get everything. The issue you bring up with HTTP is actually related to HTTP being synchronous rather than unreliable. If you wrote your program to fetch data by sending an email, it would probably work even if the SMTP server that had the data was down: your local SMTP server would store your message and forward it when the destination server came back up.