-
Notifications
You must be signed in to change notification settings - Fork 30
IPFS API via Unix sockets #129
Description
Unix socket have many benefits over TCP sockets. Lower CPU time and latency overhead, file system localized locations which allows for system based permissions and access control.
Also Unix sockets would be a able to use different encoding scheme from TCP (HTTP) which would be suitable for different type of applications (not browsers). This encoding should focus on being fast to encode and decode, simple to implement and also "size doesn't matter" as it is local communication.
Things that need specifying:
- location of socket:
- for user daemon
- for system daemon: `/var/run/ipfs/api.socket
- base encoding - bencode
- protocol
- multipart encoding - needed for streaming files in and of the API
My proposal for encoding is bencode. It is very simple to implement (under 300 C LOC) quite fast encoding. At first glance it isn't human readable but as it isn't binary encoding someone knowing the rules is able to read. It isn't space efficient but this isn't that much of a problem here.
With usage of Unix sockets in STREAM mode it should be quite easy to write protocol that is both simple and efficient. I would go with something similar to cjdns's admin API RPC model. Calls and responses are maps.
- each call or response is a bencode map
- each call includes
txidfield that is a unique integer (usually just increasing 64bit integer) , this integer is include in response - it is used for asynchronous call <-> response tracking. - each call includes
queryfield that specifies what query this call uses - calls can include
argstable of strings which are consecutive arguments - calls can include
optsmap of string->string which are arguments for the commands - if call fails response includes
errormap with two fields:typeandmsg. - the result of a call is the response packet itself
Why:
We need higher performance API for example to be able to extract ipfs FUSE mount into separate process. It solves many problems but the HTTP api would be major overhead.
If anyone has some ideas, comments, please voice them. If you like the idea in current state please show it by voting 👍.
I would love to hear opinions also from JS part of a project.