Opened 8 years ago

Last modified 6 years ago

#5265 new Enhancement

RPC listen on an unix socket

Reported by: d3lxa Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version:
Severity: Normal Keywords: rpc socket
Cc: axel@…, ha@…


There may be more than one person on a computer that have access to the localhost network and as such we may want to manage the access to the RPC connection by using UNIX rights on a unix (domain) socket (file).

That way we can restraint the access to the users we want (in a group) and we remove overhead due to real socket because socket files are implemented using shared buffers so copies are not done.

I propose to implement this myself as a new option in the settings as a boolean and a socket file path.

Change History (7)

comment:1 Changed 8 years ago by jordan

  • Milestone changed from Sometime to None Set
  • Version 2.76+ deleted

I can't promise to use this, but if you implement it I will review it and consider it for inclusion.

The main two criteria I would use on a feature like this would be simplicity of the code and size of the code: the smaller and simpler, the better.

comment:2 Changed 8 years ago by d3lxa

I have written a first draft of the patch needed in libtransmission and in libevent. It should work but I haven't tested yet as I don't have a client to test.

Moreover as transmission-remote uses libcurl an other patch is needed because unix socket are not supported yet. A discussion happened 4 years ago but no patch were produced. The idea of integrating unix socket wasn't rejected. I may try to write one patch and submit it upstream.

In summary there are two projects that need patch to work with unix sockets: libevent and libcurl.

The actual implementation in transmission-daemon looks at rpc-bind-address and if it begins with a slash then it assumes a unix-domain socket and starts to listen on it.

I would like some comments about all these issues if possible.

comment:3 Changed 8 years ago by jordan

I haven't seen your patch but in general I've found the libevent developers good to deal with and open to feedback.

libevent is planning on replacing its evhttp code with libevhtp. When this happens, we'll switch both our evhttp and libcurl code to libevhtp.

One issue here is that I don't know what timeframe libevent is looking at for 2.1 and adopting libevhtp. If you're going to contact them about a patch, you might ask about this as well. Transmission can't ship with an alpha libevent dependency, so the timeline for this feature might be some point after the Spring distro release.

comment:4 Changed 8 years ago by helloadam

  • Cc ha@… added

comment:5 Changed 7 years ago by vohof

Hi, any progress on this feature?

comment:6 Changed 7 years ago by d3lxa

While I created some patches for transmission with its libevent, I was not able to test because the official client uses curl which didn't support socket file 6 month ago. I don't know if the situation changed, but I can publish the patch I made although I am not proud of these, they are not clean. It may serve as a draft to implement this feature more cleanly. Are you interested?

Last edited 7 years ago by d3lxa (previous) (diff)

comment:7 Changed 6 years ago by ionice

It seems like the next version curl will support fetching from UNIX sockets:

Just posting here in case anyone was still interested in this feature.

Note: See TracTickets for help on using tickets.