Comunicações entre processos

  • Artigo

O sistema operacional Windows fornece mecanismos para facilitar as comunicações e o compartilhamento de dados entre aplicativos. Coletivamente, as atividades possibilitadas por esses mecanismos são chamadas de comunicações interprocessos (IPC). Algumas formas de CPI facilitam a divisão do trabalho entre diversos processos especializados. Outras formas de CPI facilitam a divisão do trabalho entre computadores em rede.

Normalmente, os aplicativos podem usar IPC categorizado como clientes ou servidores. Um cliente é um aplicativo ou um processo que solicita um serviço de algum outro aplicativo ou processo. Um servidor é um aplicativo ou um processo que responde a uma solicitação do cliente. Muitos aplicativos atuam como um cliente e um servidor, dependendo da situação. Por exemplo, um aplicativo de processamento de texto pode atuar como um cliente ao solicitar uma tabela resumida de custos de fabricação de um aplicativo de planilha atuando como um servidor. O aplicativo de planilha, por sua vez, pode atuar como um cliente ao solicitar os níveis de estoque mais recentes de um aplicativo de controle de estoque automatizado.

Depois de decidir que seu aplicativo se beneficiaria do IPC, você deve decidir qual dos métodos de IPC disponíveis usar. É provável que um aplicativo use vários mecanismos de IPC. As respostas a essas perguntas determinam se um aplicativo pode se beneficiar usando um ou mais mecanismos de IPC.

  • O aplicativo deve ser capaz de se comunicar com outros aplicativos em execução em outros computadores em uma rede ou é suficiente para o aplicativo se comunicar apenas com aplicativos no computador local?
  • O aplicativo deve ser capaz de se comunicar com aplicativos em execução em outros computadores que podem estar sendo executados em sistemas operacionais diferentes (como Windows ou UNIX de 16 bits)?
  • O usuário do aplicativo deve escolher os outros aplicativos com os quais o aplicativo se comunica ou o aplicativo pode encontrar implicitamente seus parceiros cooperantes?
  • O aplicativo deve se comunicar com muitos aplicativos diferentes de uma maneira geral, como permitir operações de cortar e colar com qualquer outro aplicativo, ou seus requisitos de comunicação devem ser limitados a um conjunto restrito de interações com outros aplicativos específicos?
  • O desempenho é um aspecto crítico do aplicativo? Todos os mecanismos do IPC incluem alguma quantidade de sobrecarga.
  • O aplicativo deve ser um aplicativo GUI ou um aplicativo de console? Alguns mecanismos de IPC exigem um aplicativo GUI.

Os seguintes mecanismos IPC são suportados pelo Windows:

Usando a área de transferência para IPC

A área de transferência atua como um depositário central para o compartilhamento de dados entre aplicativos. Quando um usuário executa uma operação de corte ou cópia em um aplicativo, o aplicativo coloca os dados selecionados na área de transferência em um ou mais formatos padrão ou definidos pelo aplicativo. Qualquer outro aplicativo pode então recuperar os dados da área de transferência, escolhendo entre os formatos disponíveis que ele entende. A área de transferência é um meio de troca muito fracamente acoplado, onde os aplicativos só precisam concordar com o formato de dados. Os aplicativos podem residir no mesmo computador ou em computadores diferentes em uma rede.

Ponto chave: Todos os aplicativos devem oferecer suporte à área de transferência para os formatos de dados que eles entendem. Por exemplo, um editor de texto ou processador de texto deve pelo menos ser capaz de produzir e aceitar dados da área de transferência em formato de texto puro. Para obter mais informações, consulte Área de transferência.

Usando COM para IPC

Os aplicativos que usam OLE gerenciam documentos compostos — ou seja, documentos compostos de dados de vários aplicativos diferentes. O OLE fornece serviços que facilitam a chamada de outros aplicativos para edição de dados. Por exemplo, um processador de texto que usa OLE pode incorporar um gráfico de uma planilha. O usuário pode iniciar a planilha automaticamente de dentro do processador de texto, escolhendo o gráfico incorporado para edição. OLE se encarrega de iniciar a planilha e apresentar o gráfico para edição. Quando o usuário sair da planilha, o gráfico será atualizado no documento original do processador de texto. A planilha parece ser uma extensão do processador de texto.

A base do OLE é o COM (Component Object Model). Um componente de software que usa COM pode se comunicar com uma ampla variedade de outros componentes, mesmo aqueles que ainda não foram escritos. Os componentes interagem como objetos e clientes. O COM distribuído estende o modelo de programação COM para que ele funcione em uma rede.

