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
.