Date: Tue, 2 Jul 2013 07:00:13 -0400 From: Ambarisha B <b.ambarisha@gmail.com> To: David Chisnall <theraven@freebsd.org> Cc: soc-status@freebsd.org Subject: Re: IDMS : Weekly status report #2 of 14 Message-ID: <CAJP25sOHL-Ntf4Yt885L7mCeHj9mi2m8%2BgMqUCOj_JeMqZdTwg@mail.gmail.com> In-Reply-To: <C2E395F2-3026-48E1-8A62-E9BC36F0DFBD@FreeBSD.org> References: <CAJP25sPv9FvWjm0125ix0iDm18nZfAFO_O-0MWz6PZ=UdwypKw@mail.gmail.com> <C2E395F2-3026-48E1-8A62-E9BC36F0DFBD@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 2, 2013 at 5:23 AM, David Chisnall <theraven@freebsd.org> wrote:
> On 1 Jul 2013, at 19:27, Ambarisha B <b.ambarisha@gmail.com> wrote:
>
> > 3. Refactor the client to give an open fd to the server (instead of
> > expecting one, as is the model with libfetch)
>
> Can you explain a bit what this means? The daemon should be the thing
> openning the connection. The forked worker should then pass it to
> libfetch.
>
fd isn't the connection, it is the local file. libfetch doesn't take an
open local file descriptor. It returns the remote file stream wrapped as an
fd. The client (fectch program) expects this fd for cryptographic hash
verification etc and when it is done writes the data in that fd into a
local file. This doesn't work for us because that has to be done in the
daemon. I was talking about refactoring that into the daemon and the client
passes the fd of the local file to the daemon.
> struct client_request req;
>
> int IPC_connection_to_clients = /* whatever you're using here, most likely
> a UNIX domain socket so that you can pass in the fd for the output file
> from the client. */;
>
> while (wait_for_request(IPC_connection_to_clients, &req) {
> /* URL parsing code goes here. */
> int fd server = connect(...);
> /* Error handling goes here */
>
> /* You may want to create a pipe here for sending progress
> messages from the client back to the server */
>
> /* You may want to queue requests and not start downloading
> immediately if some bandwidth or number of concurrent downloads quota is
> reached */
>
> /* Create the worker */
> pid_t child = fork();
> /* Error handling here */
>
> if (child == 0)
> {
> /* Now we're in the worker, close any file descriptors
> that we shouldn't have */
> close(IPC_connection_to_clients);
> close(stdin);
> close(stdout);
> /* Then enter sandboxed mode */
> cap_enter();
> /* Now do the real downloading and exit */
> do_the_real_downloading(server, req.output_file, req.url);
> exit(0);
> }
> else
> {
> /* Close the file descriptors that the worker is using. */
> close(server);
> close(req.output_file);
> /* Probably add child to a list of things that you'll wait
> for exit signals from in the kqueue call in the wait_for_request part */
> }
> }
>
>
Yes this is what I'm thinking as well. For this, libfetch has to be
modified to accept a connection. Right now, it takes a url and returns the
stream containing the remote file wrapped as an fd. Opening the connection
is abstracted in libfetch.
Cheers
Ambarish
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP25sOHL-Ntf4Yt885L7mCeHj9mi2m8%2BgMqUCOj_JeMqZdTwg>