Comunicação usando soquetes.

Transcrição

1 Soquetes Um soquete é 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 soquetes - um para cada processo. Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos de clientes ouvindo a uma porta específica. Assim que um pedido é recebido, o servidor aceita uma conexão do soquete cliente para completar a conexão. Os servidores que implementam serviços específicos (como telnet, ftp, mail e http) ouvem portas bem conhecidas (um servidor telnet ouve a porta 23, um servidor ftp ouve a porta 21, e um servidor Web (http) ouve a porta 80). Todas as portas abaixo de 1024 são consideradas bem conhecidas; podemos usá-las para implementar tais serviços padrão. Quando um thread cliente inicia um pedido de conexão, ele recebe uma porta atribuída pelo host. Essa porta tem um número arbitrário > Por exemplo, se um cliente no hostxcom endereço IP desejar estabelecer uma conexão com um servidor Web (que está ouvindo a porta 80) no endereço , o host X poderá receber a porta A conexão consistirá então em um par de soquetes: ( :1625) no host X e ( :80) no servidor Web. Os pacotes que viajam entre os hosts são entregues aos threads apropriados, com base no número da porta de destino. Todas as conexões devem ser exclusivas. Portanto, se outro processo também no host X desejasse estabelecer outra conexão com o mesmo servidor Web, a ele seria atribuído um número de porta > 1024 e Isso garante que todas as conexões consistem em um único par de soquetes. Servidores e threads Em geral, os servidores podem ter vários pedidos concorrentes. A quantidade de tempo que um cliente pode ter de esperar para ser atendido por um servidor de mono-thread pode ser inaceitável. Para resolver essa situação, um servidor pode lidar com pedidos concorrentes atribuindo um thread separado para atender cada pedido que chega. Por exemplo, um servidor Web atarefado pode atribuir um thread separado para atender cada solicitação de página Web. hostx ( servidor Web ( Comunicação usando soquetes. Soquetes Java A linguagem Java fornece três tipos diferentes de soquetes. Os soquetes orientados a conexão (TCP) são implementados com a classe Socket. Os soquetes sem conexão (UDP) utilizam a classe DatagramSocket. Um terceiro tipo é a classe MulticastSocket, que é uma subclasse da classe DatagramSocket. Um soquete de difusão seletiva (multicast) permite que um dado seja enviado para múltiplos destinatários simultaneamente. Servidor de data e hora Como um exemplo de soquetes baseados em Java, agora vamos apresentar várias classes Java para implemen-

2 tar um servidor de data e hora com múltiplos threads. Sua operação permite que os clientes solicitem a data e hora do servidor. O servidor ouve a porta 5155, embora a porta possa ser qualquer número arbitrário > Quando uma conexão é recebida, o servidor cria um novo thread para atender o pedido. Esse novo thread retorna ao cliente a data e hora do dia. O servidor O servidor de data e hora cria um ServerSocket que especifica que ele ouvirá a porta Em seguida, ele começa a escutar a porta com o método accept ( ). O servidor bloqueia no método accept ( ) esperando que algum cliente solicite uma conexão. Quando um pedido de conexão é recebido, accept ( ) retorna um soquete que o servidor pode usar para se comunicar com o cliente. O servidor cria um novo thread para atender o pedido e passa o soquete para esse thread. O servidor, em seguida, retoma o processo de escuta por mais pedidos. Os detalhes que ilustram como o servidor se comunica com o soquete estão especificados na classe Connection. Cada thread Connection recebe o soquete para o cliente ao qual ele fornecerá a data e hora do dia. O thread primeiro estabelece um objeto PrintWriter que será usado para comunicação com o cliente. Um objeto PrintWriter permite que o thread escreva no soquete usando os métodos de saída normais print( ) e p r i n t l n ( ). O thread envia a hora para o cliente chamando o método println( ). Assim que tiver gravado a data e hora do dia no soquete, ele fecha o soquete e o thread termina. Para iniciar o servidor, a instrução java Server é digitada na linha de comandos. O servidor permanece em execução enquanto escuta a porta 5155 esperando por conexões. Sempre que receber um pedido de conexão de um cliente, o servidor criará um thread Connection separado para atender o pedido e, em seguida, retomará o processo de escuta da porta import Java.net.*; public class Server { public Server ( ) { // cria o soquete try { s = new ServerSocket(5155) ; } catch (java.io.ioexception e) { System. out. println(e) ; System. exit(l) ; // OK, agora escuta as conexões System. out. print1n("server is listening.") ; try while (true) { client = s.accept( ); // cria um thread separado // para atender o pedido c = new Connection(client) ; c.start( ); catch (java.io.ioexception e) { System. out. println(e) ;

3 public static void main(string args[ ]) Server timeofdayserver = new Server( ) private ServerSocket s; private Socket client; private Connection c; } Servidor de data e hora. O cliente Um cliente se comunica com o servidor criando um soquete e se conectando à porta onde o servidor está escutando. Ele pode simplesmente estabelecer uma conexão telnet com a porta Por exemplo, o comando telnet abre um soquete e solicita uma conexão com o servidor no endereço l na porta servidor responde com a data e hora do dia. O endereço IP é um endereço especial conhecido como host local. Quando um computador se refere ao endereço , ele está fazendo referência a si mesmo. Esse mecanismo permite que um cliente e um servidor no mesmo host se comuniquem usando o protocolo TCP/IP mesmo se o computador não estiver conectado a uma rede. O cliente cria um Socket e solicita uma conexão com o servidor na porta Assim que a conexão é feita, o cliente pode ler do soquete usando instruções de I/O de arquivo normais. Depois que tiver recebido a hora do servidor, o cliente fecha o soquete e termina. Para executar o programa cliente, a instrução java Cl ient é digitada na linha de comandos. import java.net.*; import java.io.*; public class Connection extends Thread { public Connection(Socket s) { outputline = s; public void run( ) { try { // cria um objeto PrintWriter // com esvaziamento automático. // Isso permite IO de arquivo // comum no soquete. PrintWriter pout = new PrintWriter (outputline.getoutputstream( ), true); // agora envia uma mensagem ao cliente pout.println("the Date and Time is" + new java.util.date( ).tostring( )); // agora fecha o soquete outputline.close( ); } catch (java.io.loexception e) { System.out.println(e); private Socket outputline; Thread para atender pedidos de data e hora.

4 import java.net.*; import java.io.*; public class Client public Client( ) { try { Socket s = new Socket(" ",5155); InputStream in = s.get!nputstream( ); BufferedReader bin = new BufferedReader (new InputStreamReader(in)); System.out.println(bin.readLine( )); s.close( ); í catch (java.io.ioexception e) { System.out.println(e); System.exit(l); public static void main(string args[ ]) Client client = new Client( ); O cliente. Chamadas de procedimento remoto A comunicação usando soquetes - embora comum e eficiente - é considerada uma forma de comunicação de baixo nível entre processos ou threads distribuídos. Um dos motivos é que os soquetes só permitem a troca de um fluxo não-estruturado de bytes entre os threads em comunicação. É responsabilidade da aplicação cliente ou servidor impor uma estrutura aos dados. Vamos analisar dois métodos alternativos de comunicação de nível mais alto. A primeira abordagem é uma chamada de procedimento remoto (RPC - Remote Procedure Call). Um sistema RPC permite que um thread 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 de RPCs permite ao thread solicitante ativar o procedimento remoto exatamente como faria com um procedimento local. A vantagem das RPCs em relação aos soquetes é 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. Invocação de método remoto A segunda abordagem que exploramos é a invocação de método remoto (RMI, remote method invocation), um recurso Java semelhante a RPCs. A RMI permite que um thread invoque um método em um objeto remoto. Os objetos são considerados remotos se residirem em uma máquina virtual Java (JVM -Java Virtual Machine) 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 RPCs. Em primeiro lugar, as RPCs suportam apenas programação procedural, na qual somente procedimentos ou funções remotos podem ser chamados. A RMI baseiase 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

5 distribuídas por toda a rede. JVM JVM Invocação de método remoto. 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 (representante) do objeto remoto; ele reside junto ao cliente. Quando o cliente invoca um método remoto, é esse stub para o objeto remoto que é chamado. Esse stub no cliente é 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, um processo conhecido como marshalling dos parâmetros. O stub envia então esse pacote (agregação) para o servidor, onde ele é recebido pelo skeleton do objeto remoto. O skeleton é responsável por efetuar a operação de unmarshalling (extração) dos parâmetros e por invocar o método desejado no servidor. O skeleton agrega o valor 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 para o cliente. Vamos demonstrar como esse processo funciona. Considere que um cliente deseja invocar um método em um objeto remoto Server com a assinatura somemethod(object, Object) que retorna um valor boolean. O cliente executa a instrução boolean vai = Server.someMethod(A, B); A chamada a somemethod( ) com os parâmetros A e B invoca o stub para o objeto remoto. O stub agrega em um pacote os parâmetros A e B e o nome do método que deverá ser invocado no servidor, enviando o pacote para o servidor. O skeleton no servidor extrai os parâmetros e invoca o método somemethod ( ). A implementação real de somemethod ( ) reside no servidor. Assim que o método for concluído, o skeleton agrega o valor bool ean retornado de somemethod ( ), enviando esse valor de volta para o cliente. O stub extrai esse valor de retorno e o passa para o cliente. cliente objeto remoto Agregação e extração de parâmetros

6 Felizmente, o nível de abstração que a RMI fornece torna os stubs e skeletons transparentes, permitindo que o desenvolvedor Java escreva programas que invoquem os métodos distribuídos exatamente como invocariam métodos locais. Entretanto, é fundamental que você compreenda algumas regras sobre o comportamento da passagem de parâmetros. Se os parâmetros agregados forem objetos locais (não-remotos), eles serão passados por cópia usando uma técnica chamada serialização de objetos. No entanto, se os parâmetros também forem objetos remotos, eles são passados por referência. No nosso exemplo, se A for um objeto local e B um objeto remoto, A será serializado e passado por cópia, e B será passado por referência. Isso, por sua vez, permitiria que o servidor chamasse métodos em B remotamente. Passar objetos remotos como parâmetros é uma técnica RJV1I importante. Se os objetos locais deverão ser passados como parâmetros aos objetos remotos, eles devem implementar a interface java.io.serializable. Muitos objetos na API Java principal implementam Seria-1i zabl e, permitindo que eles sejam usados com RMI. A serialização de objetos permite que o estado de um objeto seja escrito em um fluxo de bytes. Agora, vamos apresentar uma solução atribuída via troca de mensagens para o problema do produ-tor-consumidor usando RMI. Essa solução distribuída consistirá em um objeto remoto para mensagens que serão passadas por referência, permitindo que os threads consumidor e produtor invoquem os métodos send( ) e receive( ) remotamente. Objetos remotos Definimos objetos remotos primeiro declarando uma interface que especifica os métodos que podem ser chamados remotamente. No exemplo da solução via troca de mensagens para o problema do produtor-consumidor, são os métodos send( ) e receive( ). Essa interface deve estendera interface java.rmi. Re-mote, que identifica o objeto como sendo remoto. Em seguida, cada método declarado na interface deve tratar a exceção java.rmi.remoteexception. Import java.util.*; Import java.rmi.*; public interface MessageQueue extends j ava. rmi.remote { public void send(0bject item) throws java.rmi.remot eexception; public Object receive( ) throws java.rmi. Remote Exceptio n; A interface MessageQueue.

7 Import java.util.*; Import Java.rmi.*; public class MessageQueuelmpl extends java.rmi.server.unicastre moteobject implements MessageQueue { public MesssageQueuelmpl ( ) throws RemoteExce ption { queue = new Vector( ); } public synchronized void send(0bject item) throws RemoteExce ption { // Figura 15.9 } public synchronized Object receive( ) throws RemoteExce ption public static void main(string args[ ]) { System.setSecurityManag er (new RMISecurityManager( )); try { MessageQueue server = new MessageQueuelmpl( ); Naming.rebind("MessageServer", server); System.out.println("Serv er Bound"); } catch(exception e) { System.err.println(e); private Vector queue; Implementação da interface MessageQueue. A classe que define o objeto remoto deve implementar a interface MessageQueue. Além de definir os métodos da interface, a classe também deve estender j ava. rmi. server. Uni cãs tremoteob j ect. Estender Uni castremoteobject permite a criação de um objeto remoto único que escuta os pedidos da rede utilizando o esquema padrão RMI de soquetes para comunicação de rede. Esse objeto também inclui um método main ( ). Esse método instala um gerente de segurança especial, RMISecuri tymanager. O papel do RMISecuri tymanager é impor restrições de segurança em classes mal-comportadas ou maliciosas que podem ser carregadas da rede. Se um gerente de segurança não estiver instalado, a RMI permitirá que classes sejam carregadas apenas do sistema de arquivos local e não a partir da rede. Em seguida, uma instância do objeto será criada e registrada no registro RMI que executa no servidor, através do método rebind( ). Nesse caso, a instância de objeto registra a si própria com o nome MessageServer. Observe também que a estrutura da classe MessageQueuelmpl deve gerar uma RemoteExcepti on se uma falha de comunicação ou de

8 rede impedir a RMI de exportar o objeto remoto. Observe que as implementações dos métodos send( ) e receive( ) são declaradas como synchronized. Também podemos usar a sincronização de threads Java para impedir o acesso concorrente a objetos remotos., // Isto implementa um envio não bloqueante public synchronized void send(0bject item) throws RemoteException { queue.addelement(item); System.out.println("Producer entered " * item + " size = " + queue.size( )); // Isto implementa uma recepção não bloqueante public synchronized Object receive( ) throws RemoteException { Object item; if (queue.size( ) == 0) return null; else { item = queue.firstelement( ); queue.removeel ementat(0); System.out.println("Consumer removed " + item + " size = " + queue.size( )); return item; Os métodos send e receive. Acesso ao objeto remoto Assim que um objeto é registrado no servidor, um cliente (conforme indicado na Figura 15.10) pode obter uma referência a esse objeto remoto a partir do registro RMI que executa no servidor usando o método Na-ming. lookup ( ). A RMI fornece um esquema de pesquisa baseado em URL que usa a forma rmi: //host/ob-jectname, no qual host é o nome IP do servidor no qual o objeto remoto objectname reside. objectname é o nome do objeto remoto especificado pelo servidor no método rebind( ) (nesse caso, MessageServer). O cliente também deve instalar um RMISecuri tymanager para garantir a segurança dos stubs remotos que podem ser carregados via rede. Assim que o cliente tiver uma referência ao objeto remoto, ele criará threads produtor e consumidor separados, passando a cada thread uma referência ao objeto remoto. Observe que os threads produtor e consumidor invocam os métodos remotos send ( ) e recei vê ( ) como invocações de método normais. import java.util.*; import java.rmi.*; public class Factory { public Factory( ) { // objeto remoto MessageQueue mailbox; System.setSecurityManager(new RMISecurityManager( ));

9 try { mailbox = (MessageQueue)Naming.lookup ("rmi:// /messageserver"); Producer producerthread = new Producer(mailBox); Consumer consumerthread = new Consumer(mailBox); producerthread.start( ); consumerthread.start( ); } catch (Exception e) { System.err.println(e); // produtor e consumidor chamarão este método para dormir public static void napping( ) { int sleeptime = (int) (NAP_TIME * Math.random( )); try { Thread.sleep(sleepTime*1000); } catch(interruptedexception e) { }.... public static void main(string args[ ]) { Factory client = new Factory( ); } private static final int NAP_TIME = 5; O cliente. Execução dos programas Agora vamos demonstrar as etapas necessárias para executar os programas de exemplo. Para fins de simplicidade, estamos considerando que todos os programas estão executando no host local. No entanto, a comunicação ainda é considerada remota, porque os programas cliente e servidor estão executando em suas próprias JVMs. l. Compile todos os arquivos fonte. 2. Gere o stub e o skeleton. A ferramenta RMIc é usada para gerar os arquivos de classe stub e skeleton, o que é realizado quando o usuário digita rmi c MessageQueuelmpl na linha de comandos; isso cria os arquivos MessageQueueImpl_Skel.class e MessageQueueImpl_Stub.class. (Se você estiver executando esse exemplo em dois computadores diferentes, certifique-se de que todos os arquivos de classe - incluindo as classes stub - estão disponíveis em cada computador. Também é possível carregar as classes dinamicamente usando RMI, um tópico além do escopo deste texto mas discutido nos textos mencionados nas Notas bibliográficas.) 3. Inicie o registro e crie o objeto remoto. Para iniciar o registro em plataformas UNIX, o usuário pode digitar rmiregistry & No Windows, o usuário poderá digitar start rmiregistry Esse comando inicia o registro no qual o objeto remoto será registrado. Em seguida, crie uma instância do objeto remoto com

10 java MessageQueuelmpl Esse objeto remoto se registrará usando o nome MessageServer. 4. Faça referência ao objeto remoto. A instrução java Factory é digitada na linha de comandos para iniciar o programa cliente. Esse programa obterá uma referência do objeto remoto MessageServer e criará os threads produtor e consumidor, passando para cada thre-ad a referência do objeto remoto. Os threads produtor e consumidor agora podem invocar os métodos send( ) e receive( ) no objeto remoto. CORBA RMI é uma tecnologia que permite que os threads invoquem métodos em objetos distribuídos. Entretanto, RMI é uma tecnologia Java nativa e por isso requer que todas as aplicações distribuídas sejam escritas em Java. Muitos sistemas existentes que talvez também queiramos que sejam distribuídos são escritos em C, C + +, COBOL ou Ada. Nenhum protocolo de comunicação discutido até agora fornece um mecanismo conveniente para essas aplicações diferentes se comunicarem. import java.útil,*; class Producer extends Thread public Producer(MessageQueue m) { mbox = m; l public void run( ) { Date message; while (true) { Factory.napping( ); message = new Date( ); try { mbox.send(message}; catch (Exception e) { System.err.pritnln(e); private MessageQueue mbox; Thread produtor. Common Object Request Broker Architecture (CORBA) é um middleware - uma camada de software intermediária - que permite a comunicação entre aplicações cliente e servidor heterogêneas. Por exemplo, um programa C+ + pode usar CORBA para acessar um serviço de banco de dados escrito em COBOL. CORBA permite que aplicações escritas em diferentes linguagens se comuniquem usando uma interface definition language (IDL) e um Object Request Broker (ORB). Uma IDL permite a um objeto distribuído - como um banco de dados - descrever uma interface para os serviços que fornece. A IDL é uma linguagem de programação genérica; permite que um serviço descreva a si próprio

11 independentemente de qualquer linguagem específica. Para comunicar com um servidor, um cliente precisa se comunicar apenas com a interface especificada via IDL. O objeto servidor implementa a interface especificada pela IDL. O ORB forma a espinha dorsal de COBRA, permitindo que os clientes invoquem métodos em objetos distribuídos e aceitem valores de retorno. Existe um ORB no cliente e no servidor, e um protocolo, o Internet InterORB Protocol (IIOP), que especifica como os ORBs podem ser comunicar. import java.util.*; class Consumer extends Thread public Consumer (MessageQueue m) mbox = m; public void run( ) { Date message; while (true) { Factory.napping( try message = (Date)mbox.receive( ); i f (message! = null) // Consome o item catch (Exception e) { System.err.println(e); private MessageQueue mbox; Thread consumidor. Quando uma aplicação cliente s olicita uma referência para um objeto remoto, é responsabilidade do ORB do cliente localizar o objeto remoto no sistema distribuído. O ORB do cliente também é responsável por rotear as invocações de método remoto para o servidor apropriado e por aceitar os resultados do servidor. O ORB do servidor permite que o servidor registre novos objetos CORBA e também é responsável por aceitar pedidos de ORBs de clientes para chamar métodos no servidor. O ORB do servidor também devolve valores de retorno para o cliente. Um sistema CORBA funciona da seguinte maneira. Assim que um cliente tiver uma referência a um objeto remoto, quaisquer invocações de métodos para esse objeto são feitas através do stub cliente. Esse stub utiliza o ORB do cliente para se comunicar com o servidor. Quando o ORB do servidor recebe um pedido do cliente para invocar um método, ele chama o skeleton apropriado, que, por sua vez, invoca a implementação do método remoto no servidor. Os valores de retorno são devolvidos pelo mesmo caminho. Em muitos aspectos, o comportamento do ORB é muito semelhante ao de RMI. No entanto, RMI é uma tecnologia Java para Java. CORBA fornece interoperabilidade entre clientes e servidores heterogêneos, permitindo a comunicação entre aplicações escritas em diferentes linguagens.

12 Registro de objetos Tanto RMI quanto CORBA são sistemas de objetos distribuídos: os objetos são distribuídos em uma rede e as aplicações podem se comunicar com os objetos distribuídos. Um recurso importante desses sistemas é um serviço de registro de objeto, com o qual um objeto se registra. As aplicações que desejarem utilizar um objeto distribuído obtêm uma referência ao objeto através desse serviço. O rmiregistry atua como um serviço de registro para RMI. Assim que o registro é iniciado, um objeto remoto se registra com um nome exclusivo usando o método Naming.rebind ( ). Os clientes usam esse nome quando solicitam ao servidor de registro uma referência ao objeto remoto. Usando RMI, um cliente obtém uma referência a um objeto remoto usando o método Naming.lookup ( ). Em um sistema CORBA, o ORB no servidor é responsável por fornecer o serviço de registro.