djdv
commented
2 years ago Status update:
The current draft worked well enough for me to implement the mount command on top of it, but has also changed considerably in the process.
Those changes need to be pulled back into this branch and refined into something more suitable for review/release.
The mount branch could then be split up into its components and moved into PRs as well.
I'll try to detail the changes better later but some things are:
- I reimplemented the auto-launch logic. (Client commands will auto launch the server process if it's not already running and they have no been provided a
-server=/some/server/maddrflag. Meaning from the user perspective they just invoke the command they want, without needing to think about the background process at all. It will shutdown when/if idle.)- The old code was centered around
go-ipfs-cmds, a custom stdio protocol, and HTTP; now it's mainly the standard library with 9P for both stdio and all other types of connections. (We only use stdio when launching the server to pass back listening addresses to the client, before detaching the process into the background, but everything uses the same protocol/code now.) - I don't know if that will be part of this patchset or another. Probably this one? If not the first client command (like
mount) will bring it with it.
- The old code was centered around
- I ditched the
closerfilelogic and came up with a different approach of handling listeners. It's still managed and exposed via a 9P file system, but all those implementations were refined into what I hope is a more sensible hierarchy within the code / type system.- This is slightly more complicated overall, but more general. It allowed me to collapse 3 concepts around listeners into 1 that would previously have been 3 disparate constructs.
- While kind of pointless to stress this for the daemon, the nicest thing about this effort is that all the 9P code here is also going to be reused in the rest of the code. So we only have to get it correct once and we can use it as-is or extend it easily for a variety of other interfaces. The mount table itself is also a directory, like
/listeners, and uses the same code. Something likelistis thus implemented almost implicitly through a simplereaddir, not a more bespoke implementation as was the case before.
ec1oud
Follow up to https://github.com/djdv/go-filesystem-utils/pull/3
We're implementing things via a "client and server" model, but it's actually more just like "remote and persist". Between calls to things like
fs mount,fs list, etc. we need somewhere to store and share persistent/session data, and this seems like a sensible and portable way to handle it compared to other strategies like shared memory, or whatever else.It also easily allows us to do privilege separation. The daemon can run in the background with higher privileges, while less authoritative clients can just make requests to it.
There's potential to do other fancy remote things with this since we expect to communicate over local sockets, but that's not really the focus for now.
Implementation: We're ditching the previous HTTP RPC library that was inherited from the old repo and starting fresh with a 9P based server that is arguably simpler to use and reason about. Abstractions are intended to be file systems, with basic I/O operations not too dissimilar to how people use REST. Listening sockets are files in a directory, the mount table should be some similar abstraction, etc.
We basically just need some abstract tree where we can hold data across calls, and access/manipulate it via some remote client. Ideally, the abstractions for these should be layered well. With file abstractions being implemented independently. ("socket files are socket files") Construction being done via composition. ("the server makes a bunch of socket files on startup and stores them in some directory") APIs having default expectations, but not lacking in configuration. ("
clientApi.Shutdown(sockName, opts...)will walk to the socket file, and do the closer dance with it") With higher APIs just gluing it together ("from the CLI it'sfs.exe shutdown sockName")Something like that.
Status: The concept seems to be viable enough to publish this draft, but the implementations still need to be completed. As-is we can listen on a socket, mount the server's root on Linux via
mount -t 9p 192.168.1.40 /mnt/9 -o "trans=tcp,port=564"and close those listeners via standard file system writesprintf desino>/mnt/9/listeners/192.168.1.40\:564; umount /mnt/9Doing this from a cli program is basically the same procedure, abstracted in Go.client := connect(...); open("the file"); write("shutdown key"); close("the file"); client.CloseThis pattern should follow for all of our commands server and client side. The prototype we developed (*not useful, correct, or pretty) exists here: https://github.com/djdv/go-filesystem-utils/tree/j/D9 which shows a simple "MOTD" server. It can act as another example of how we'll likely implement
mount,unmount, andlist. (Except less crude, and more spec correct)TODO: Lots. The commits need to be split up logically, some things need to be backported to the commands branch. Tests / spec correctness is important. This message needs to be more coherent.