Início / unix / Perguntas / 748458
Accepted
David Scherfgen
Asked: 2023-06-10 06:56:14 +0800 CST

Existe um programa que concatena fluxos não pesquisáveis ​​(tamanho não conhecido antecipadamente) e pode separá-los novamente?

  • 772

Estou tentando concatenar vários arquivos/fluxos de entrada em um fluxo (usando o comando imaginário stream-cat), canalizar esse fluxo para dentro sshe no host remoto, separá-lo de volta em arquivos/fluxos individuais ( stream-sep), como neste exemplo, que é para demonstração propósitos apenas:

stream-cat <( zfs send tank/vm@snapshot ) somefile.txt | ssh user@host "stream-sep >( zfs receive tank/vm@snapshot ) somefile.txt"

Explicação do exemplo: zfs sendgera um grande fluxo de dados cujo tamanho não é conhecido antecipadamente (é por isso que tarnão pode lidar com isso). Esse fluxo de dados é concatenado com o conteúdo de um arquivo regular somefile.txt. O fluxo resultante é canalizado para ssh, onde é separado novamente. O primeiro fluxo é canalizado para zfs receive, enquanto o segundo é gravado em um arquivo regular.

Tal programa deve ser simples de implementar lendo fluxos não pesquisáveis ​​em blocos e sempre escrevendo o tamanho do bloco seguido pelos dados, até que o final do fluxo seja alcançado. A sobrecarga seria mínima.

Esse programa já existe?

pipe

2 respostas

  1. Best Answer

    O que você está descrevendo é multiplexação ; algo que requer um protocolo (ou seja, uma especificação formal sobre como lidar com os dados).

    Há muitas abordagens para isso. Por exemplo, você notará que seu computador pode perfeitamente baixar vários arquivos ao mesmo tempo via HTTP – até mesmo do mesmo servidor. Esse recurso é trazido a você principalmente pelo TCP, que, como protocolo de transporte, permite que diferentes fluxos sejam enviados e "desmontados" na extremidade receptora.

    Portanto, o TCP já oferece essa funcionalidade e você pode simplesmente iniciar duas conexões SSH simultâneas e usá-la!

    zfs send | zstd -10 | ssh user@host 'zstd -d | zfs receive tank/vm@snapshot' &
# ^         ^    ^     ^             ^     ^   ^                             ^
# |         |    |     |             |     |   |                             |
# |         |    |     |             |     |   |     Tell your own shell to run
# |         |    |     |             |     |   |     this in the background and
# |         |    |     |             |     |   |     not block
# |         |    |     |             |     |   |                         
# |         |    |     |             |     |   |                            
# |         |    |     |             |     |   \---- Program to receive in the end
# |         |    |     |             |     |
# |         |    |     |             \-----+-------- use zstd to decompress
# |         |    |     |                             received data
# |         |    |     |            
# |         |    |     |
# |         |    |     \---------------------------- our first ssh invocaton
# |         |    |
# |         \----+---------------------------------- use zstd to compress at medium
# |                                                  high compression level (10)
# |
# \------------------------------------------------- the first program whose output
#                                                    we send

cat somefile.txt | ssh user@host 'cat > somefile.txt'
#                                                    Second SSH connection

    Claro, em vez do levemente deselegante cat somefile.txt | ssh … > somefile.txt, você provavelmente usaria apenas scp somefile.txt user@host:somefile.txt(que usa SSH sob o capô, mas não faz uma conexão shell, mas usa a camada SCP integrada no SSH para copiar o arquivo).

    Você pode tornar o estabelecimento de conexão para a segunda conexão mais rápido adicionando o seguinte ao seu ~/.ssh/configarquivo:

    ControlMaster auto
ControlPath /tmp/.ssh-socket-%h_%p_%r

    Isso dirá ao SSH para tentar reutilizar a única sessão SSH para enviar vários fluxos criptografados ao mesmo tempo (isso funciona com qualquer combinação de scpe sshtambém).

    • 2

  2. Implementações brutas dessas stream-cat, stream-seppoderiam ser facilmente escritas em perl:

    stream-cat() {
  perl -ne 'BEGIN{$/ = \0x7fff}
            print pack("n", $c|length()<<1), $_;
            $c = !eof' -- "$@"
}
stream-sep() {
  perl -e 'while($/ = \2, $_ = <STDIN>) {
             $n = unpack "n";
             open OUT, shift@ARGV unless $n & 1;
             if ($n>>=1) {$/ = \$n; $_ = <STDIN>; print OUT}
           }' -- "$@"
}

    ou o mesmo que #! /bin/sh -scripts em vez de shfunções.

    (tratamento de erro deixado como exercício para o leitor :-).

    stream-catenvia registros de até 32767 bytes grandes prefixados por um nshort codificado em rede (big-endian) cujo bit mais baixo indica se é o início de um novo fluxo (0) ou a continuação, e os bits restantes são o tamanho.

    E então, por exemplo:

    $ cat a
test
$ stream-cat 'seq 10|' a | stream-sep '|wc -l' '>b'
10
$ cat b
test

    Então no seu caso:

    stream-cat 'zfs send tank/vm@snapshot|' somefile.txt |
  ssh user@host 'stream-sep "|zfs receive tank/vm@snapshot" ">somefile.txt"'

    Um caso raro em que a forma insegura de open(aqui também usada por <>como usada por -n), que permite <fileabrir >filearquivos no modo somente leitura ou somente gravação ou |cmdcanalizar cmd|para/de um comando é realmente útil.

    Usando essas escalas |cmd/ cmd|melhor do que o seu <(cmd)/ >(cmd)como apenas um está aberto por vez, para que você possa enviar milhares de fluxos separados sem problemas.

    • 2

relate perguntas