\documentstyle[12pt,a4]{article} % % le document sort sous le format A4 % Il faut introduire le fichier A4.STY dans le directory courant % \begin{document} % % Permet de souligner du texte % \def\souligne#1{$\underline{\smash{\hbox{#1}}}$} % % % % % % % \begin{center} \bf{ -------------------------------------------------------\\ % {\LARGE EUROGAM Project }\\ % {\LARGE Using Sun RPC}\\ -------------------------------------------------------}\\ \end{center} % % % % % % \noindent {\Large Edition 0.1\\ October 1990\\} % % % \begin{center} {\bf \LARGE . . .\\ .\\} \end{center} % % % % % % \noindent {\bf CENBG BORDEAUX, FRANCE : P. Kadionik} \newpage % % P. Kadionik 09/90 % Ce document fait le point sur les "Remote Procedure Calls" d\'ecrits dans le manuel "Network Programming Guide" de Sun microsystems (pp 1-129). On s'y r\'ef\'erera pour y puiser les exemples pratiques indispensables pour une meilleure compr\'ehension de pr\'esent document \footnote{$\dag$ Le lecteur connaissant d\'ej\`a les protocoles TCP-UDP/IP et les RPC pourra passer directement au chap\~{\i}tre 3.}$\dag$...\\ \section{G\'en\'eralit\'es :} \subsection{Historique :} La communication entre processus a toujours \'et\'e un point essentiel sous UNIX. Ainsi, jusqu'\`a la version 7 d' UNIX, on n'avait que le {\it pipe} comme seul moyen de communication inter-processus. Mais le {\it pipe} avait ses limites, car pour communiquer, les processus devaient avoir la m\~eme filiation. De plus, l'ex\'ecution des processus devait se faire sur la m\~eme machine.\\ Avec la version System III d' ATT, on a introduit les "tubes nomm\'es" ({\it named pipes}), ce qui a permis la communication entre processus sans filiation. Mais, les processus s'ex\'ecutaient toujours sur la m\~eme machine...\\ L'universit\'e de Berkeley a d\'evelopp\'e parall\`element, une autre version d' UNIX (UNIX BSD), mais orient\'ee r\'eseaux. Avec l'arriv\'ee d' UNIX BSD 4.3, le programmeur a \`a sa disposition des m\'ecanismes puissants : {\it sockets} (comme interface d'acc\`es au r\'eseau), les protocoles TCP-UDP/IP d'Arpanet, les RPC et XDR.\\ De son c\~o\-t\'e, ATT, avec UNIX Sys\-tem V, a d\'e\-ve\-lop\-p\'e une in\-ter\-fa\-ce r\'e\-seau \'e\-qui\-va\-len\-te aux {\it soc\-kets}, les {\it streams}, pour avoir acc\`es aux protocoles Arpanet. Ils ont aussi introduit les m\'ecanismes de {\it zone m\'emoire partag\'ee} ainsi que les {\it s\'emaphores}.\\ Mais, actuellement, les m\'ecanismes offerts par UNIX BSD 4.3 se sont impos\'es comme standard car leur mise en \oe uvre est ais\'ee.\\ % \newpage \begin{center} \begin{tabular}{|c|c|c||c||c|c|c|} \hline \multicolumn{7}{|c|}{}\\ \multicolumn{7}{|c|}{APPLICATION}\\ \multicolumn{7}{|c|}{}\\ \hline \multicolumn{3}{|c}{Socket} & & \multicolumn{3}{c|}{Stream}\\ \hline \multicolumn{3}{|c}{TCP UDP} & & \multicolumn{3}{c|}{Protocole 1}\\ \hline \multicolumn{3}{|c}{IP} & & \multicolumn{3}{c|}{Protocole 2}\\ \hline \multicolumn{3}{|c}{Arpanet Ethernet} & & \multicolumn{3}{c|} {R\'eseau 1 R\'eseau 2} \\ \hline \multicolumn{3}{|c}{} & & \multicolumn{3}{c|}{}\\ \multicolumn{3}{|c}{UNIX BSD 4.3} & & \multicolumn{3}{c|}{UNIX System V}\\ \multicolumn{3}{|c}{} & & \multicolumn{3}{c|}{}\\ \hline \end{tabular} \end{center} % \begin{center} \souligne{Tableau 1}\\ \end{center} \subsection{L'architecture Arpanet :} Dans les ann\'ees 70, le DARPA (Defense Advanced Research Project Agency) a d\'e\-ve\-lop\-p\'e la tech\-no\-lo\-gie In\-ter\-net pour la trans\-mis\-sion par pa\-quets de l'in\-for\-ma\-tion. En 1980, le DARPA a implant\'e TCP/IP sur ses machines qui \'etaient reli\'ees \`a Arpanet (Ar\-pa\-net a \'e\-t\'e d\'e\-ve\-lop\-p\'e par le Department of Defense-USA).\\ L'environnement TCP/IP s'est alors affirm\'e comme un standard.\\ L'universit\'e de Berkeley a ensuite implant\'e TCP/IP sous UNIX BSD pour permettre l'acc\`es au r\'eseau Arpanet. L'architecture Arpanet se d\'ecoupe comme suit :\\ % % \begin{center} \begin{tabular}{|l|l|l|} \hline \multicolumn{1}{|l|}{3} & couche application & telnet, ftp, rlogin...\\ \hline \multicolumn{1}{|l|}{2} & couche transport & TCP/UDP\\ \hline \multicolumn{1}{|l|}{1} & couche r\'eseau & IP\\ \hline \multicolumn{0}{|l|}{0} & couche physique & Arpanet, Ethernet...\\ \hline \end{tabular} \end{center} % \begin{center} \souligne{Tableau 2}\\ \end{center} % % On voit que l'on reste tout de m\~eme en accord avec les couches basses de la norme ISO.\\ \newpage \subsection{Le protocole IP :} Le protocole IP (Internet Protocole) permet de connecter des machines sur des r\'eseaux diff\'erents (Arpanet, Ethernet...). C'est un service sans connexion (chaque datagramme (paquet) est consid\'er\'e individuellement) et non fiable car on n'assure pas l'acheminement vers le destinataire.\\ \subsection{Le protocole UDP :} Le protocole UDP (User Datagram Protocole) se situe au niveau de la couche transport et utilise le service IP pour acheminer les messages. C'est un service sans connexion (orient\'e transaction) et non fiable, mais il est simple \`a mettre en \oe uvre. On a introduit \`a ce niveau la notion de num\'ero de port ({\it port number}) qui permet d'identifier au sein d'une machine, un processus qui utilise ce protocole.\\ UDP est surtout utilis\'e pour des r\'eseaux fiables (faible taux d'erreur) comme%E\-ther\-net. Il est \`a la base d'utilitaires comme {\it tftp} (trivial ftp).\\ \subsection{Le protocole TCP :} Le protocole TCP (Transport Control Protocol) est lui orient\'e connexion et est fiable. \subsection{ RPC et XDR :} Les RPC (Remote Procedure Call) mettent en jeu un ensemble de m\'ecanismes qui permettent l'ex\'ecution de proc\'edures sur une machine distante, ex\'ecution demand\'ee par la machine locale. Les RPC utilisent les protocoles TCP/IP ou UDP/IP. L'interfa\c cage r\'eseau ({\it socket}) est compl\'etement transparent pour le programmeur%! L'utilitaire {\it rpcgen} de Sun permet de mettre en place rapidement un syst\`eme Client (local) /Serveur (local ou distant) RPC.\\ % \noindent XDR (eXternal Data Representation) permet une repr\'esentation des donn\'ees ind\'ependantes machine. De fa\c con g\'en\'erale, les donn\'ees "locales" sont cod\'ees sous format XDR par s\'erialisation, transmises \`a la machine "distante", puis d\'ecod\'ees par d\'es\'erialisation. On s'affranchit ainsi de la contrainte de repr\'esentation des donn\'ees qui reste propre \`a une machine.\\ Les RPC u\-ti\-li\-sent XDR pour la S\'e\-ria\-li\-sa\-tion/D\'e\-s\'e\-ria\-li\-sa\-tion des in\-for\-ma\-tions (don\-n\'ees et r\'e\-sul\-tats).\\ \section{Les RPC :} \subsection{Le mod\`ele RPC :} Comme l'on vient de le voir, les RPC permettent \`a un processus d'une machine locale ("local client machine"), d'ex\'ecuter une proc\'edure sur la machine locale ou sur une machine distante ("local/remote server machine").\\ Les RPC sont bas\'ees sur le mod\`ele Client/Serveur. On distingue le {\it processus client} et le {\it processus serveur} :\\ 1. Le processus client va essayer de rentrer en contact avec le processus serveur en s'adressant au {\it service portmapper} de la machine distante. Quand le {\it portmapper} aura identifi\'e le processus serveur demand\'e, celui-ci renvoie toutes les coordonn\'ees de celui-ci (r\~ole du {\it port number}) pour que le processus client puisse alors s'adresser directement au processus serveur.\\ 2. Le processus client lance la proc\'edure d'appel au processus serveur.\\ 3. Quand la requ\~ete arrive au processus serveur, celui-ci la sert et ex\'ecute la proc\'edure RPC appropri\'ee, puis renvoie les r\'esultats, s'il y en a, au processus client.\\ % \noindent - La proc\'edure d'appel doit contenir les informations n\'ecessaires \`a identifier la proc\'edure RPC que doit ex\'ecuter le processus serveur.\\ - Le processus serveur est en g\'en\'eral endormi ({\it daemon}). Il ne se r\'eveille que pour servir la requ\~ete d'un client RPC. Quand le processus serveur est actif, le processus client est en sommeil jusqu'\`a ce que le processus serveur ait fini de servir la requ\~ete du processus client.\\ - Les donn\'ees \`a transmettre au processus serveur sont sous format XDR. Les r\'esultats transmis au processus client sont aussi sous format XDR.\\ - Le time-out des RPC intervient \`a ce niveau (voir 4.4). Quand il n'y a pas de r\'eponse du serveur au bout d'un certain temps d\'efini par le programmeur lors d'un appel RPC, le processus client redevient actif...\\ \subsection{Le service portmapper :} Un processus client doit \~etre capable d'entrer en contact avec le processus serveur RPC. Pour cela, il faut qu'il connaisse le num\'ero de port ({\it port number}) du serveur de la machine distante.\\ Le service portmapper d'une machine Sun est un service qui permet de fa\c con standard aux clients de conna\~{\i}tre le num\'ero de port d'un serveur.\\ La gestion du service portmapper est assur\'ee par le {\it serveur portmapper} qui est lanc\'e lors du boot de la machine Sun. Un ensemble de serveurs RPC est activ\'e lors de cette phase de boot. On a en particulier le serveur "rusersd" qui est utilis\'e lorque l'on veut conna\~{\i}tre les utilisateurs en session sur tout le r\'eseau local (\% rusers). On retrouve aussi le {\it serveur portmapper} dont le r\~ole est de communiquer le num\'ero de port d'un serveur r\'epertori\'e dans son service portmapper \`a tout client qui en fait la demande. Il faut donc, au pr\'ealable que le serveur RPC que l'on d\'esire installer soit d\'eclar\'e au niveau du service portmapper de la machine distante avant tout appel RPC par un client !\\ \subsection{Reconnaissance d'une proc\'edure RPC :} Un serveur RPC peut avoir \`a g\'erer plusieurs proc\'edures. Pour \~etre distingu\'ee, une proc\'edure est identifi\'ee par un num\'ero de proc\'edure. En plus du num\'ero de port attribu\'e par le service pormapper, le serveur RPC poss\`ede un num\'ero de programme et un num\'ero de version. Pour s'adresser \`a un processus serveur RPC, le processus client doit donc conna\~{\i}tre :\\ - le nom de la machine o\`u est install\'e le serveur (adresses IP).\\ - le num\'ero de port.\\ - le num\'ero de programme.\\ - le num\'ero de version.\\ - le num\'ero de la proc\'edure \`a ex\'ecuter.\\ - le type du protocole \`a employer (TCP ou UDP) avant tout appel RPC.\\ L'ensemble de ces informations est accessible \`a l'utilisateur lorsqu'il rentre la commande :\\ \% rpcinfo -p {\it hostname}\\ \subsection{Choix du protocole :} Le choix du protocole (TCP ou UDP) pour le serveur est laiss\'e au programmeur. N\'eanmoins, UDP ne permet qu'un \'echange de donn\'ees de taille inf\'erieure \`a 8 Ko...\\ \section{Mise en oeuvre des RPC par rpcgen :} \subsection{Le but :} {\it rpcgen} est un outil (compilateur) qui permet de cr\'eer tr\`es rapidement des programmes serveur et client RPC. {\it rpcgen} demande peu de connaissances.\\ \subsection{Le principe :} 1. Le programmeur \'ecrit le fichier de la structure de donn\'ees qui sera utilis\'ee par la proc\'edure RPC (pgr.x) en utilisant le langage RPC ({\it RPC language}) qui reste tr\`es proche du C.\\ 2. Puis, il lance l'utilitaire rpcgen avec comme param\`etre, le fichier pr\'ec\'edent. En retour, un squelette du client (pgr\_clnt.c), un squelette du serveur (pgr\_svc.c), un fichier des donn\'ees sous format XDR (pgr\_xdr.c) et un fichier header contenant les constantes (pgr.h) sont g\'en\'er\'es.\\ 3. Le programmeur \'ecrit en C sa proc\'edure RPC (proc.c) et un fichier qui va permettre de g\'en\'erer le programme serveur et le programme client (client.c).\\ 4. Le programmeur compile client.c avec pgr\_clnt.c et pgr\_xdr.c pour obtenir le programme ex\'ecutable {\it client}.\\ 5. Le programmeur compile proc.c avec pgr\_svc.c et pgr\_xdr.c pour obtenir le programme ex\'ecutable {\it serveur}.\\ 6. Le programme serveur est lanc\'e sur la machine distante (par la commande \%{\it serveur} \&) pr\~et \`a servir une requ\~ete RPC.\\ \subsection{Un exemple d'application :} L'exemple choisi est tir\'e du manuel Sun cit\'e au d\'ebut du document. S'y r\'ef\'erer pour trouver les sources des fichiers cit\'es...\\ % \noindent On d\'esire r\'ealiser un programme client qui imprime \`a l'\'ecran d'une machine distante un message.\\ % \noindent {\bf - Etape 1 :} on cr\'ee le fichier en "langage RPC" {\it msg.x} qui sp\'ecifie la structure de donn\'ees utilis\'ee par les RPC.\\ % % \noindent program MESSAGEPROG \{ \\ \indent version MESSAGEVERS \{ \\ \indent \indent int PRINTMESSAGE (string) = 1;\\ \indent \} = 1;\\ \} = 0x20000000;\\ % % \begin{center} \underline{fichier msg.x}\\ \end{center} % % \noindent Le num\'ero de proc\'edure vaut 1.\\ Le num\'ero de version vaut 1.\\ Le num\'ero de programme vaut 0x20000000 (le num\'ero de programme doit appartenir \`a une plage donn\'ee).\\ La structure de donn\'ees est ici :\\ - une cha\~{\i}ne de caract\`eres (le message \`a afficher) utilis\'ee lors de l'appel RPC.\\ - un entier utilis\'e lors du retour d'appel RPC.\\ % \noindent {\bf - Etape 2 :} on fait appel \`a rpcgen :\\ \% rpcgen {\it msg.x}\\ On r\'ecup\`ere alors les fichiers {\it msg\_clnt.c}, {\it msg\_svc.c}, et {\it msg.h}. Notons qu'ici, on n'a pas de fichier {\it msg\_xdr.c} car la structure de donn\'ees employ\'ee est simple.\\ % \noindent {\bf - Etape 3 :} il faut ensuite \'ecrire la proc\'edure RPC {\it msg\_proc.c} et le programme C {\it rprintmsg.c} qui va permettre de "lier" le tout.\\ % \noindent {\bf - Etape 4 :} on g\'en\`ere le programme client :\\ \% cc {\it rprintmsg.c msg\_clnt.c} -o {\it msg\_client}\\ % \noindent {\bf - Etape 5 :} on g\'en\`ere le programme serveur :\\ \% cc {\it msg\_proc.c msg\_svc.c} -o {\it msg\_server}\\ % \noindent {\bf - Etape 6 :} on lance le programme serveur sur la ma\-chi\-ne dis\-tan\-te%:\\ \% rlogin {\it remote\_hostname}\\ \% {\it msg\_server} \& \\ % \noindent Il ne reste plus qu'\`a utiliser le programme client si l'on d\'esire imprimer un message \`a l'\'ecran de la machine distante...\\ \subsection{Quelques remarques :} - Il faudra rajouter lors de la g\'en\'eration des programmes client et serveur le fichier {\it pgr\_xdr.c} si n\'ecessaire.\\ - Pour la proc\'edure RPC, on n'utilise que des pointeurs sur les donn\'ees et sur les r\'esultats.\\ - Le nom de la proc\'edure est en majuscules suivi du num\'ero de proc\'edure (ex : PRINTMESSAGE\_1, le num\'ero de version \'etant ici 1).\\ - Le langage RPC fait appel \`a XDR. Pour plus d'informations sur XDR, voir plus loin...\\ \section{Les RPC : programmation avanc\'ee :} \subsection{Pr\'esentation :} Nous venons de voir que {\it rpcgen} permettait de mettre en place des programmes serveur et client de fa\c con syst\'ematique. Remarquons que l'on n'avait aucun moyen d'agir sur les mod\`eles du squelette du serveur et du client g\'en\'er\'es par {\it rpcgen}. Nous allons montrer qu'il est possible de se b\~atir ses propres programmes serveur et client.\\ On distingue trois niveaux dans la programmation des RPC :\\ - {\it la couche haute} : elle est totalement transparente \`a l'utilisateur.\\ - {\it la couche moyenne} : elle permet de construire des applications de couche haute.\\ - {\it la couche basse} : elle permet de choisir le protocole de transport, le temps de time-out des RPC...\\ \subsection{La couche haute de RPC :} C'est en fait un ensemble de routines offertes \`a l'utilisateur. L'aspect RPC lui est totalement masqu\'e.\\ Sur Sun, les services offerts sont divers :\\ - rusers() : permet d'avoir des informations sur les utilisateurs en session sur le r\'eseau.\\ - havedisk() : permet de savoir si une machine du r\'eseau poss\`ede un disque dur.\\ - yppasswd() : met \`a jour le mot de passe d'un utilisateur si les Yellow Pages sont utilis\'ees pour l'administration du r\'eseau.\\ - ...\\ % \noindent Ces routines sont archiv\'ees sous /usr/lib/librpcsvc.a .\\ \subsection{La couche moyenne de RPC :} Dans cette couche, on a \`a \'ecrire le programme serveur et le programme client. Cette couche permet de cr\'eer des services de la couche de haut niveau.\\ % \noindent Reprenons l'exemple la routine rusers() (la commande Sun \% rusers utilise la routine rusers() ). En tapant la commande :\\ \% rpcinfo -p {\it hostname},\\ on a vu qu'il existait un serveur s'appelant ruserd.\\ En fait, le serveur de couche moyenne est ruserd. Pour construire le programme client (seule chose qu'il y aurait \`a faire mais qui est d\'ej\`a r\'ealis\'ee), on utilise les informations se trouvant sous /usr/include/rpcsvc/ . Le r\'esultat de tout cela est bien s\~ur la routine de couche haute rusers()%!\\ % \noindent Si l'on veut maintenant cr\'eer notre propre serveur et notre propre client, on a \`a disposition 3 outils de base :\\ {\bf - callrpc()} : cette routine permet, c\~ot\'e client, de faire des appels RPC au serveur.\\ {\bf - registerrpc()} : cette routine permet, c\~ot\'e serveur, d'initialiser le serveur. En fait, on d\'eclare le serveur au service portmapper (affectation d'un num\'ero de port) et on cr\'ee l'interfa\c cage r\'eseau (socket).\\ {\bf - svc\_run()} : cette routine permet, c\~ot\'e serveur, d'attendre un appel RPC, transmet la demande \`a la proc\'edure RPC, renvoie les r\'esultats au client s'il y en a, puis recommence \`a attendre un appel RPC.\\ % % \noindent \underline{Remarques :}\\ \noindent On doit pr\'eciser dans l'appel callrpc() les structures XDR (filtres) \`a utiliser pour l'acheminement des donn\'ees et des r\'esultats. On doit aussi donner en param\`etres un pointeur sur la structure de donn\'ees utilis\'ee pour les donn\'ees (pour l'initialisation de l'appel RPC) et un pointeur sur la structure de donn\'ees utilis\'ee pour les r\'esultats (pour le traitement de ceux-ci apr\`es le retour d'appel).\\ On a juste \`a \'ecrire la proc\'edure RPC et les structures XDR pour les donn\'ees et les r\'esultats.\\ On peut se servir de {\it rpcgen} pour obtenir les structures XDR (fichier pgr\_xdr.c).\\ On n'a pas le choix du protocole, qui est ici UDP/IP.\\ On trouvera des exemples dans le manuel Sun.\\ \subsection{La couche basse de RPC :} C'est \`a ce niveau que l'on peut contr\~oler les RPC.\\ On peut choisir le protocole \`a employer (TCP/IP ou UDP/IP). TCP/IP permet d'avoir des \'echanges de donn\'ees sup\'erieure \`a 8 Ko.\\ {\it On peut changer le time-out des appels RPC} (fix\'e par d\'efaut \`a 30 secondes).\\ On peut installer un syst\`eme de reconnaissance des appels (qui est le client ?) et donc permettre un aiguillage au niveau des proc\'edures RPC suivant le client.\\ {\it rpcgen} g\'en\`ere des squelettes appartenant \`a la basse couche de RPC.\\ On trouvera l\`a aussi des exemples dans le manuel Sun.\\ \subsection{Autres types de RPC :} \subsubsection{Les "Raw RPC" :} Ce type de RPC n'est utilis\'e que pour la phase de d\'eveloppement d'un syst\`eme Client/Serveur RPC. Par rapport \`a la couche basse de RPC, on n'enregistre pas le serveur au niveau du service portmapper. On n'a pas acc\`es aux param\`etres de contr\~ole des appels RPC.\\ \subsubsection{ les "Broadcast RPC" :} Cela permet, entre autre, de rechercher des informations en s'adressant \`a {\bf \souligne tous} les serveurs des machines connect\'ees sur le r\'eseau.\\ Pour s'adresser juste \`a un ensemble de serveurs, il faut donc cr\'eer une interface suppl\'ementaire ("serveur de serveurs").\\ Les "broadcast RPC" n'utilisent qu' UDP/IP.\\ \section{La repr\'esentation de donn\'ees XDR :} \subsection{Rappels :} XDR (eXternal Data Representation) est un ensemble de routines qui permet de repr\'esenter des structures de donn\'ees ne d\'ependant pas de la repr\'esentation interne de celles-ci d'une machine. XDR permet donc l'\'echange d'informations entre machines h\'et\'erog\`enes. Pour aller plus loin, on peut dire que XDR r\`egle les probl\`emes de portabilit\'e de donn\'ees et peut \~etre utilis\'ee dans n'importe quel programme%!\\ La repr\'esentation XDR est utilis\'ee par les RPC.\\ % \noindent Pour utiliser XDR, il faut inclure dans les fichiers :\\ \#include $<$rpc/rpc.h$>$\\ \subsection{La biblioth\`eque XDR :} Les routines XDR sont de la forme :\\ % % \noindent xdr\_{\it xxx}(xdrs, xp)\\ \indent XDR *xdrs ;\\ \indent {\it xxx} *xp ;\\ \{ \\ ...\\ \}\\ % \noindent Voici un exemple de structure XDR pour un entier long :\\ % \noindent xdr\_long(xdrs, xp)\\ \indent XDR *xdrs ;\\ \indent long *xp ;\\ % % \noindent On u\-ti\-li\-se la m\~e\-me struc\-tu\-re aus\-si bien pour la s\'e\-ria\-li\-sa\-tion que pour la d\'e\-s\'e\-ria\-li\-sa\-tion.\\ On utilise toujours, comme on l'a d\'ej\`a vu des pointeurs sur les objets et non les objets eux-m\~eme.\\ On trouvera de nombreux exemples dans le manuel Sun...\\ \section{Conclusion :} La mise en place de RPC Sun est relativement simple mais cela n\'ecessite une bonne compr\'ehension des m\'ecanismes de base d\'ecrits dans ce document. Il est tout aussi important de "se faire la main" en mettant en place de petites applications. Le manuel "Networks Programming Guide" de Sun vous sera pour cela tr\`es utile...\\ Signalons enfin que les RPC Sun sont reconnus de tous. Wind River les a implant\'es dans son produit Temps R\'eel VxWorks (compatibilit\'e compl\`ete). On peut maintenant installer un serveur RPC Temps R\'eel sous VxWorks alors que le client RPC est install\'e sous Sun (non Temps R\'eel). Un nouvel horizon s'est ainsi ouvert pour le programmeur...\\ \end{document}