
A Virtual LAN using NATS, written in Go - rapidloop
https://github.com/rapidloop/vlan-nats?
======
crest
In effect this is still Ethernet over TCP, but other than that it's a cool
idea. Now if only NATS would support SCTP...

~~~
crocal
Agree. I would really like to hear what is the upside / sales pitch of NATS
compared to an Erlang server (that, BTW, supports SCTP out of the box).

~~~
ihsw2
NATS can saturate a network port with hundreds of thousands of messages/second
with minimal impact on CPU, it scales linearly with cores, and it has
minimal/zero effort fail-over. Whether across large geographic boundaries (ie:
AWS cross-region) or in the same rack, NATS clustering is reliable and
definitely speedy.

~~~
bjflanne
Well said; the other project involving NATS from the Rapidloop team (gRPC over
NATS essentially) mentions some benefits as they see it which are what you've
pointed out:
[https://github.com/rapidloop/nrpc](https://github.com/rapidloop/nrpc)

------
api
Ethernet or raw IP over TCP are slow (without some really creative hacks
involving multiple TCP links) due to the double ACK problem. Adding UDP would
probably not be hard.

------
jbverschoor
Also check out zerotier. It works really well, and routes traffic through the
local lan if available. It also supports other protocols than ip.

------
feelin_googley
"... only works on Linux."

"Multicast is not supported."

I seem to recall other L2 overlay projects, UDP-based, that are both portable
to other OS (subject to TAP requirement) and have no problem with multicast.

Curious: What causes these limitations with NATS?

~~~
lobster_johnson
NATS is just a message broker, and runs wherever Go runs. The limitations are
in this project. It's a 105-line proof of concept, clearly the author didn't
bother making it portable.

