UNIDAD V

Unidad 5 5.1 Introduccion 

Que es un Procedimiento? En el ámbito de la programación, un procedimiento es un tipo sub algoritmo, es el término para describir una secuencia de órdenes que hacen una tarea específica de una aplicación más grande. 

Las declaraciones de procedimientos generalmente son especificadas por: 

Un nombre único en el ámbito.- Nombre del procedimiento con el que se identifica y se distingue de otros. No podrá haber otro procedimiento ni función con ese nombre (salvo sobrecarga o polimorfismo en programación orientada a objetos). Una lista de parámetros.

- Especificación del conjunto de argumentos (pueden ser cero, uno o más) que el procedimiento debe recibir para realizar su tarea. El código u órdenes de procesamiento.

- Conjunto de órdenes y sentencias que debe ejecutar el procedimiento. La diferencia entre un procedimiento y una función (el otro tipo de sub algoritmos) radica en que estos últimos devuelven un resultado. Los procedimientos en programación generalmente son los que realizan operaciones de entrada/salida, en general, cualquier operación más o menos compleja que no requiera devolver un valor. 

Que es un Cliente? El cliente es una aplicación informática que se utiliza para acceder a los servicios que ofrece un servidor, normalmente a través de una red de telecomunicaciones. El término se usó inicialmente para los llamados terminales tontos, dispositivos que no eran capaces de ejecutar programas por sí mismos, pero podían conectarse a un ordenador central y dejar que éste realizase todas las operaciones requeridas, mostrando luego los resultados al usuario. Se utilizaban sobre todo porque su coste en esos momentos era mucho menor que el de un ordenador. 

Actualmente se suelen utilizar para referirse a programas que requieren específicamente una conexión a otro programa, al que se denomina servidor y que suele estar en otra máquina. Ya no se utilizan por criterios de coste, sino para obtener datos externos (por ejemplo páginas web, información bursatil o bases de datos), interactuar con otros usuarios a través de un gestor central (como por ejemplo los protocolos bittorrent o IRC), compartir información con otros usuarios (servidores de archivos y otras aplicaciones Groupware) o utilizar recursos de los que no se dispone en la máquina local (por ejemplo impresión) Uno de los clientes más utilizados, sobre todo por su versatilidad, es el navegador web. Muchos servidores son capaces de ofrecer sus servicios a través de un navegador web en lugar de requerir la instalación de un programa específico. 

Que es un Servidor? En informática, un servidor es una computadora que, formando parte de una red, provee servicios a otras denominadas clientes. También se suele denominar con la palabra servidor a: Una aplicación informática o programa que realiza algunas tareas en beneficio de otras aplicaciones llamadas clientes. Algunos servicios habituales son los servicios de archivos, que permiten a los usuarios almacenar y acceder a los archivos de una computadora y los servicios de aplicaciones, que realizan tareas en beneficio directo del usuario final. Este es el significado original del término. Es posible que un ordenador cumpla simultáneamente las funciones de cliente y de servidor. Una computadora en la que se ejecuta un programa que realiza alguna tarea en beneficio de otras aplicaciones llamadas clientes, tanto si se trata de un ordenador central (mainframe), un miniordenador, un ordenador personal, una PDA o un sistema integrado; sin embargo, hay computadoras destinadas únicamente a proveer los servicios de estos programas: estos son los servidores por antonomasia. Ejemplo de un Servidor. 

Un servidor no es necesariamente una máquina de última generación grande y monstruosa, no es necesariamente un superordenador; un servidor puede ser desde una computadora vieja, hasta una máquina sumamente potente (ej.: servidores web, bases de datos grandes, etc. Procesadores especiales y hasta varios gigas de memoria). Todo esto depende del uso que se le dé al servidor. Si usted lo desea, puede convertir al equipo desde el cual usted está leyendo ésto en un servidor instalando un programa que trabaje por la red y a la que los usuarios de su red ingresen a través de un programa de servidor web como Apache. A lo cual podemos llegar a la conclusión de que un servidor también puede ser un proceso que entrega información o sirve a otro proceso, el modelo cliente/servidor no necesariamente implica tener dos ordenadores, ya que un proceso cliente puede solicitar algo como una impresión a un proceso servidor en un mismo ordenador. 

