Access to on-disk files in parallel with serving them over a TCP connection.
serve ~port () must be called before clients will be able to connect. Sets up a
bound tcp socket on port that will be used to serve files to clients. The unit
Deferred will be filled when the server is ready to receive clients.
The auth function will be called once for every client connection. If it returns
false the client will be disconnected immediately. Further details of auth can be
found in the documentation for Rpc.serve.
Once serve has been called it is a mistake (and will raise) if it is ever called
again.
serve_existing_static_file filename adds filename to the list of files
that can be accessed via the Client module. As indicated in the name,
this file must already exist and must not grow or change. When a client
requests the file it will be served from beginning to end.
write_message t msg write msg to t. msg is assumed to contain no
newlines except possibly at the end. A newline will be added to the end
in the file if it is not present. The message may be transmitted to
clients with or without a newline. The string passed to write_message is copied
and so may be freely modified once write_message returns.
schedule_message t msg is write, but the message is taken from the
provided bigstring. Once a bigstring has been given to this function it is a
mistake to ever modify the bigstring in the future. This is because it will take an
unknown amount of time to deliver the message to all connected clients
debug_snapshot () returns an s-expression containing details of the current
state of the Tcp_file server.
connect ~host ~port connect to the server at (host,port)
disconnect t disconnect from t. Pipes delivered by read/tail will be closed.
read ?client_pushes_back t filename provides a pipe that will be filled with
messages from filename starting from the beginning, and continuing until the
server calls unlink or close. The client can indicate that it is no longer
interested by calling Pipe.close_reader. See Rpc.Pipe_rpc.create for the
definition on ?client_pushes_back and its implications. Passing the
client_pushes_back argument will have no detrimental effect on a server that
is delivering from a file. If the client caught up, effectively tailing the file,
then the server will enqueue the data in memory until the client catches up, or gets
disconnected.
tail ?client_pushes_back t filename same as read, but delivers messages starting
at some unspecified point near the current end of the file and continuing until the
server calls unlink or close. The client can indicate that it is no longer
interested by calling Pipe.close_reader.