We did something similar for very high speed stuff for NATS.io.
We recently had someone give a talk about Unity and NATS.io which may be interesting.
Looks like the default mode of NATS being at-most-once has bitten again, with the options for at-least-once being missed. When smart developers miss this, it’s a project problem in communication.
[disclaimer: I work for the main company behind NATS]
I wasn’t aware there were other modes. Is there a way to configure NATS so that it will act like kafka?
For what you are doing you don’t need that, and you don’t need at-least-once semantics really either. Treat NATS like HTTP and make every message a request, meaning you will wait for the other side to confirm. I also used NATS to create the control plane for CloudFoundry and never used anything but at-most-once semantics for scheduling, command and control, addressing and discovery and telemetry.
Does this potentially run into issues with missed responses? If a response message doesn’t show up you’re not sure if it failed to arrive or your message was never received? Feels like this might be easier to avoid with HTTP.
What happens when you don’t get a response from HTTP? That is also possible if the network stack hangs or breaks. Its the same thing TBH.
Right. I guess I don’t know enough about TCP/HTTP failure or message queue send failure. Seems like NATS might drop messages under load which would have different failure characteristics than TCP (maybe not true?). Would retrying on timeout also have very similar characteristics to at-least-once?
NATS will protect itself at all costs and will cut off subscribers who can not keep up. However, that really does not apply to request/reply semantics. So for request/reply I would say NATS and HTTP would behave similarly.
cool, thanks for the knowledge
The other half of it was that the Rust client for nats wasn’t as mature as I was hoping.
You should look again, its a 1st class citizen now, but at the time you are probably right.