Ponto chave: OLE oferece suporte a documentos compostos e permite que um aplicativo inclua dados incorporados ou vinculados que, quando escolhidos, iniciam automaticamente outro aplicativo para edição de dados. Isso permite que o aplicativo seja estendido por qualquer outro aplicativo que use OLE. Os objetos COM fornecem acesso aos dados de um objeto por meio de um ou mais conjuntos de funções relacionadas, conhecidas como interfaces. Para obter mais informações, consulte COM e ActiveX Object Services.

Usando a cópia de dados para IPC

A cópia de dados permite que um aplicativo envie informações para outro aplicativo usando a mensagem WM_COPYDATA. Este método requer cooperação entre o pedido de envio e o pedido de recepção. O aplicativo receptor deve conhecer o formato das informações e ser capaz de identificar o remetente. O aplicativo de envio não pode modificar a memória referenciada por nenhum ponteiro.

Ponto chave: a cópia de dados pode ser usada para enviar rapidamente informações para outro aplicativo usando mensagens do Windows. Para obter mais informações, consulte Cópia de dados.

Usando DDE para IPC

O DDE é um protocolo que permite que os aplicativos troquem dados em uma variedade de formatos. Os aplicativos podem usar o DDE para trocas de dados únicas ou para intercâmbios contínuos nos quais os aplicativos se atualizam uns aos outros à medida que novos dados se tornam disponíveis.

Os formatos de dados usados pelo DDE são os mesmos usados pela área de transferência. O DDE pode ser pensado como uma extensão do mecanismo da área de transferência. A área de transferência é quase sempre usada para uma resposta única a um comando do usuário, como escolher o comando Colar em um menu. O DDE também é geralmente iniciado por um comando de usuário, mas muitas vezes continua a funcionar sem interação adicional do usuário. Você também pode definir formatos de dados DDE personalizados para IPC de finalidade especial entre aplicativos com requisitos de comunicação mais fortemente acoplados.

As trocas de DDE podem ocorrer entre aplicativos em execução no mesmo computador ou em computadores diferentes em uma rede.

Ponto chave: o DDE não é tão eficiente quanto as tecnologias mais recentes. No entanto, você ainda pode usar DDE se outros mecanismos IPC não são adequados ou se você deve fazer interface com um aplicativo existente que oferece suporte apenas DDE. Para obter mais informações, consulte Dynamic Data Exchange e Dynamic Data Exchange Management Library.

Usando um mapeamento de arquivo para IPC

O mapeamento de arquivos permite que um processo trate o conteúdo de um arquivo como se fosse um bloco de memória no espaço de endereço do processo. O processo pode usar operações de ponteiro simples para examinar e modificar o conteúdo do arquivo. Quando dois ou mais processos acessam o mesmo mapeamento de arquivo, cada processo recebe um ponteiro para a memória em seu próprio espaço de endereço que pode ser usado para ler ou modificar o conteúdo do arquivo. Os processos devem usar um objeto de sincronização, como um semáforo, para evitar a corrupção de dados em um ambiente multitarefa.

Você pode usar um caso especial de mapeamento de arquivo para fornecer memória compartilhada nomeada entre processos. Se você especificar o arquivo de troca do sistema ao criar um objeto de mapeamento de arquivo, o objeto de mapeamento de arquivo será tratado como um bloco de memória compartilhada. Outros processos podem acessar o mesmo bloco de memória abrindo o mesmo objeto de mapeamento de arquivo.

O mapeamento de arquivos é bastante eficiente e também fornece atributos de segurança suportados pelo sistema operacional que podem ajudar a evitar a corrupção de dados não autorizados. O mapeamento de arquivos pode ser usado somente entre processos em um computador local; ele não pode ser usado em uma rede.

Ponto chave: o mapeamento de arquivos é uma maneira eficiente de dois ou mais processos no mesmo computador compartilharem dados, mas você deve fornecer sincronização entre os processos. Para obter mais informações, consulte Mapeamento e sincronização de arquivos.

Usando um Mailslot para IPC

Mailslots fornecem comunicação unidirecional. Qualquer processo que cria um mailslot é um servidor mailslot. Outros processos, chamados clientes mailslot, enviam mensagens para o servidor mailslot escrevendo uma mensagem em seu mailslot. As mensagens recebidas são sempre anexadas ao mailslot. O mailslot salva as mensagens até que o servidor mailslot as tenha lido. Um processo pode ser um servidor mailslot e um cliente mailslot, portanto, a comunicação bidirecional é possível usando vários mailslots.

Um cliente mailslot pode enviar uma mensagem para um mailslot em seu computador local, para um mailslot em outro computador ou para todos os mailslots com o mesmo nome em todos os computadores em um domínio de rede especificado. As mensagens transmitidas para todos os mailslots em um domínio não podem ter mais de 400 bytes, enquanto as mensagens enviadas para um único mailslot são limitadas apenas pelo tamanho máximo de mensagem especificado pelo servidor mailslot quando ele criou o mailslot.

