Communication entre processus From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001 Chapitre 4
Plan zCaractéristiques des protocoles de communication entre processus dans un système réparti yPrincipes généraux ycommunication xpar datagrammes Client-serveur Communication de groupe xpar flots (streams) Client-serveur yconstruction de protocoles pour les patterns de communication xclient-serveur : requête-réponse xgroupe : même message est envoyé à plusieurs processus ydonnées xreprésentation des objets dans les messages xréférences à des objets distants
Communication client-serveur Request ServerClient doOperation (wait) (continuation) Reply message getRequest execute method message select object sendReply
UDP vs TCP zUn protocole construit au-dessus de UDP épargne certains overheads imputables à TCP yUDP évite les accusés de réception redondants, la réponse du serveur sert d’accusé de réception yUDP épargne les messages de création de la connexion TCP yIl n’est pas nécessaire en général de gérer le flot de contrôle TCP car la plupart des invocations transmettent des arguments et des résultats de petite taille
Opérations du protocole requête-réponse public byte[] doOperation (RemoteObjectRef o, int methodId, byte[] arguments) sends a request message to the remote object and returns the reply. The arguments specify the remote object, the method to be invoked and the arguments of that method. public byte[] getRequest (); acquires a client request via the server port. public void sendReply (byte[] reply, InetAddress clientHost, int clientPort); sends the reply message reply to the client at its Internet address and port.
Structure des messages messageType requestId objectReference methodId arguments int (0=Request, 1= Reply) int RemoteObjectRef int or Method array of bytes
Modélisation des fautes zFaute par omission zPas de garantie de livraison dans l ’ordre d ’émission zDéfaillance des processus
Garantie de livraison zla réponse du serveur sert d ’accusé de réception zbesoin d ’un identificateur de messages plus complexes yid de la requête, unique du point de vue de l ’émetteur yid de l ’émetteur (InetAddress + port), unique du point de vue du système réparti zTimeouts ysender.doOperation (...) xréémettre le message un nombre raisonnable de fois xdéclencher une exception
Requêtes dupliquées zLorsque le message est réémis, le serveur peut recevoir le message plusieurs fois zreconnaître les messages successifs en provenance du même client avec le même identificateur de requêtes zrejeter les duplicatas
Réponses perdues zSi le serveur reçoit un duplicata d ’un message et qu ’il a déjà effectué l ’opération le serveur doit refaire l ’opération ou bien avoir conservé le résultat de l ’opération originale yHistorique xCompte de banque : le relevé des opérations peut être utilisé pour récupérer le résultat de l ’opération originale zopération idempotente yopération qui rend toujours le même résultat peu importe le nombre de fois où elle est exécutée
Historique zPour les serveurs qui doivent retransmettre les réponses sans ré-exécuter la requête zstructure yidentificateur de requête ymessage (réponse) yidentificateur du client zCoût ymémoire xsi les clients ne peuvent faire qu ’une requête à la fois une nouvelle requête = accusé de réception de la requête précédente xsupprimer les réponses après un certain temps
Utilisation de TCP pour implémenter le protocole requête-réponse zDatagramme ydifficile de décider d ’une taille appropriée pour les tampons qui reçoivent les datagrammes ytaille limitée (habituellement 8Kb) yPas adéquat pour des systèmes RMI transparents car la taille des arguments et des résultats est inconnue a priori zutilisation de TCP ypas besoin d ’implémenter un protocole multi-paquets ygarantie de livraison des requêtes et des réponses xpas besoin de retransmission, filtrage de duplicatas, historique ymécanisme de flot de contrôle de TCP permet de passer des arguments et résultats de n’importe quelle taille.
HTTP un protocole requête-réponse zbrowser Requête Réponse : serveur web zHTTP yprotocole requête-réponse qui spécifie xles messages impliqués dans l ’échange xles méthodes (nombre fixe) GET, PUT, POST,HEAD, PUT, DELETE, OPTIONS, TRACE xleurs arguments xles résultats xles règles de marshalling des arguments et des résultats requêtes et réponses ---> chaîne de caractères ASCII arguments et résultats ---> structure similaire au MIME –(Multipurpose Internet Mail Extensions) ex.: image/gif, etc. ressources ---> suite (compressée) d ’octets xnégociation du contenu les clients peuvent indiquer quel contenu ils acceptent xauthentification
zUtilise TCP zversion originale yétablissement d ’une connexion à la demande du client yrequête yréponse yfermeture de la connexion zHTTP 1.1 yconnexions persistantes xpeuvent être fermées par le client ou le serveur n ’importe quand xle serveur ferme la connexion après un certain temps d ’inactivité HTTP : implémentation
HTTP : méthodes zGET : obtenir la ressource spécifiée par l ’URL zHEAD : obtenir les informations sur la ressource, e.g. dernière date de modification zPOST : URL d ’une ressource qui peut traiter les données transmises avec la requête zPUT : ajouter une ressource à l ’ URL spécifié zDELETE : détruire la ressource à l ’URL spécifié zOPTIONS : la liste des méthodes applicables pour un URL zTRACE : écho du message pour diagnostic
zRequête yen-tête: modification et informations sur le client zRéponse yen-tête: informations sur le serveur et accès à la ressource (e.g. besoin d ’authentification) zCorps des messages yen-tête : informations sur les données, taille, jeu de caractères, date de modification, type MIME ( incluant quel algorithme de compression) Contenu des messages
Clients invoke individual servers
A distributed application based on peer processes
A service provided by multiple servers
Web proxy server
Web applets
Thin clients and compute servers Thin Client Application Process Network computer or PC Compute server network
Client SMTP import java.io.*;import java.net.*; public class smtpClient { public static void main(String[] args) { // declaration section: // smtpClient: our client socket // os: output stream // is: input stream Socket smtpSocket = null; DataOutputStream os = null; DataInputStream is = null; // Initialization section: // Try to open a socket on port 25 // Try to open input and output streams try { smtpSocket = new Socket("hostname", 25); os = new DataOutputStream(smtpSocket.getOutputStream()); is = new DataInputStream(smtpSocket.getInputStream()); } catch (UnknownHostException e) { System.err.println("Don't know about host: hostname"); } catch (IOException e) { System.err.println("Couldn't get I/O for the connection to: hostname"); }
// If everything has been initialized then we want to write some data // to the socket we have opened a connection to on port 25 if (smtpSocket != null && os != null && is != null) { try { // The capital string before each colon has a special meaning to SMTP // you may want to read the SMTP specification, RFC1822/3 os.writeBytes("HELO\n"); os.writeBytes("MAIL From: os.writeBytes("RCPT To: os.writeBytes("DATA\n"); os.writeBytes("From: os.writeBytes("Subject: testing\n"); os.writeBytes("Hi there\n"); // message body os.writeBytes("\n.\n"); os.writeBytes("QUIT"); // keep on reading from/to the socket till we receive the "Ok" from SMTP, // once we received that then we want to break. String responseLine; while ((responseLine = is.readLine()) != null) { System.out.println("Server: " + responseLine); if (responseLine.indexOf("Ok") != -1) { break; } // clean up: // close the output stream // close the input stream // close the socket os.close(); is.close(); smtpSocket.close(); } catch (UnknownHostException e) { System.err.println("Trying to connect to unknown host: " + e); } catch (IOException e) { System.err.println("IOException: " + e); }
Exemples zMultithreaded chat server yhttp:// zSimple web server yhttp://java.sun.com/developer/technicalArticles/Networking/Webserver/ zKnock Knock server yhttp://java.sun.com/docs/books/tutorial/networking/sockets/clientServer. html