Diomidis Spinellis wrote:
> I think I can package the proposed sh changes as a separate command,
> following Luigi's suggestion. The syntax will not include a pipe symbol
> and layout, but the performance benefits will still be there. It will
> also be a lot more portable and also usable within a
At 2003-07-25T15:48:13Z, Diomidis Spinellis <[EMAIL PROTECTED]> writes:
> The same can also be done when connecting a local process with a remote
> process through a socket(2); there is no need for an intermediary, and
> this is what I have implemented.
Gotcha.
--
Kirk Strauser
pgp0.pgp
De
Kirk Strauser wrote:
> At 2003-07-25T06:06:01Z, Diomidis Spinellis <[EMAIL PROTECTED]> writes:
> > You still have the overhead of two nc instances copying data and context
> > switching.
> Forgive my ignorance, but is that significantly higher than two /bin/sh
> instances copying data and context s
At 2003-07-25T06:06:01Z, Diomidis Spinellis <[EMAIL PROTECTED]> writes:
> You still have the overhead of two nc instances copying data and context
> switching.
Forgive my ignorance, but is that significantly higher than two /bin/sh
instances copying data and context switching?
--
Kirk Strauser
On Thu, Jul 24, 2003 at 05:51:27PM -0400, Leo Bicknell wrote:
> In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote:
> > Another approach would be to add a new option to SSH
> > so that it could encrypt only the initial authentication,
> > then pass data unencrypted af
Kirk Strauser wrote:
> # ssh -f remotehost "nc -l -p 54321 | dd of=/dev/st0 bs=32k"
> # tar cvf - / | nc remotehost 54321
>
> Netcat implements a TCP/UDP transports and basically nothing else. Isn't
> that what you're trying to achieve?
You still have the overhead of two nc instances cop
On Thu, 2003-07-24 at 21:51, Leo Bicknell wrote:
> In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote:
> > Another approach would be to add a new option to SSH
> > so that it could encrypt only the initial authentication,
> > then pass data unencrypted after that. Th
At 2003-07-24T08:19:49Z, Diomidis Spinellis <[EMAIL PROTECTED]> writes:
> tar cvf - / |@ ssh remotehost -- dd of=/dev/st0 bs=32k | :
> The effect of the above command is that a socket is created between the
> local and the remote host with the standard output of tar and the standard
> input of dd
In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote:
> Another approach would be to add a new option to SSH
> so that it could encrypt only the initial authentication,
> then pass data unencrypted after that. This would
> go a long way to addressing the performance co
Dirk-Willem van Gulik wrote:
I think this should just be a utility like Luigi suggested. This will
help "solve" these problems.
And in large part the traditional netpipe/socket tools in combination with
the -L and -R flags of SSH solve these issues rather handily. And when
used with ssh-keyagent r
On Thu, Jul 24, 2003 at 10:36:41AM -0700, John-Mark Gurney wrote:
> Diomidis Spinellis wrote this message on Thu, Jul 24, 2003 at 14:04 +0300:
> > separate command "netpipe". Netpipe takes as arguments the originating
> > host, the socket port, the command to execute, and its arguments.
> > Netp
> I think this should just be a utility like Luigi suggested. This will
> help "solve" these problems.
And in large part the traditional netpipe/socket tools in combination with
the -L and -R flags of SSH solve these issues rather handily. And when
used with ssh-keyagent rather nicely.
Dw
Diomidis Spinellis wrote this message on Thu, Jul 24, 2003 at 14:04 +0300:
> 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
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 cv
- Diomidis Spinellis's Original Message -
> > Luigi Rizzo wrote:
> >
> > * 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 plumbi
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
>
hi,
i have the following questions:
* 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
17 matches
Mail list logo