Ponto chave: Mailslots oferecem uma maneira fácil para os aplicativos enviarem e receberem mensagens curtas. Eles também fornecem a capacidade de transmitir mensagens em todos os computadores em um domínio de rede. Para obter mais informações, consulte Mailslots.

Usando tubos para IPC

Existem dois tipos de tubos para comunicação bidirecional: pipes anônimos e pipes nomeados. Os pipes anônimos permitem que processos relacionados transfiram informações entre si. Normalmente, um pipe anônimo é usado para redirecionar a entrada ou saída padrão de um processo filho para que ele possa trocar dados com seu processo pai. Para trocar dados em ambas as direções (operação duplex), você deve criar dois pipes anônimos. O processo pai grava dados em um pipe usando seu identificador de gravação, enquanto o processo filho lê os dados desse pipe usando seu identificador de leitura. Da mesma forma, o processo filho grava dados no outro pipe e o processo pai lê a partir dele. Pipes anônimos não podem ser usados em uma rede, nem entre processos não relacionados.

Os pipes nomeados são usados para transferir dados entre processos que não são processos relacionados e entre processos em computadores diferentes. Normalmente, um processo de servidor de pipe nomeado cria um pipe nomeado com um nome conhecido ou um nome que deve ser comunicado a seus clientes. Um processo de cliente de pipe nomeado que sabe o nome do pipe pode abrir sua outra extremidade, sujeito a restrições de acesso especificadas pelo processo de servidor de pipe nomeado. Depois que o servidor e o cliente se conectarem ao pipe, eles poderão trocar dados executando operações de leitura e gravação no pipe.

Ponto chave: pipes anônimos fornecem uma maneira eficiente de redirecionar entrada ou saída padrão para processos filho no mesmo computador. Os pipes nomeados fornecem uma interface de programação simples para transferir dados entre dois processos, quer residam no mesmo computador ou em uma rede. Para obter mais informações, consulte Pipes.

Usando RPC para IPC

O RPC permite que os aplicativos chamem funções remotamente. Portanto, o RPC torna o IPC tão fácil quanto chamar uma função. RPC opera entre processos em um único computador ou em computadores diferentes em uma rede.

O RPC fornecido pelo Windows é compatível com o Open Software Foundation (OSF) Distributed Computing Environment (DCE). Isso significa que os aplicativos que usam RPC podem se comunicar com aplicativos em execução com outros sistemas operacionais que oferecem suporte a DCE. O RPC oferece suporte automático à conversão de dados para dar conta de diferentes arquiteturas de hardware e para ordenação de bytes entre ambientes diferentes.

Os clientes e servidores RPC são fortemente acoplados, mas ainda mantêm alto desempenho. O sistema faz uso extensivo de RPC para facilitar uma relação cliente/servidor entre diferentes partes do sistema operacional.

Ponto chave: RPC é uma interface de nível de função, com suporte para conversão automática de dados e para comunicações com outros sistemas operacionais. Usando RPC, você pode criar aplicativos distribuídos de alto desempenho e fortemente acoplados. Para obter mais informações, consulte Componentes RPC da Microsoft.

Usando o Windows Sockets para IPC

O Windows Sockets é uma interface independente de protocolo. Ele aproveita os recursos de comunicação dos protocolos subjacentes. No Windows Sockets 2, um identificador de soquete pode opcionalmente ser usado como um identificador de arquivo com as funções de E/S de arquivo padrão.

Os Windows Sockets são baseados nos soquetes popularizados pela Berkeley Software Distribution (BSD). Um aplicativo que usa o Windows Sockets pode se comunicar com outra implementação de soquete em outros tipos de sistemas. No entanto, nem todos os prestadores de serviços de transporte suportam todas as opções disponíveis.

Ponto chave: o Windows Sockets é uma interface independente de protocolo capaz de oferecer suporte a recursos de rede atuais e emergentes. Para obter mais informações, consulte Windows Sockets 2.

A função de soquete unix (AF_UNIX) no Windows

A partir do Windows Insider Build 17063, você pode usar a família de endereços de soquete unix (AF_UNIX) no Windows para se comunicar entre processos Win32. Os soquetes Unix permitem a comunicação entre processos (IPC) entre processos na mesma máquina. Para obter mais informações, consulte a postagem do blog AF_UNIX chega ao Windows.

A substituição do protocolo Remote Mailslot

A partir do Windows 11 Insider Preview Build 25314 e do Windows Server Preview Build 25314, começamos a desabilitar o protocolo Remote Mailslot por padrão. Este é um precursor para a depreciação e eventual remoção do Windows. Para obter mais informações, consulte a postagem do blog O início do fim dos Slots Remotos como parte do Windows Insider.