I am experimenting with a web service architecture with multiple frontend linode and separate backend linodes. The frontend accept requests, post them as "jobs" to an internal job/work queue server (say beanstalk, gearman, whatever). The backend workers pull jobs, and then may need to notify multiple frontends, not just one particular frontend.

There are a lot of ways of doing this one-to-many notification from backend to multiple frontends. AMQP with RabbitMQ for instance. But I'd like to avoid the overhead of an internal pubsub/message-broker if I can and just use the network itself... VLANs, multicast UDP, PGM, broadcast, etc. I've read enough of the material to understand these subjects at a respectable level, but I'm not an expert on them.

For Linode, is the private network a VLAN? Or, if I broadcast from one of my backend linodes, will ONLY my other linodes see the traffic? Or will other linodes see the traffic as well (and get pissed off at me)?

My messages need to be reliable so UDP is out. PGM looks interesting. Is it supported at Linode?

Do you have any suggestions? Thanks!

The private network is a LAN. Broadcasts work, and any Linode in the datacentre can talk to any other Linode in the datacentre.

Security is enforced by the fact that Linodes can't spoof an IP (their host won't allow it), and that they can't enter promiscuous mode; they can only receive broadcasts and packets addressed to them.

You can get an effective simulation of a VLAN by just firewalling to only the IP of your other linodes.

It seems to me like Linode should support PGM (I'd imagine that the hosts care only about IP and not higher levels), but I'm not sure. Regardless, PGM is listed as experimental, so is it really the right thing for you?

We're talking about a LAN here; packetloss should be minimal, and a simple ACK-based system should accomplish what you need if you're coding it yourself. Simply send out a UDP broadcast and have the other endpoints send back a hash of the received packet as an acknowledgement; if you don't hear back from a machine within a set period (and being a LAN, you could set that pretty low), it didn't receive the packet. Bonus points for using sequence numbers to ensure order.

Thanks for the info. I suppose I could/should avoid broadcast then and use a simple reliability layer atop multicast UDP. I do not want my broadcasts hitting my neighbors' Linodes.

It's been a while since I worked with it, but not sure going multicast would be the best approach either. Since it's essentially one big LAN, there's little control over assignment of group addresses, so what's to stop someone from joining your group without your knowledge and then receiving your packets.

Also, unless there's some network infrastructure (IGMP aware switches?), multicast ethernet frames would essentially have to be broadcasted too I think.

Personally I'd opt for a more declarative approach where you managed the set of devices in the system more explicitly rather than depending on broadcast or multicast. Yes, it's a little more work, but I think it's the best approach in a shared environment like Linode.

-- David

Yeah, I have been reading more about multicast and that was something that caught my attention - there's nothing from stopping someone else from joining your group.

Anyway, I've decided to just run a message broker (RabbitMQ probably).

Thanks everyone!