UMA COMUNICAÇÃO ENTRE PROCESSOS

...

A forma síncrona utiliza o envio da mensagem e o processo origem fica bloqueado até que recebimento dessa mensagem seja feito. Já na forma assíncrona, não há bloqueio após o envio da mensagem, pois existe um buffer que guarda os subprocessos(threads) que permite o receiver processar cada vez que estiver pronto.

Para que haja a troca de mensagens, são necessários os identificadores, que são o IP(Internet Protocol) e a porta, do destinatário e remetente. Essas portas são representadas por números e são usadas para que processos possam enviar mensagens para outros processos. Deve-se verificar a integridade dos pacotes enviados, pois os mesmos podem chegar corrompidos ou nem mesmo chegar.

Os protocolos TCP e UDP utilizam soquetes para efetuar a comunicação entre processos, via endereço de IP e número de porta. Segundo Coulouris, Dollimore, Kindberg e Blair (2013, p. 149), “Cada computador tem 216 números de portas disponíveis para serem usados pelos processos para envio e recepção de mensagens”, como informado antes, o soquete deve saber a porta disponível para efetuar a comunicação, assim como o tipo de protocolo a utilizar entre os dois já citados.

No protocolo UDP, o remetente envia pacotes ao destinatário sem receber uma mensagem de confirmação, que gera um ganho no desempenho do programa ainda que haja a probabilidade que os pacotes não cheguem. Para efetuar comunicação via UDP, o cliente utiliza uma porta livre e não reservada no sistema, já o servidor recebe a mensagem e envia a resposta pelo endereço IP do remetente e a mesma porta vinculada.

Algumas características do datagrama devem ser consideradas na utilização do protocolo UDP, são elas o tamanho da mensagem, deve ter um limite que pode ser alterado de acordo com as restrições do servidor; o bloqueio, como o método send é não bloqueante, o método receive bloqueia processo(s) na espera dessas múltiplas threads, dependendo da implementação, o método servidor tem threads específicas para tratar somente do recebimento dos datagramas, tornando-se a maior parte do tempo disponível; os timeouts, são limites de tempo utilizados para conexões que esperam os as mensagens dos clientes, essa estrutura impede que os processos não esperem indefinidamente por uma mensagem.

De acordo com Kurose e Ross (2013, p. 242), “O protocolo IP não garante a entrega do datagrama, nem a entrega em ordem, e também não garante a integridade dos dados nos datagramas”. O modelo de falhas tenta prezar a integridade dos arquivos ou mensagens, os fluxos TCP usam os checksums para verificar os pacotes, caso exista alguma alteração ou duplicação, estes são rejeitados e solicitados novamente pelo destinatário. Caso ocorram várias vezes erro de envio de mensagem ou resposta(confirmação), o protocolo TCP informará falha de comunicação que pode ser falha na rede ou mesmo no processo, sem mais detalhes.

Comunicação Multicast

Segundo Tanenbaum e Steen (2007, p. 100), “A ideia básica do multicasting no nível de aplicação é que os nós se organizem em uma rede de sobreposição que então é usada para disseminar informações para seus membros”. Sempre que a comunicação é feita via sistemas distribuídos, a comunicação via processos em pares já não é tão eficiente, pois existem vários processos hardwares diferentes e com desempenhos diferentes. Para deixar a aplicação mais eficiente, os processos podem utilizar a comunicação via multicast, onde um grupo de hosts receberá uma mensagem específica para cada host, aproveitando as vantagens de utilizar a programação distribuída. Porém, existem problemas quando se utiliza vários hardwares diferentes em um só sistema, as mensagens enviadas podem estar duplicadas, corrompidas ou desordenadas.

Os grupos multicast têm vantagens como seus participantes podem enviar e receber mensagens para o grupo mesmo sem saber a quantidade de hosts. Além disso, hosts podem pertencer a vários grupos ao mesmo tempo e enviar mensagens sem pertencerem a um grupo.

O multicast IP usa protocolo UDP e envia a mensagem pelo soquete para um IP vinculado a uma porta, quando a mensagem é recebida pelo roteador, todos os participantes do grupo recebem essa mensagem na porta especificada.

Coulouris, Dollimore, Kindberg e Blair (2013, p. 170) comenta que “Um grupo multicast é especificado por um endereço IP classe D […] – isto é, um endereço cujos primeiros 4 bits são 1110(22410) no protocolo IPv4.”(grifo nosso). A propagação dessas mensagens é feita utilizando os endereços de Classe D não reservados pela rede, ainda essa propagação é controlada por um tempo específico o TTL(time to live). Esse tipo de comunicação também tem falhas de omissão, por isso essa característica é conhecida como mutlicast não confiável.

Caso o roteador multicast falhar no envio da mensagem em um grupo de várias redes, os hosts dessa rede específica não receberão a mensagem. Em aplicações onde a ordenação tem muita importância, pode-se usar o multicast confiável, onde todos devem receber a mensagem. Além disso, existe o multicast ordenado, onde as mensagens enviadas a um grupo são transmitidas na mesma ordem.

Virtualização de Redes: Redes de Sobreposição

Aplicações distribuídas são implementadas de diversas formas e elas utilizam recursos da rede que podem estar sendo utilizados por outras aplicações. Uma forma de solucionar esse problema é a virtualização de redes, ondem um software cria uma sub-rede com as configurações necessárias para funcionar adequadamente sem prejudicar a experiência de outros softwares que dividem os mesmos recursos da