Primeiro de tudo - eu sei fifos para IPC, mas li sobre soquetes de domínio unix , que são bidirecionais e eu queria testar isso, o que é possível com linha de comando e bash.
Perguntei ao Chat GPT, mas as informações que obtive foram inúteis e os exemplos não funcionaram.
Eu queria conseguir que dois processos pudessem escrever simultaneamente um para o outro ou ler, sem o conceito de um fifo.
Se eu definir um descritor de arquivo para leitura em um fifo. eu também posso escrever com dois processos ou mais para o fifo. mas os dados são misturados, e o primeiro leitor lê todo o conteúdo misturado.
o processo A deve receber o que o processo B escreve, e o processo B deve receber o que o processo A escreve.
Consegui fazer isso funcionar com o seguinte código de teste:
arquivo bash: processA
while true; do
for ((i=0;i<10;i++)); do
echo "$((i+1))A" > "/proc/$PID/fd/6";
sleep 1;
done
while read -t 0.01 dataB; do echo "Received from process B: $dataB"; done
done
Arquivo bash: processB
while true; do
for ((i=0;i<10;i++)); do
echo "$((i+1))B";
sleep 0.5;
done
while read -t 0.01 dataA <"/proc/$PID/fd/5"; do echo "Received from process A: $dataA" > /dev/tty; done
done
terminal 1:
exec 6> >(nc -lU unixSocket | PID=$$ bash processA)
No Processo A :
Depois disso, posso escrever no soquete Unix por meio de "/proc/$PID/fd/6",
ler do soquete Unix com stdin
e o stdout vai para o terminal.
terminal 2:
exec 5< <(PID=$$ bash processB | nc -U unixSocket)
No Processo B :
Depois disso, posso escrever no soquete Unix com stdout,
ler do soquete Unix com "/proc/$PID/fd/5",
escrever no terminal com /dev/ttx
e stdin no teclado.
Primeira pergunta: Por que os descritores de arquivo 5 e 6 não são herdados dos subprocessos abertos na substituição de processo?
Tenho que obtê-los exportando o PID - por quê?
Segunda pergunta: os processos A e B podem se comunicar bidirecionalmente, mas preciso abrir mais dois processos principais, que estão executando o comando exec para redirecionamento do descritor de arquivo e iniciando a substituição do processo exec 5< <(PID=$$ bash processB | nc -U unixSocket)
.
Mas o que eu finalmente quero é uma comunicação entre o processo principal e o processo filho, e nada mais.
Agora eu tenho: o principal 1 abre o filho 1, o principal 2 abre o filho 2, e o filho 1 pode se comunicar bidirecionalmente com o filho 2.
Obrigado pela sua ajuda antecipadamente
Em resposta à sua pergunta 1: como você sabe que os descritores de arquivo não estão sendo herdados? Em vez disso,
read dataA < /proc/$PID/fd/5
você deveria ser capaz deread dataA <&5
. Não é esse o caso?Quanto à pergunta 2, acho que você está perguntando como estender isso para vários clientes? Para que isso funcione, você precisa de um comportamento fork/exec para lidar com cada nova conexão de cliente se o UDS estiver no modo de serviço de streaming, ou para colocar o UDS no modo de serviço de datagrama.
Nunca usei netcat para UDSes, e em uma busca de 10 segundos, não consegui encontrar nenhuma documentação que me dissesse como usá-lo. Sempre que lidei com UDSes em um script de shell, usei uma ferramenta cli chamada socat .
Supondo que você queira o serviço de datagrama, no terminal um, inicie o servidor:
No terminal dois, inicie um cliente
Repita esse comando do cliente quantas vezes quiser. Se quiser serviço de stream, inicie o servidor assim:
(Sem a
fork
opção, este comando aceitará apenas uma conexão e sairá quando a conexão for fechada).E comece a transmitir clientes assim:
A página do manual do socat documenta completamente todas as suas Especificações de Endereço que ele suporta. Ele faz tudo o que o netcat faz, e mais um pouco, com uma sintaxe mais escalável.