It would be great if glisten can support unix sockets and abstract unix sockets.
Erlang supports this by passing the option {ip, {local, Path}} to gen_tcp:listen where Path is either a file system path, or an abstract unix sockets where the Path starts with null byte (<<0,path:utf8>>).
I have implemented a prototype in glisten where this is implemented. The prototype makes a couple of different modifications to achieve this:
- Extending
IpAddress to also represent a UnixSocketAddress
- modifying
bind to see if the incoming interface starts with "/" or "@" (which is the convention to deal with unix sockets, however we can change this to use something other than bind, like: fn bind_unix_socket(handler, path: String) -> Handler instead
- Modifying the type of
sockname from #(Dynamic, Int) to Dynamic as the underlying erlang code might return {Hostname :: binary(), Port :: int()} | {local, Path :: binary()}. Then this dynamic is decoded into either #(ipv4|ipv6, port) or #(path, 0).
From my point of view the biggest problem with the prototype is that it piggy-backs on some naming conventions like IpAddress and the return type from sockname which might not be ideal.
Would it be OK if I do the PR with what I currently have and we can take discussion from there?
It would be great if glisten can support unix sockets and abstract unix sockets.
Erlang supports this by passing the option
{ip, {local, Path}}togen_tcp:listenwherePathis either a file system path, or an abstract unix sockets where the Path starts with null byte (<<0,path:utf8>>).I have implemented a prototype in glisten where this is implemented. The prototype makes a couple of different modifications to achieve this:
IpAddressto also represent aUnixSocketAddressbindto see if the incoming interface starts with "/" or "@" (which is the convention to deal with unix sockets, however we can change this to use something other thanbind, like:fn bind_unix_socket(handler, path: String) -> Handlerinsteadsocknamefrom#(Dynamic, Int)toDynamicas the underlying erlang code might return{Hostname :: binary(), Port :: int()} | {local, Path :: binary()}. Then this dynamic is decoded into either#(ipv4|ipv6, port)or#(path, 0).From my point of view the biggest problem with the prototype is that it piggy-backs on some naming conventions like
IpAddressand the return type fromsocknamewhich might not be ideal.Would it be OK if I do the PR with what I currently have and we can take discussion from there?