Respostas:
Nos sistemas Windows e POSIX, os pipes nomeados fornecem uma maneira de a comunicação entre processos ocorrer entre os processos em execução na mesma máquina. O que os pipes nomeados oferecem a você é uma maneira de enviar seus dados sem a penalidade de desempenho de envolver a pilha de rede.
Assim como você tem um servidor ouvindo um endereço IP / porta para solicitações recebidas, um servidor também pode configurar um canal nomeado que pode atender solicitações. Nos dois casos, o processo do cliente (ou a biblioteca de acesso ao banco de dados) deve saber o endereço específico (ou o nome do canal) para enviar a solicitação. Geralmente, existe um padrão padrão comumente usado (assim como a porta 80 para HTTP, o SQL Server usa a porta 1433 no TCP / IP; \\. \ Pipe \ sql \ query para um pipe nomeado).
Ao configurar pipes nomeados adicionais, você pode ter vários servidores de banco de dados em execução, cada um com seus próprios ouvintes de solicitação.
A vantagem dos pipes nomeados é que geralmente é muito mais rápido e libera recursos da pilha de rede.
- BTW, no mundo Windows, você também pode ter pipes nomeados para máquinas remotas - mas, nesse caso, o pipe nomeado é transportado por TCP / IP, para que você perca o desempenho. Use pipes nomeados para comunicação da máquina local.
O Unix e o Windows têm itens chamados "pipes nomeados", mas se comportam de maneira diferente. No Unix, um pipe nomeado é uma via de mão única que normalmente possui apenas um leitor e um escritor - o escritor escreve e o leitor lê, entendeu?
No Windows, a coisa chamada "pipe nomeado" é um objeto IPC mais parecido com um soquete TCP - as coisas podem fluir nos dois sentidos e há alguns metadados (você pode obter as credenciais da coisa na outra extremidade, etc.).
Os pipes nomeados do Unix aparecem como um arquivo especial no sistema de arquivos e podem ser acessados com comandos normais de E / S de arquivo, incluindo o shell. Os Windows não, e precisam ser abertos com uma chamada de sistema especial (após o que se comportam principalmente como um identificador win32 normal).
Ainda mais confuso, o Unix tem algo chamado "soquete Unix" ou soquete AF_UNIX, que funciona mais como (mas não completamente como) um "pipe nomeado" do win32, sendo bidirecional.
Pipes Linux
First In First Out (FIFO) mecanismo de comunicação interproccess.
Tubos sem nome
Na linha de comando, representada por um "|" entre dois comandos.
Canais nomeados
Um arquivo especial FIFO. Uma vez criado, você pode usar o canal como um arquivo normal (abrir, fechar, gravar, ler, etc.).
Para criar um pipe nomeado, chamado "myPipe", na linha de comando ( página de manual ):
mkfifo myPipe Para criar um canal nomeado a partir de c, onde "nome do caminho" é o nome que você deseja que o canal tenha e "mode" contenha as permissões que você deseja que o canal tenha ( página de manual ):
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);tell()posicionar nem seek()em um cano.
De acordo com a Wikipedia :
[...] Um canal tradicional é "sem nome" porque existe anonimamente e persiste apenas enquanto o processo estiver em execução. Um canal nomeado é persistente no sistema e existe além da vida útil do processo e deve ser "desvinculado" ou excluído quando não estiver mais sendo usado. Os processos geralmente são anexados ao canal nomeado (geralmente aparecendo como um arquivo) para executar o IPC (comunicação entre processos).
Comparar
echo "test" | wcpara
mkdnod apipe p
wc apipewc irá bloquear até
echo "test" > apipeexecuta
Pipes são uma maneira de transmitir dados entre aplicativos. No Linux, eu uso isso o tempo todo para transmitir a saída de um processo para outro. Isso é anônimo porque o aplicativo de destino não faz ideia de onde vem esse fluxo de entrada. Não precisa.
Um pipe nomeado é apenas uma maneira de conectar-se ativamente a um pipe existente e acumular seus dados. É para situações em que o provedor não sabe quais clientes estarão consumindo os dados.
Este é um exemplo da Technet (por isso não sei por que a resposta marcada diz que pipes nomeados são mais rápidos ??):
Canais nomeados x soquetes TCP / IP
Em um ambiente rápido de rede local (LAN), os clientes de soquetes e de pipes nomeados do protocolo TCP / IP (Transmission Control Protocol / Internet Protocol) são comparáveis em relação ao desempenho. No entanto, a diferença de desempenho entre os clientes de soquetes TCP / IP e pipes nomeados se torna aparente em redes mais lentas, como redes de longa distância (WANs) ou redes dial-up. Isso ocorre devido às diferentes maneiras pelas quais os mecanismos de comunicação entre processos (IPC) se comunicam entre os pares.
Para pipes nomeados, as comunicações de rede geralmente são mais interativas. Um par não envia dados até que outro solicite usando um comando de leitura. Uma leitura de rede geralmente envolve uma série de mensagens de exibição de pipes nomeados antes de começar a ler os dados. Isso pode ser muito caro em uma rede lenta e causar tráfego de rede excessivo , o que afeta outros clientes da rede.
Também é importante esclarecer se você está falando sobre pipes locais ou de rede. Se o aplicativo do servidor estiver sendo executado localmente no computador que está executando uma instância do SQL Server, o protocolo de pipes nomeados local será uma opção. Os pipes nomeados locais são executados no modo kernel e são muito rápidos.
Para soquetes TCP / IP, as transmissões de dados são mais simplificadas e têm menos sobrecarga. As transmissões de dados também podem tirar proveito dos mecanismos de aprimoramento de desempenho dos soquetes TCP / IP, como janelas, reconhecimentos atrasados etc. Isso pode ser muito útil em uma rede lenta. Dependendo do tipo de aplicativos, essas diferenças de desempenho podem ser significativas.
Os soquetes TCP / IP também suportam uma fila de pendências. Isso pode fornecer um efeito de suavização limitado comparado aos pipes nomeados que podem levar a erros de ocupado quando você está tentando se conectar ao SQL Server.
Geralmente, o TCP / IP é preferido em uma rede LAN, WAN ou dial-up lenta, enquanto os pipes nomeados podem ser uma escolha melhor quando a velocidade da rede não é o problema, pois oferece mais funcionalidade, facilidade de uso e opções de configuração.
Comunicação entre processos (principalmente) para aplicativos Windows. Semelhante ao uso de soquetes para se comunicar entre aplicativos no Unix.
Os pipes nomeados em um contexto unix / linux podem ser usados para criar dois shells diferentes para se comunicar, já que um shell simplesmente não pode compartilhar nada com outro.
Além disso, um script instanciado duas vezes no mesmo shell não pode compartilhar nada através das duas instâncias. Encontrei um uso para pipes nomeados ao codificar um daemon que contém a função start () e stop () e queria usar o mesmo script para executar as duas ações.
Sem pipes nomeados (ou qualquer tipo de semáforo), iniciar o script em segundo plano não é um problema. O problema é que, quando termina, você simplesmente não pode acessar a instância em segundo plano.
Portanto, quando você deseja enviar a ele o comando stop, você simplesmente não pode: executar o mesmo script sem pipes nomeados e chamar a função stop () não fará nada, pois na verdade você está executando outra instância.
A solução foi implementar dois pipes, um READ e outro WRITE quando você inicia o daemon. Em seguida, faça-o, entre outras tarefas, ouvir o canal READ. Em seguida, a função Stop () contém um comando que gravará uma mensagem no canal, que será manipulada pelo script de execução em segundo plano que executará uma saída 0. Dessa forma, nossa segunda instância do mesmo script tem apenas uma tarefa a executar: diga à primeira instância para parar.
Dessa forma, um e apenas um script pode iniciar e parar por si mesmo.
Claro que você tem maneiras diferentes de fazer isso, acionando a parada por meio de um toque, por exemplo. Mas este é legal e interessante de codificar.
Pipes nomeados é um sistema windows para comunicação entre processos. No caso do servidor SQL, se o servidor estiver na mesma máquina que o cliente, é possível usar pipes nomeados para transferir os dados, em oposição ao TCP / IP.