How to multicast using NATS?

[GC]

I need to publish message to all nodes in my local subnet. 

I think multicast is a better way to do it. Is it possible to do multicast using NATS?

I experimented pub/sub, but did not figure out how to do it in multicast. 

[Larry McQueary]

Hi there. NATS doesn't support multicast, nor do many network administrators :) 

You say that you think multicast is a better way. How are you defining "better"? Simpler to implement? Simpler to use? Faster? Less error-prone?

Do you have performance constraints that you need to meet?

--
You received this message because you are subscribed to the Google Groups "nats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to natsio+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Larry McQueary | Director, Messaging Technology

la...@apcera.com | @mcqueary | github.com/mcqueary

[GC]

Yes simpler to implement, simpler to use and faster.

Let's say I have hundreds clients in a subnet, and they all need to receive the message as quickly as possible... and they are all potential publishers.

[Larry McQueary]

How large are the messages? How frequently are messages published?

[GC]

Not big, not frequent.

Most of the messages are less than 1k. Less than 10 messages per second on whole system.

[Larry McQueary]

Also, when you say "simpler to implement" and "simpler to use", could you elaborate a little bit on how it's simpler for you? If you're using something like NATS for message delivery, then you should assume that simplicity of implementation (for you) and simplicity of use (for you) would be nearly equal, regardless of whether unicast or multicast is used. A publisher sends a message on subject "foo.bar" to gnatsd, and gnatsd delivers that message to all subscribers interested in "foo.bar".  The underlying transport that the messaging layer uses should not really affect the simplicity of implementation.

[GC]

Yes I admire the simplicity of NATS. Just I have a bunch of workstations and they need to talk to each other. The simpler way for me would be to let everybody publish and listen to a multicasting address. 

I could run a gnatsd on each node and my application pub/sub to it; but is there a way to 'move' the message from one node to the other, so my application on other nodes also 'see' the message?

[Larry McQueary]

What you're describing is a gnatsd cluster with routes (described here). gnatsd instances in a cluster will propagate messages to other cluster members to ensure that all clients of all cluster members who are subscribed to a subject will receive messages published to that subject, regardless of which cluster member they are connected to.

Rather than running one gnatsd per workstation, though, I would recommend running a cluster of one or two gnatsd instances centrally on your subnet and connecting all the workstations to that cluster. 

Are you by any chance using TIBCO Rendezvous today? Just curious, since the way you're describing your desired architecture sounds very familiar :) 

On Mon, Mar 21, 2016 at 12:26 PM, GC <mr.ga...@gmail.com> wrote:

Yes I admire the simplicity of NATS. Just I have a bunch of workstations and they need to talk to each other. The simpler way for me would be to let everybody publish and listen to a multicasting address. 

I could run a gnatsd on each node and my application pub/sub to it; but is there a way to 'move' the message from one node to the other, so my application on other nodes also 'see' the message?

--

You received this message because you are subscribed to the Google Groups "nats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to natsio+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ivan Kozlovic]

How many receivers? That may change my statement, but with two two variables (less then 1k and less than 10 msgs/sec), there does not seem to be a need for multicast. NATS will do just fine ;-)

[GC]

Yes I am still using TIBCO Rendezvous and looking for a technology to replace it :)

[Larry McQueary]

Take it from someone who was at TIBCO for a very long time (actually 2 someones, myself and Ivan): assming you don't have strict sub-millisecond latency requirements, you do not need multicast to solve that problem. Even TIBCO would tell you that, these days.If you're willing to move away from the rvd architectural model, NATS can quite capably handle the volume/performance you're describing here.