irresponsible

Bricks - the sockets suite of your dreams

Bricks is a new suite of sockets libraries which will ultimately grow to encompass:

TCP/SSL/Unix sockets
Connector and acceptor pools
HTTP client and server
and more!

The name is a hint at the philosophy of the library - that it should be possible to plug things together to solve your problem. The bricks suite came about because no existing http client was flexible enough to handle a particularly badly behaved web api I needed to integrate with. It should be flexible enough for you to integrate with your own particularly badly behaved network services.

github
hexdocs

Here is the intro to bricks, the first library in the suite:

The OTP gen_tcp and ssl libraries have quite a few pain points:

A different (albeit identical) API per socket type
Different active mode message tags per socket type
Risk of mailbox overflow-induced BEAM crash in active mode
ssl ignores your intended socket state options on handshake
gen_tcp sockets default to a different activity mode for a unix socket
Confusing documentation
Lack of useful examples

This library attempts to address these problems.

Goals:

Intuitive high-level API for common tasks
Simple low-level API for advanced purposes
Fully embrace active and passive socket modes, avoiding active overflow
Do not force a process model on the user
Examples of common use cases

4 comments

#library #gen-tcp #ssl #socket

9 1447 4

2018-10-31 23:09:57 UTC

Most Liked

NobbZ

Just use the :sparse option.

Why don’t you use git submodules then? As it is now, it looks as if it were even harder to maintain, by copying back and forth from your monorepo, but then again it feels weirtd not to have the regular flat hirarchy.

Post #4

OvermindDL1

Well this looks cool.

The repo is a bit odd looking though, the elixir project is in a subdirectory instead of the git root? That will make it hard to use with mix.exs as a github dependency (is it even possible?). I’d recommend putting the project at the git root so mix.exs can github depend on it directly if someone needs to test the master or a branch version or so.

Hmm, so bounded active with an integer is like active: one repeatedly until that integer number worth of packets is buffered (until drained)? That’s pretty cool.

I’ll need to play with it in some project sometime but the API looks immediately useful.

Post #2

irresponsible

The repo is like that because on my machine it’s actually a monorepo with four projects in it (of which i’ve only released one, the rest aren’t ready yet) with the root directory containing an umbrella project (so i can build combined docs for all the modules for convenience).

Integer bounded active is not quite like :once repeatedly - :once doesn’t cause a passive notification whereas an integer does. Note carefully the warning about the internal counter in the documentation - it’s confusing!

Post #3

Last Post!

irresponsible

I don’t understand what you mean about copying back and forth, but whatever the problem, I do know git submodules are never quite the answer I was looking for.

I’m not totally wedded to the monorepo if it makes using bricks difficult, but I don’t want any replacement to be significantly more effort.

Post #5