Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Idea: master/client concept
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Eric Wong via curl-users <curl-users_at_cool.haxx.se>
Date: Wed, 24 Feb 2021 19:29:06 +0000
Daniel Stenberg <daniel_at_haxx.se> wrote:
> Hey,
>
> This concept has been discussed a bit at both curl up conferences so far, so
> I decided it was about time to start jotting down some thoughts on how it
> could work:
>
> https://github.com/curl/curl/wiki/curl-tool-master-client
If I find time to implement this for *nix, I would use
SCM_RIGHTS to pass std* FDs to avoid unnecessary bulk data
copies between processes. stdin -T- and stdout won't have
throughput penalties.
The directory FD of the client would also be passed if path
expansion is necessary (and the daemon could use
openat/fchdir/... off that FD). No racy and redundant pathname
lookups would be done.
As for the Unix socket path location. For XDG systems,
"$XDG_RUNTIME_DIR/curl/daemon.sock" is probably acceptable.
If XDG_RUNTIME_DIR isn't set, maybe "/tmp/curl-$UID/daemon.sock" ?
All directories would be 0700.
Interactive prompts would still have to be handled by the client
and inputs passed to the daemon; since the daemon won't have a
controlling terminal even if it gets the FDs.
This probably isn't far off from what things like screen(1) and
tmux(1) do (I haven't read their code :x).
I'm actually working on some AGPL-3+ Perl5+Inline::C project
which does this SCM_RIGHTS stuff with SOCK_SEQPACKET Unix
sockets. SOCK_SEQPACKET is convenient for passing small
messages from the server back to the client (e.g. to prompt
users or set error codes); I'm hoping it's portable enough these
days...
Maybe I can find time to work on this for curl once I'm tired of
Perl5 (said project also uses curl(1) atm).
> It's a wiki. Feel free to add your ideas/thoughts.
Fwiw, I find GitHub's Terms-of-Service and JS CAPTCHA unacceptable.
I have no social media profiles (or homepage) and will keep it that way.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-24
Date: Wed, 24 Feb 2021 19:29:06 +0000
Daniel Stenberg <daniel_at_haxx.se> wrote:
> Hey,
>
> This concept has been discussed a bit at both curl up conferences so far, so
> I decided it was about time to start jotting down some thoughts on how it
> could work:
>
> https://github.com/curl/curl/wiki/curl-tool-master-client
If I find time to implement this for *nix, I would use
SCM_RIGHTS to pass std* FDs to avoid unnecessary bulk data
copies between processes. stdin -T- and stdout won't have
throughput penalties.
The directory FD of the client would also be passed if path
expansion is necessary (and the daemon could use
openat/fchdir/... off that FD). No racy and redundant pathname
lookups would be done.
As for the Unix socket path location. For XDG systems,
"$XDG_RUNTIME_DIR/curl/daemon.sock" is probably acceptable.
If XDG_RUNTIME_DIR isn't set, maybe "/tmp/curl-$UID/daemon.sock" ?
All directories would be 0700.
Interactive prompts would still have to be handled by the client
and inputs passed to the daemon; since the daemon won't have a
controlling terminal even if it gets the FDs.
This probably isn't far off from what things like screen(1) and
tmux(1) do (I haven't read their code :x).
I'm actually working on some AGPL-3+ Perl5+Inline::C project
which does this SCM_RIGHTS stuff with SOCK_SEQPACKET Unix
sockets. SOCK_SEQPACKET is convenient for passing small
messages from the server back to the client (e.g. to prompt
users or set error codes); I'm hoping it's portable enough these
days...
Maybe I can find time to work on this for curl once I'm tired of
Perl5 (said project also uses curl(1) atm).
> It's a wiki. Feel free to add your ideas/thoughts.
Fwiw, I find GitHub's Terms-of-Service and JS CAPTCHA unacceptable.
I have no social media profiles (or homepage) and will keep it that way.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2021-02-24