Show HN: Condor – A library for building scalable TCP servers in Erlang(github.com)
github.com
Show HN: Condor – A library for building scalable TCP servers in Erlang
https://github.com/sinasamavati/condor
10 comments
There’s no Netty type thing for Erlang? Netty is so nice to have on the JVM, I don’t know much about TCP and it lets me be dangerous, asynchronously.
The Erlang VM (BEAM) is non-blocking by design, you don't need anything like Netty on BEAM.
There's a standard, built-in way to handle events on a TCP socket? Like Netty or Node's `net` package.
I'm not familiar with Netty, but in Erlang you set `active` mode which means Erlang will send your process messages for all incoming events for a socket: http://erlang.org/doc/man/inet.html#setopts-2
You can further use `{active, N}` to limit the "events" to a certain number as to apply back pressure to the OS socket level and beyond.
You can further use `{active, N}` to limit the "events" to a certain number as to apply back pressure to the OS socket level and beyond.
How Condor differentiate itself from Ranch?
Ranch is merely a socket acceptor pool. Condor takes care of framing and buffering, also.
Doesn't native erlang handle that? With {packet, Len} and {active, once}?
Not the buffering.
You can set a user level buffer size of the socket driver, and a receive buffer size (see http://erlang.org/doc/man/inet.html).
Why is another level of buffering needed?
Why is another level of buffering needed?
Also, it's frankly hard to judge your claim of scalability, when you haven't provided any data. How many millions of connections can this handle (on which particular hardware), how many thousands of connections per second, how many gigabits of data transfer can you push, how many connections can you gracefully close per second, etc. What erlang settings did you have to tweak, what operating system limits did you have to tweak, etc to get there.