Date: Thu, 24 Jul 2003 10:27:16 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Diomidis Spinellis <dds@aueb.gr> Cc: freebsd-hackers@freebsd.org Subject: Re: Network pipes Message-ID: <20030724102715.A33378@xorpc.icir.org> In-Reply-To: <3F1FBD35.82A3629E@aueb.gr>; from dds@aueb.gr on Thu, Jul 24, 2003 at 02:04:21PM %2B0300 References: <3F1F96A5.A7D2D221@aueb.gr> <20030724021426.A28546@xorpc.icir.org> <3F1FBD35.82A3629E@aueb.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
i understand the motivations (speeding up massive remote backups and the
like), but i do not believe you need to introduce a new shell
construct (with very different semantics) just to accommodate this.
I believe it is a lot more intuitive to say something like
foo [flags] source-host "tar cvzf - /usr" dest-host "dd of=/dev/bar"
and have your 'foo' command do the authentication using ssh or whatever
you require with the flags, create both ends of the socket, call
dup() as appropriate and then exec the source and destination
pipelines.
cheers
luigi
On Thu, Jul 24, 2003 at 02:04:21PM +0300, Diomidis Spinellis wrote:
> Luigi Rizzo wrote:
> > * strange benchmark results! Given the description, I would expect
> > the "|@ rsh" and "|@ ssh" cases to give the same throughput, and
> > in any case "| rsh" to be faster than "| ssh". How comes, instead,
> > that the times differ by an order of magnitude ? Can you run the
> > tests in similar conditions to appreciate the gains better ?
>
> They were executed on different machines. The ssh result was between
> freefall.freebsd.org and ref5, the rsh result was between old low-end
> Pentium machines on my home network.
>
> > * I do not understand how can you remove the pipe in the remote host
> > without modifying there both "sshd" and "sh" ?
> > I think it would be very important to understand how much
> > |@ depends on the behaviour of the remote daemon.
>
> The remote daemon is only used for authentication. Thus any remote host
> command execution method can be used without modifying the client or the
> server. What the modified shell does is start on the remote machine a
> separate command "netpipe". Netpipe takes as arguments the originating
> host, the socket port, the command to execute, and its arguments.
> Netpipe opens the socket back to the originating host, redirects its I/O
> to the socket, and execs the specified command.
>
> > * the loss of encription on the channel is certainly something that might
> > escape the attention of the user. I also wonder in how many cases you
> > really need the extra performance to justify the extra plumbing
> > mechanism.
>
> I felt the need for such functionality when moving GB data between
> different machines for creating a disk copy and backup to tape. My
> requirements may be atypical, this is why I asked for input.
>
> > * there are subtle implications of your new plumbing in the way
> > processes are started. With "A | B | C" the shell first creates the
> > pipes, then it can start the processes in any order, and they can
> > individually fail to start without any direct consequence other
> > than an I/O failure. "A |@ B |@ C" requires that you start things
> > from the end of the chain (because you cannot start a process
> > until you have a [socket] descriptor from the next stage in the
> > chain), and if a process fails to start you cannot even start the
> > next one in the sequence. Not that this is bad, just very different
> > from regular pipes.
>
> It is even worse. You can not write "A |@ B |@ C" because sockets are
> created on the originating host. For the above to work you would need a
> mechanism to create another socket between the B and C machines. Maybe
> the syntax should be changed to make such constructions
> counterintuitive.
>
>
> Diomidis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724102715.A33378>