Essa é uma linha de teste muito curta. Tente algo maior que o tamanho do buffer usado por netcat
ou socat
e enviando essa sequência várias vezes a partir de várias instâncias de teste; aqui está um programa sender
que faz isso:
#!/usr/bin/env expect
package require Tcl 8.5
set socket [lindex $argv 0]
set character [string index [lindex $argv 1] 0]
set length [lindex $argv 2]
set repeat [lindex $argv 3]
set fh [open "| socat - UNIX-CONNECT:$socket" w]
# avoid TCL buffering screwing with our results
chan configure $fh -buffering none
set teststr [string repeat $character $length]
while {$repeat > 0} {
puts -nonewline $fh $teststr
incr repeat -1
}
E, em seguida, um launcher
para chamar isso várias vezes (25) usando diferentes caracteres de teste de grande comprimento (9999) várias vezes (100) para, com sorte, passar por qualquer limite de buffer:
#!/bin/sh
# NOTE this is a very bad idea on a shared system
SOCKET=/tmp/blabla
for char in a b c d e f g h i j k l m n o p q r s t u v w x y; do
./sender -- "$SOCKET" "$char" 9999 100 &
done
wait
Hmm, eu não tenho um netcat
esperançosamente nc
no Centos 7 será suficiente:
$ nc -klU /tmp/blabla > /tmp/out
E, em seguida, em outro lugar, nós fornecemos dados para isso
$ ./launcher
Agora, nosso /tmp/out
será estranho, pois não há novas linhas (algumas coisas são baseadas em novas linhas para que novas linhas possam influenciar os resultados dos testes, veja setbuf(3)
para o potencial de buffer) precisa de código que procure por uma mudança de um caractere e conte quanto tempo a sequência anterior de caracteres idênticos era.
#include <stdio.h>
int main(int argc, char *argv[])
{
int current, previous;
unsigned long count = 1;
previous = getchar();
if (previous == EOF) return 1;
while ((current = getchar()) != EOF) {
if (current != previous) {
printf("%lu %c\n", count, previous);
count = 0;
previous = current;
}
count++;
}
printf("%lu %c\n", count, previous);
return 0;
}
Oh, garoto C! Vamos compilar e analisar nossa saída ...
$ make parse
cc parse.c -o parse
$ ./parse < /tmp/out | head
49152 b
475136 a
57344 b
106496 a
49152 b
49152 a
38189 r
57344 b
57344 a
49152 b
$
Uh-oh. Isso não parece certo. 9999 * 100
deve ser 999.900 de uma única letra em uma linha e, em vez disso, temos ... não isso. a
e b
foram iniciados cedo, mas parece que r
conseguiu algumas capturas iniciais. Isso é agendamento de tarefas para você. Em outras palavras, a saída está corrompida. Que tal perto do final do arquivo?
$ ./parse < /tmp/out | tail
8192 l
8192 v
476 d
476 g
8192 l
8192 v
8192 l
8192 v
476 l
16860 v
$ echo $((9999 * 100 / 8192))
122
$ echo $((9999 * 100 - 8192 * 122))
476
$
Parece que o 8192 é o tamanho do buffer neste sistema. Em todo o caso! Sua entrada de teste foi muito curta para passar os comprimentos de buffer e dá a falsa impressão de que várias gravações de clientes estão corretas. Aumente a quantidade de dados dos clientes e você verá resultados mistos e, portanto, corruptos.