5.2 Llamadas a procedimientos remotes 

Llamados también RPC(Remote Procedures Call) inventados por Birrel y Nelson en 1984 no es más que el procedimiento en el que una maquina recurre a programas o aplicaciones situados en otra máquina que se encuentra a distancia, este proceso es fácil consta de lo siguiente: Maquina Cliente pide servicio a Servidor Maquina Servidor valida el servicio y envía respuesta Ambas maquinas se relacionan mediante protocolos. Maquina servidor envía servicios a máquina Cliente. 

5.3 Eventos y notificaciones 

En la programación existe la programación orientada a eventos, en la que un evento es un mensaje de software que indica que algo ha ocurrido, como un tecleo o un click de un mouse. En el control de procesos, un evento es una ocurrencia que ha ocurrido y que ha sido registrado. Llamada a Procedimiento Remoto El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una colección de herramientas y funciones de biblioteca. Aplicaciones importantes construidas sobre RPC son NIS, Sistema de Información de Red[1] (descrito en Capítulo 13), y NFS, Sistema de Ficheros de Red[2] (descrito en Capítulo 14), ambos se describen en este libro. 

Un servidor RPC consiste en una colección de procedimientos que un cliente puede solicitar por el envío de una petición RPC al servidor junto con los parámetros del procedimiento. El servidor invocará el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation [3] (XDR) por el emisor, y son reconvertidos a la representación local por el receptor. RPC confía en sockets estandard UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio público; se describe en una serie de RFCs. A veces las mejoras en una aplicación RPC introducen cambios incompatibles con la interfaz de llamada a procedimientos. Por supuesto, simplemente cambiando el servidor hará que no funcionen todas las aplicaciones que todavía esperen el comportamiento original. Por lo tanto, los programas RPC tienen números de versión asignados, casi siempre empezando por 1, y con cada nueva versión de la interfaz RPC, este contador se incrementa. A menudo, un servidor puede ofrecer varias versiones simultáneamente; entonces los clientes indican a través del número de versión en la petición que implementación del servicio quieren usar. 

La comunicación entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o más colecciones de procedimientos; cada conjunto se llama un programa y es idenficado de forma única por un número de programa. Una lista que relaciona nombres de servicio con números de programa se mantiene usualmente en /etc/rpc, un extracto del cual se ve en Ejemplo 12-4. Ejemplo 12-4. Una muestra de fichero /etc/rpc # # /etc/rpc - servición miscaláneos basados en RPC # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate En redes TCP/IP , los autores de RPC se enfrentan al problema del mapeo de números de programa con servicios genéricos de red. Diseñaron cada servidor para proveer ambos puertos TCP y UDP para cada programa y cada versión. Generalmente, las aplicaciones RPC usan UDP cuando envían datos, y vuelven a TCP sólo cuando los datos a transferir no caben en un solo datagrama UDP. Por supuesto, los programas cliente necesitan averiguar a qué puerto se refiere un número de programa. Usar un fichero de configuración para esto podría ser demasiado inflexible; debido a que las aplicaciones RPC no usan puertos reservados, no hay garantía de que un puerto originalmente usado por nuestra aplicación de base de datos, no haya sido tomado por cualquier otro proceso. 

Por lo tanto, las aplicaciones RPC toman cualquier puerto que puedan obtener y lo registran con un programa especial llamado el demonio portmapper. El mapeador de puertos actúa como un intermediario para todos los servidores RPC ejecutándose en su máquina. Un cliente que desea contactar con un servicio con un número de programa dado primero pregunta al mapeador de puertos en el host del servidor, el cuál devuelve el número de puerto TCP y UDP en donde el servicio puede ser alcanzado. Este método introduce un solo punto de fallo, similar a como el demonio inetd hace para los servicios estándar de Berkeley. Sin embargo, este caso es aún un poco peor porque cuando el mapeador de puertos muere, toda la información de los puertos RPC se pierde; esto a menudo significa que debe reiniciar todos los servidores RPC manualmente o reiniciar la máquina. En Linux, el mapeador de puertos se llama /sbin/portmap, o a veces /usr/sbin/rpc.portmap. Una vez que se cerciora de que se inicia desde sus guiones de inicio de red, el mapeador de puertos no requiere ninguna configuración.