Search code examples
stomp

Why STOMP protocol has ACK and NACK, if delivery of frames already guaranteed by TCP?


STOMP seems to be a protocol for socket based communication, and AFAIK socket always means TCP.

Why does STOMP needs ACK/NACK commands for acknowledging messages, if it's already guaranteed that the messages will be delivered on protocol level?

https://stomp.github.io/stomp-specification-1.2.html#ACK


Solution

  • As I understand it, the STOMP ACK/NACK functionality doesn't really have anything to do with the transport protocol (i.e. tcp). It's really about the messaging client and how it interacts with the message from the broker. For example, a client could receive a message, process it, and if the processing result was "successful" then it would ACK the message. If the processing result was a "failure" then it would NACK the message. As the spec states, when a message is NACKed:

    The server can then either send the message to a different client, discard it, or put it in a dead letter queue.

    This allows messaging applications to deal with potentially bad messages as well as malfunctioning clients.

    There are other use-cases, but this is probably the most common and straight-forward.