Anhaguera
Comunicação Distribuída Sockets Um socket é definido como uma extremidade de um canal de comunicação. Um par de processos (ou threads) se comunica em uma rede utilizando um par de sockets, sendo uma para cada processos. Um socket é formado por um endereço IP conectado com um número de porta. Em geral utilizam uma arquitetura cliente-servidor. Servidores que implementam serviços específicos, ouvem portas bem conhecidas (por exemplo, um servidor telnet ouve a porta 23, um servidor FTP, ouve a porta 21, um servidor web ouve a porta 80). Todas as bem conhecidas – po padrões. Quando uma threa ecebe uma porta atr arbitrário > 1024. r 6 Swipe to page ao consideradas ’ementar serviços de conexão, ela orta tem um número Por exemplo, se um cliente no host X com endereço IP 146. 86. 5. 20 desejar estabelecer uma conexão com um servidor web no endereço 161. 25. 19. 8, o host X poderá receber a porta 1 625 (por exemplo). A conexão consistirá então em um par de sockets: 146. 86. 5. 20:1 625 no host Xe 161. 25. 19. 8:80 no servidor web. Todas as conexões devem ser exclusivas. Exemplo: Servidor de data e hora Programa simples que obtém informações de data e hora de um servidor remoto. O servidor: (java. io. lOException e) { System. ut. println(e); public static void main(String args[]) { Servidor data e_hora = new Servidor(); private ServerSocket s; private Socket cliente; private Conexao c; A thread para atender o pedido de data e hora: import java. net. *; import java. io. *; public class Conexao extends Thread { public Conexao(Socket s) { outputLine = s; public void run() { try { PrintWriter pout new PrintWriter (outputLine. getOutputStream(),true); pout. println(“A data e a hora são: ” + new outputl_ine. close(); catch (java. io. lOException e) { private Socket outputLin hread chame um procedimento ou função em outro processo.
Esse outro processo pode estar em um espaço de endereçamento separado no mesmo computador ou pode estar executando em um computador distinto que é conectado por uma rede. A semântica RPC permite à thread solicitante ativar o procedimento remoto exatamente como faria com um procedimento local. A principal vantagem de um sistema RPC em relação aos sockets é que o sistema RPC gerencia o canal de comunicação, por isso os programas aplicativos podem ser escritos de modo que a localização de um procedimento, quer local ou remoto, seja transparente.
Implementação Aqui será utilizada uma ferramenta (rpcgen) de auxílio na implementação das aplicações RPC. O rpcgen é um compilador para RPC Language (RPCL). A utilização do rpcgen possibilita a implementação do protocolo de comunicação das aplicações de uma forma rápida, pois partindo das definições de um arquivo aplicacao. x o compilador gera os fontes necessários em C, que são os arquivos “stubs” para o cliente e para o servidor, o arquivo de descrição e caso necessário o XDR responsável pela conversão de tipos de dados. Pode opcionalmente gerar templates para os arquivos do cliente e servidor.
Tomando como exemplo uma aplicação simples, para enviar mensagens, definimos seu arquivo RPCL msg. x: msg. x: Remote message printing protocol k/ program MESSAGEPROG PRINTMESSAGE com seu número de procedimento 1 . Este tipo de definição permite que existam diversos programas em diversas versões com inumeros procedimentos. Compilando o arquivo msg. x da forma: rpcgen -a msg. x O rpcgen criará os arquivos “stubs” msg_clnt. c (cliente) e msg_svc. c (servidor) assim como msg. h e os esqueletos das aplicações msg_client. c (cliente) e msg_sever. c (servidor).
Descreveremos aqui apenas os arquivos das aplicações nos quais erão implementados os procedimentos necessários. OBS: os blocos em negrito foram incluídos após a geração dos arquivos. msg. h: * please do not edit this file. * It was generated using rpcgen. #ifndef MSG H RPCGEN #define MSG H RPCGEN #include #ifdef _cplusplus extern { #endif static int result; FILE *f; NULL) result = 0, return (); fprintf(f, “Cliente: *argp); fclose(f); result return &result; * This is sample code generated by rpcgen. * These are only templates and you can use them * as a guideline for developing your own functions. #include “msg. i’ void messageprog_l(char *host, char *msg) CLIENT *Cinc int //char *printmessage_l _ ar • Foi comentado APÔS a geração do arquivo objeto remoto. Os objetos são considerados remotos se residirem em uma máquina virtual Java distinta. Portanto, o objeto pode estar em uma JVM diferente no mesmo computador ou em um host remoto conectado por uma rede. Existem duas diferenças fundamentais entre RMI e RPC. Em primeiro lugar, as RPCs suportam apenas programação procedural, na qual somente procedimentos ou funções remotos podem ser chamados. A RMI baseia-se em objetos: suporta a invocação de métodos em objetos remotos.
Em segundo lugar, os parâmetros dos procedimentos remotos na RPC são estruturas de dados comuns; com a RMI é possível passar objetos como parâmetros para os métodos remotos. Permitindo que um programa Java invoque métodos em objetos remotos, a RMI torna possível aos usuários desenvolver aplicações Java que sejam distribuídas por toda a rede. Para tornar os métodos remotos transparentes ao cliente e ao servidor, a RMI implementa o objeto remoto usando stubs e skeletons. Um stub é um Proxy do objeto remoto; ele reside junto ao cliente. Quando o cliente invoca um método remoto, ele chama o tub para o objeto remoto.
Esse stub é responsável por criar um pacote que consiste no nome do método a ser invocado no servidor e nos parâmetros desse método – marshalling dos parâmetros. O stub envia então esse pacote para o servidor, onde é recebido pelo skeleton do objeto remoto. O skeleton é responsável por efetuar a operação de unmarshalling dos parâmetros e por invocar o método desejado no servidor. O skeleton agrega os valores de retorno (ou exceção, se houver) em um pacote e retorna-o ao cliente. O stub efetua a extração do valor de retorno e o passa ao cliente. ***exemplos***