Bricks - the sockets suite of your dreams

Your Libraries & OS Mentoring Libraries
, ,
1

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
9 Likes
2

Well this looks cool. :slight_smile:

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. :slight_smile:

1 Like
3

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!

1 Like
4

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.

2 Likes
5

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.