1
0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Stephen Asbury 127ea2ad63 Added acks and seq num to concepts
Cleaned up concepts a bit
Added pattern names to some of the concepts
2019-05-16 13:59:14 -07:00

1.3 KiB

Acknowledgements

In a system with at-most-once semantics, there are times when messages are lost. If your application is doing request-reply then it can simply use timeouts to handle network and application failures. When you are using one-way messaging the easiest way to insure message delivery is to turn it into a request-reply with the concept of an acknowledgement message, or ACKS. In NATS an ACK can simply be an empty message, a message with no body.

digraph nats_request_reply { rankdir=LR

subgraph { publisher [shape=box, style="rounded", label="Publisher"]; }

subgraph { subject [shape=circle, label="Subject"]; reply [shape=circle, label="Reply"]; {rank = same subject reply} }

subgraph { sub1[shape=box, style="rounded", label="Subscriber"]; }

publisher -> subject [label="msg1"]; publisher -> reply [style="invis", weight=2]; subject -> sub1 [label="msg1"]; sub1 -> reply [label="ack"]; reply -> publisher; }

Because the ACK can be empty it can take up very little network bandwidth, but the idea of the ACK turns a simple fire-and-forget into a fire-and-know world where the sender can be sure that the message was received by the other side, or with scatter-gather, several other sides.