INTRODUCCIN------------------------------------------------------------------------------------------------------ 3 PLANTEAMIENTO -------------------------------------------------------------------------------------------------------------3 JUSTIFICACIN ----------------------------------------------------------------------------------------------------------------3 OBJETIVOS GENERALES DEL SISTEMA ------------------------------------------------------------------------------------4 OBJETIVOS ESPECFICOS DEL SISTEMA -----------------------------------------------------------------------------------4

METODOLOGA ----------------------------------------------------------------------------------------------------------------4 CAPTULO I. ARQUITECTURA CLIENTE / SERVIDOR -------------------------------------------------- 6 1.1. ANTECEDENTES ---------------------------------------------------------------------------------------------------------6 1.2. CLIENTE / SERVIDOR ---------------------------------------------------------------------------------------------------6 1.3. COMPONENTES ESENCIALES DE LA INFRAESTRUCTURA CLIENTE/SERVIDOR -------------------------------8 1.4. DESCRIPCIN DE LAS DIFERENTES VARIANTES DE LA ARQUITECTURA CLIENTE / SERVIDOR -----------9 1.4.1. Presentacin Distribuida.---------------------------------------------------------------------------------- 9 1.4.2. Administracin de Datos Remota. ------------------------------------------------------------------------ 9 1.4.3. Internet ----------------------------------------------------------------------------------------------------- 10 CAPTULO II. INTRODUCCIN A TCP/IP ------------------------------------------------------------------ 12 2.1. REDES Y TCP/IP: ------------------------------------------------------------------------------------------------------ 12 2.2. DEFINICIN DEL CONJUNTO DE PROTOCOLOS TCP/IP: -------------------------------------------------------- 13 2.3. MODELO CLIENTE-SERVIDOR: ------------------------------------------------------------------------------------- 14 2.3.1. Interfaz del programa a protocolos--------------------------------------------------------------------- 15 2.4. TCP /IP Y COMUNICACIONES ENTRE REDES --------------------------------------------------------------------- 15 2.5. PROTOCOLO IP--------------------------------------------------------------------------------------------------------- 16 2.5.1. La estructura de direcciones IP ------------------------------------------------------------------------- 16 CAPTULO III. EL PROTOCOLO HTTP --------------------------------------------------------------------- 22 3.1. INTRODUCCIN -------------------------------------------------------------------------------------------------------- 22 3.2. PROPIEDADES DE HTTP --------------------------------------------------------------------------------------------- 22 3.3. CARACTERSTICAS DEL PROTOCOLO HTTP ----------------------------------------------------------------------- 24 3.4. MTODOS HTTP -------------------------------------------------------------------------------------------------------- 24 3.5. LAS CABECERAS ------------------------------------------------------------------------------------------------------- 25 3.5.1. Cabeceras comunes para peticiones y respuestas ---------------------------------------------------- 25 3.5.2. Cabeceras slo para peticiones del cliente ------------------------------------------------------------ 26 3.5.3. Cabeceras slo para respuestas del servidor HTTP-------------------------------------------------- 26 3.5.4. Otras cabeceras ------------------------------------------------------------------------------------------- 27 3.6. ETAPAS DE UNA TRANSACCIN HTTP ---------------------------------------------------------------------------- 27 3.7. CDIGOS DE ESTADO DEL SERVIDOR ------------------------------------------------------------------------------ 28 3.8. CACHS DE PGINAS Y SERVIDORES PROXY --------------------------------------------------------------------- 29 CAPTULO IV. BREVE DESCRIPCIN DE LAS CLASES UTILIZADAS ---------------------------- 30 4.1. LA CLASE TLIST ------------------------------------------------------------------------------------------------------- 30 4.1.1. Propiedades------------------------------------------------------------------------------------------------ 30 4.1.2. Mtodos ---------------------------------------------------------------------------------------------------- 31 4.2. LA CLASE TSTRINGLIST ---------------------------------------------------------------------------------------------- 35 4.2.1. Propiedades------------------------------------------------------------------------------------------------ 35 4.2.2. Mtodos ---------------------------------------------------------------------------------------------------- 37 4.3. LA CLASE TSERVERSOCKET ---------------------------------------------------------------------------------------- 38 4.3.1. Propiedades------------------------------------------------------------------------------------------------ 39 4.3.2. Mtodos ---------------------------------------------------------------------------------------------------- 40 4.3.3. Eventos ----------------------------------------------------------------------------------------------------- 41 CAPTULO V. DISEO -------------------------------------------------------------------------------------------- 42 1

5.1. ESPECIFICACIN Y REQUISITOS GENERALES. -------------------------------------------------------------------- 42 5.2. DESCRIPCIN DE LAS TAREAS DEL SISTEMA --------------------------------------------------------------------- 43 5.3. DETALLES DEL DISEO ----------------------------------------------------------------------------------------------- 44 CAPTULO VI. IMPLEMENTACIN DEL SISTEMA ----------------------------------------------------- 47 6.1. DELPHI COMO HERRAMIENTA DE DESARROLLO. ---------------------------------------------------------------- 47 6.2. DELPHI E INTERNET. -------------------------------------------------------------------------------------------------- 48 6.3. CREACIN DEL SISTEMA SERVERCPC ---------------------------------------------------------------------------- 49 6.3.1. Registro y conteo de peticiones.------------------------------------------------------------------------- 50 6.3.2. Subsistema de respaldo de la lista de recursos visitados. ------------------------------------------- 51 6.4. PRUEBAS REALIZADAS AL SISTEMA.------------------------------------------------------------------------------- 52 CONCLUSIONES, LIMITACIONES Y PERSPECTIVAS-------------------------------------------------- 53 CONCLUSIONES.------------------------------------------------------------------------------------------------------------- 53 LIMITACIONES. -------------------------------------------------------------------------------------------------------------- 53 PERSPECTIVAS -------------------------------------------------------------------------------------------------------------- 53 GLOSARIO------------------------------------------------------------------------------------------------------------ 55 BIBLIOGRAFA. ---------------------------------------------------------------------------------------------------- 56

Introduccin
Planteamiento
Para este trabajo de tesis se pretende la realizacin de un sistema servidor de pginas y recursos web basados en el protocolo estndar HTTP con conexin sobre TCP/IP. El cual deber tener las siguientes particularidades: El manejo de un disco virtual en la memoria RAM de la mquina servidor, el cual servir para almacenar una copia de los recursos mayormente solicitados por los clientes. Se podr definir cuales recursos se almacenan en el disco virtual basndose en un rating de los recursos que contiene el servidor. La actualizacin del disco virtual deber hacerse automticamente cada cierto periodo de tiempo.

Con esto se pretende reducir los tiempos de acceso a los recursos del servidor y por lo tanto reducir el tiempo que una conexin permanece activa, reduciendo por ende la carga de flujos de la red, debido a la latencia de acceso al disco.

Justificacin
La expansin que ha tenido Internet en nuestros das conlleva consigo grandes problemas en lo que se refiere en hacer ms veloz el acceso a los recursos, ocupando el menor tiempo posible los dispositivos de comunicacin, es decir acelerar la localizacin y despacho de los recursos solicitados en la red. Para atacar esto se han realizado diferentes propuestas en ambos lados del problema, es decir del lado del cliente y del lado del servidor: Desde el punto de vista de los programas cliente de Internet o navegadores web se implement la utilizacin de un directorio de almacenamiento (con las propiedades de un cach), en el cual se guardan por cierto tiempo todas las pginas que han sido visitadas por el navegador, as cada vez que el navegador visita un recurso del sitio, comprueba a travs del comando HEAD/HTTP, la fecha de la ltima modificacin del mismo si este se encuentra en su cach. En caso de que se detecte un cambio o actualizacin, el cliente acceder, ahora a travs de un GET/HTTP, a recoger la nueva versin del archivo. Del lado de los servidores, se recre el concepto de servidor proxy. Este tipo de servidor, una mezcla entre servidor HTTP y cliente Web, realiza las funciones de cach de pginas para un gran nmero de clientes. Todos los clientes conectados a un proxy dejan que ste sea el encargado de recoger las URLs solicitadas. De esta forma, en caso de que varios clientes accedan a la misma pgina, el servidor proxy la podr proporcionar con un nico acceso a la informacin original. La principal ventaja de ambos sistemas es la drstica reduccin de conexiones a Internet necesarias, en caso de que los clientes accedan a un conjunto similar de pginas, como suele ocurrir con mucha frecuencia. Adems, determinadas organizaciones limitan, por motivos de seguridad, los accesos desde su organizacin al exterior y viceversa. Para ello, se dispone de sistemas denominados "cortafuegos" (firewalls), que son los nicos habilitados para conectarse con el exterior. En este caso, el uso de un servidor proxy se vuelve indispensable. En determinadas situaciones, el almacenamiento de pginas en un cach o en un proxy puede hacer que se mantengan copias no actualizadas de la informacin, como por ejemplo en el caso de trabajar con

documentos generados dinmicamente. Para estas situaciones, los servidores HTTP pueden informar a los clientes de la expiracin del documento, o de la imposibilidad de ser almacenado en un cach, utilizando la variable Expires en la respuesta del servidor. En este trabajo se pretende preparar una respuesta ptima para cuando las soluciones anteriores fallen, es decir cuando no se tienen los recursos solicitados dentro del cach del navegador o el cach del proxy, tratando de que el despacho de los recursos de manera expedita y as consumir menor tiempo en la conexin, para esto se realizar la creacin de un servidor web que tenga un cach en memoria, en el que se almacenarn los recursos mas solicitados del mismo, optimizando de esta forma el despacho de los mismos.

Objetivos generales del sistema

La creacin de un servidor de recursos web que mantenga almacenada la informacin de manera eficiente en base a un rating, para que los recursos que produzcan mayor carga de trabajo en el servidor sean reubicados a una zona alternativa y se optimice su despacho. Creacin de una interfaz y un subsistema de apoyo para la personalizacin de los servicios bsicos del servidor como son: o Tamao de la cola de espera del servidor. o Tamao del disco virtual (cach) o Definicin y mantenimiento del rating Tiempo en el que se debe actualizar el cach.

Objetivos especficos del sistema

La programacin de un servidor de pginas web que resuelva de manera eficiente la reduccin en el tiempo de despacho de las mismas. El estudio del concepto rating para que el sistema sea capaz de manejar de forma eficiente la cantidad de informacin que debe guardarse en el cach. El estudio de las diferentes formas de implementacin de servidores web para decidir cual es la que mejor se adapta a la resolucin de este problema en especfico.

Metodologa
Para la realizacin de este sistema se deber cumplir con todos los pasos que se enlistan a continuacin: Estudio del concepto cliente servidor. Estudio de las metodologas de programacin de aplicaciones cliente servidor Estudio del protocolo de comunicacin HTTP. Estudio del protocolo TCP-IP Creacin del sistema.

La tesis que se presenta consta de 6 captulos, en donde: En el captulo 1, se presenta una introduccin a los conceptos de la arquitectura cliente / servidor. En el captulo 2, se discute el protocolo de red TCP/IP su relacin con el modelo cliente / servidor y la estructura de las direcciones IP. En el captulo 3, se desarrolla una discusin a cerca del protocolo http, sus propiedades, caractersticas, mtodos, cabeceras de peticin y respuesta que utiliza, las etapas de las transiciones http y los cdigos de estado del protocolo. En el captulo 4, se definen las clases base en las que se apoya la creacin del sistema propuesto. En el captulo 5, Se desarrolla el diseo del sistema. En el captulo 6 se habla acerca de la herramienta que se ocupo para el diseo, se describen las principales estructuras del sistema y se discuten las pruebas realizadas al mismo. Existe adems la parte de las conclusiones, limitaciones y perspectivas del sistema. Tambin se cuenta como anexo un glosario con los trminos ms utilizados en el desarrollo de este documento.

Captulo I. Arquitectura Cliente / Servidor

1.1. Antecedentes
Los ordenadores personales y los paquetes de software de aplicaciones proliferan comercialmente. Estos ordenadores, tambin conocidos como estaciones de trabajo programables, estn conectados a las Redes de rea Local (LAN), mediante las cuales, los grupos de usuarios y profesionales comparten aplicaciones y datos. Las nuevas tecnologas de distribucin de funciones y datos en una red, permiten desarrollar aplicaciones distribuidas de una manera transparente, de forma que mltiples procesadores de diferentes tipos (ordenadores personales de gama baja, media y alta, estaciones de trabajo, minicomputadoras o incluso mainframes), puedan ejecutar partes distintas de una aplicacin. Si las funciones de la aplicacin estn diseadas adecuadamente, se pueden mover de un procesador a otro sin modificaciones, y sin necesidad de retocar los programas que las invocan. Si se elige una adecuada infraestructura de sistemas distribuidos y de herramientas de desarrollo, las aplicaciones resultantes podrn trasladarse entre plataformas de distintos proveedores. Los primeros trabajos conocidos para la arquitectura Cliente / Servidor los hizo la empresa Sybase, que se fund en 1984 pensando en lanzar al mercado nicamente productos para esta arquitectura. A fines de la dcada pasada el producto fue lanzado para el voluminoso segmento "low-end" del mercado, en conjuncin con Microsoft, teniendo como soporte de la base de datos un servidor OS/2, y como herramienta "front end" bsica a DBase IV de Ashton Tate. El DBase IV no se mostr como una herramienta adecuada, y los desencuentros comerciales entre Sybase, Microsoft e IBM (en aquel momento socia de Microsoft para el OS/2) hicieron el resto. La situacin era muy diferente en 1994, cuando los principales fabricantes tradicionales (Informix, Oracle y Sybase) haban lanzado al mercado poderosos servidores y, a ellos, se agregaba IBM que estaba lanzando su producto DB2 para, prcticamente, todos los sistemas operativos importantes (adems de sus clsicos MVS y VM, ahora anunciaba AIX, OS/2,Windows NT, Hewlett Packard's UNIX, Suns UNIX, Siemens' UNIX, etc.) y Microsoft que, luego de finalizar su acuerdo con Sybase, parti para su propio SQL Server para Windows NT. Exista un conjunto de lenguajes "front end" como, por ejemplo, Delphi, Foxpro, Powerbuilder, SQL Windows, Visual Basic, etc. Decamos en aquel momento que Visual Basic, ms all de sus mritos intrnsecos como lenguaje, era el favorito para dominar el mercado, cosa que est ocurriendo en algunos entornos. En general, la tecnologa de los servidores de base de datos ha evolucionado mucho en los ltimos aos y todos los fabricantes trabajan con tecnologa sensiblemente equivalente. Parecen, mucho ms importantes para la eleccin, elementos que estn fuera de la tecnologa: la confianza que nos despierta el fabricante, su compromiso con el producto, su tendencia a mantenerse siempre actualizado, su situacin econmico / financiera, las garantas que nos brinde el soporte local y, en menor medida, el precio.

1.2. Cliente / Servidor

El concepto de Cliente / Servidor proporciona una forma eficiente de utilizar todos estos recursos, de tal forma que la seguridad y fiabilidad que proporcionan los entornos mainframe se traspasa a la red de rea local. A esto hay que aadir la ventaja de la potencia y simplicidad de los ordenadores personales.

La arquitectura cliente / servidor es un modelo para el desarrollo de sistemas de informacin, en el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos. Se denomina cliente al proceso que inicia el dilogo o solicita los recursos y servidor, al proceso que responde a las solicitudes. Este es el modelo de interaccin ms comn entre aplicaciones en una red. Y no forma parte de los conceptos de la Internet como los protocolos IP, TCP o UDP, sin embargo todos los servicios estndares de alto nivel propuestos en Internet funcionan segn este modelo. Los principales componentes del esquema cliente / servidor son entonces los Clientes, los Servidores y la infraestructura de comunicaciones. En este modelo, las aplicaciones se dividen de forma tal que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece slo lo particular de cada usuario. Los Clientes interactan con el usuario, usualmente en forma grfica. Frecuentemente se comunican con procesos auxiliares que se encargan de establecer conexin con el servidor, enviar el pedido, recibir la respuesta, manejar las fallas y realizar actividades de sincronizacin y de seguridad. Los clientes realizan generalmente funciones como: Manejo de la interfase del usuario. Captura y validacin de los datos de entrada. Generacin de consultas e informes sobre las bases de datos.

Los Servidores proporcionan un servicio al cliente y devuelven los resultados. En algunos casos existen procesos auxiliares que se encargan de recibir las solicitudes del cliente, verificar la proteccin, activar un proceso servidor para satisfacer el pedido, recibir su respuesta y enviarla al cliente. Adems, deben manejar los interbloqueos, la recuperacin ante fallas, y otros aspectos afines. Por las razones anteriores, la plataforma computacional asociada con los servidores es ms poderosa que la de los clientes. Por esta razn se utilizan PCs poderosas, estaciones de trabajo, minicomputadoras o sistemas grandes. Adems deben manejar servicios como administracin de la red, mensajes, control y administracin de la entrada al sistema ("login"), auditoria y recuperacin, y contabilidad. Usualmente en los servidores existe algn tipo de servicio de bases de datos. En ciertas circunstancias, este trmino designar a una mquina. Este ser el caso si dicha mquina est dedicada a un servicio particular, por ejemplo: servidores de impresin, servidor de archivos, servidor de correo electrnico, etc. Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin de perifricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa.

Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y ste, le responde proporcionndolo. Normalmente, pero no necesariamente, el cliente y el servidor estn ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores personales y / o estaciones de trabajo y los servidores en procesadores departamentales o de grupo. Para que los clientes y los servidores puedan comunicarse se requiere una infraestructura de comunicaciones, la cual proporciona los mecanismos bsicos de direccionamiento y transporte. La mayora de los sistemas Cliente / Servidor actuales, se basan en redes locales y por lo tanto utilizan protocolos no orientados a conexin, lo cual implica que las aplicaciones deben hacer las verificaciones. La red debe tener caractersticas adecuadas de desempeo, confiabilidad, transparencia y administracin. Entre las principales caractersticas de la arquitectura cliente / servidor, se pueden destacar las siguientes: 7

El servidor presenta a todos sus clientes una interfase nica y bien definida. El cliente no necesita conocer la lgica del servidor, slo su interfase externa. El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el que se encuentra, ni de su sistema operativo. Los cambios en el servidor implican pocos o ningn cambio en el cliente.

Como ejemplos de clientes, pueden citarse interfaces de usuario para enviar comandos a un servidor, APIs para el desarrollo de aplicaciones distribuidas, herramientas en el cliente para hacer acceso a servidores remotos (por ejemplo, servidores de SQL) o aplicaciones que solicitan acceso a servidores para algunos servicios. Como ejemplos de servidores pueden citarse servidores de ventanas como X-Windows, servidores de archivos como NFS, servidores para el manejo de bases de datos (como los servidores de SQL), servidores de diseo y manufactura asistidos por computador, etc.

1.3. Componentes esenciales de la infraestructura Cliente/Servidor

Una infraestructura Cliente / Servidor consta de tres componentes esenciales, todos ellos de igual importancia y estrechamente ligados: Plataforma Operativa. La plataforma deber soportar todos los modelos de distribucin Cliente / Servidor, todos los servicios de comunicacin, y deber utilizar, preferentemente, componentes estndar de la industria para los servicios de distribucin. Los desarrollos propios deben coexistir con las aplicaciones estndar y su integracin deber ser imperceptible para el usuario. Igualmente, podrn acomodarse programas escritos utilizando diferentes tecnologas y herramientas. Entorno de Desarrollo de Aplicaciones. Debe elegirse despus de la plataforma operativa. Aunque es conveniente evitar la proliferacin de herramientas de desarrollo, se garantizar que el enlace entre stas y el middleware no sea excesivamente rgido. Ser posible utilizar diferentes herramientas para desarrollar partes de una aplicacin. Un entorno de aplicacin incremental, debe posibilitar la coexistencia de procesos cliente y servidor desarrollados con distintos lenguajes de programacin y/o herramientas, as como utilizar distintas tecnologas (por ejemplo, lenguaje procedural, lenguaje orientado a objetos, multimedia), y que han sido puestas en explotacin en distintos momentos. Gestin de Sistemas. Estas funciones aumentan considerablemente el costo de una solucin, pero no se pueden evitar. Siempre deben adaptarse a las necesidades de la organizacin, y al decidir la plataforma operativa y el entorno de desarrollo, es decir, en las primeras fases de la definicin de la solucin, merece la pena considerar los aspectos siguientes: Qu necesitamos gestionar? Dnde estarn situados los procesadores y estaciones de trabajo? Cuntos tipos distintos se soportarn? Qu tipo de soporte es necesario y quin lo proporciona?

La Plataforma Operativa, el Middleware y el Entorno de Desarrollo de Aplicaciones estn relacionados entre s. Las necesidades de apertura pueden condicionar la eleccin de la plataforma o del middleware, de igual manera que lo condiciona una determinada herramienta de desarrollo. El software de aplicacin puede influir en la plataforma del sistema, y el tiempo disponible para la primera aplicacin puede implicar algn tipo de compromiso. Por lo tanto, es necesario fijar los objetivos y el modo de conseguirlos en cada caso concreto: una Metodologa de Infraestructura para Sistemas Distribuidos que permita definir una 8

infraestructura para el sistema Cliente / Servidor y evale la puesta en marcha del proyecto sobre una base racional. El enfoque estructurado de dicha Metodologa comprende los pasos siguientes: 1. Captacin de las necesidades. Definir, analizar y evaluar, aunando los requerimientos del negocio con las aportaciones tecnolgicas. 2. Diseo conceptual en el que se sitan los principales bloques funcionales y de datos del sistema, mostrando la relacin y comunicacin entre ambos. 3. Detalle de los principales componentes funcionales, seleccin de procesos, determinando los principios que deben aplicarse a la seleccin de software o diseo de los mdulos. Al final de los tres pasos anteriores, se definen los conceptos del sistema y la infraestructura tecnolgica, sin concretar, todava, en productos o plataformas especficos. Por ltimo, se llega a la seleccin de plataformas y principales productos y componentes para la implantacin. El resultado es la descripcin de una solucin que incluye infraestructura tecnolgica, plataformas y productos.

1.4. Descripcin de las diferentes variantes de la Arquitectura Cliente / Servidor

1.4.1. Presentacin Distribuida.
Es aquella donde tanto la administracin de los datos, como la lgica de la aplicacin, funcionan en el servidor y la lgica de la presentacin se divide entre el servidor (parte preponderante) y el cliente (donde simplemente se muestra). Esta alternativa es extremadamente simple, porque generalmente no implica programacin alguna. Qu se obtiene con ella? Una mejor presentacin, desde el punto de vista estrictamente cosmtico, y ciertas capacidades mnimas para vincular las transacciones clsicas con el entorno Windows. Desde el punto de vista del uso de los recursos, esta primera alternativa es similar a la Arquitectura Centralizada.

1.4.2. Administracin de Datos Remota.

Es aquella donde dicha administracin de los datos se hace en el servidor, mientras que tanto la lgica de la aplicacin, como la de la presentacin, funcionan en el Cliente. Desde el punto de vista de las necesidades de potencia de procesamiento, esta variante es la ptima. Se minimiza el costo del procesamiento en el Servidor (slo se dedica a administrar la base de datos, no participando en la lgica de la aplicacin que, cada vez, consume ms recursos), mientras que se aumenta en el cliente, donde es irrelevante, teniendo en cuenta las potencias de Cliente necesarias, de todas maneras, para soportar el sistema operativo Windows. El otro elemento a tener en cuenta es el trnsito de datos en la red. Esta variante podr ser ptima, buena, mediocre o psima, de acuerdo a este trnsito. En el caso de transacciones o consultas activas, donde prcticamente todos los registros seleccionados son necesarios para configurar las pantallas a mostrar, este esquema es ptimo. 9

Por otro lado, en el caso de programas "batch", donde en realidad no se muestra nada, esta alternativa es tericamente indefendible (no obstante, si el cliente est ligado al servidor por una red de alta velocidad, los resultados prcticos, a menudo, son aceptables). Una variante interesante es la de complementar el procesamiento en el cliente con procesamiento en el servidor. Este objetivo se puede abordar de dos maneras bastante diferentes: La primera es el uso de "Stored Procedures" y "Triggers" asociados al servidor de base de datos. Como la mayor parte de los mecanismos utilizados en la arquitectura Cliente / Servidor, estos elementos fueron introducidos por Sybase al final de la dcada pasada y consisten en: "Triggers": son eventos que se disparan cuando se detectan ciertos estados en la base de datos. Su funcin es permitir la implementacin de reglas corporativas y permanentes, y su uso ms tpico ha sido el de proteger la integridad referencial de la base de datos. El "Trigger" llama "Stored Procedures" que se han programado previamente para atender a cada uno de dichos eventos. "Stored Procedures": son procedimientos que se programan para cumplir la parte de la lgica de la aplicacin que se desea se ejecute en el servidor. Un "Stored procedure" puede ser llamado por otro de ellos, por un "Trigger" o, directamente desde el cliente, mediante un Call remoto (llamada remota). Este esquema representa un avance importante en la distribucin de la lgica de la aplicacin entre el cliente y el servidor que, sin embargo, presenta un conjunto de rigideces indeseables: No existe un estndar de lenguaje para formulacin de "Stored Procedures" (el original, definido por Sybase, es el Transact SQL y diferentes dialectos del mismo son utilizados por Sybase y Microsoft, Oracle tiene el suyo propio llamado PL/SQL, Informix tambin tiene el Informix 4GL, mientras que IBM no tiene un lenguaje especfico.). La otra alternativa importante es la "Three Tiered Architecture". En este caso, se tiene la libertad de organizar cada aplicacin en tres partes (administracin de la base de datos, lgica de la aplicacin y lgica de la presentacin). Aqu se puede escoger libremente dnde se quiere colocar la lgica de la aplicacin: en el cliente, en el servidor de la base de datos, en un servidor de procesos, o distribuida entre ms de uno de ellos.

1.4.3. Internet
Un fenmeno que no se puede dejar de considerar es el crecimiento permanente de Internet. Probablemente sea hoy, en todo el mundo, lo nico que crece a un ritmo del 10% mensual. Actualmente se utiliza para un conjunto de propsitos (correo electrnico, transferencia de archivos, WWW). La disponibilidad de los WWW, ha modificado mucho las cosas y los cambios mayores an estn por producirse: hoy la enorme mayora de las pginas WWW son estticas y son muy adecuadas para promocin institucional, informacin, etc. En contraposicin, estas pginas estticas no son adecuadas para permitir a las distintas empresas formalizar negocios a travs de Internet: son necesarias pginas dinmicas, que puedan ser construidas en el momento, interactuando con la base de datos. Este tipo de facilidad dar al uso WWW una mucho mayor proyeccin y posibilitar, en gran escala, ventas al detalle, ventas de informacin, home banking de mucho mayor calidad, por ejemplo.

10

La premisa aqu es diferente: no existe el on-line, el procesamiento es siempre asncrono, pero se mantiene la unidad de tiempo del sincrnismo, por lo que, en el macro tiempo, se pueden implementar transacciones naturales para el usuario. Lo que se necesita es que el dilogo sea muy simple y natural a los usuarios, muchas veces casuales, sin entrenamiento alguno (y bsicamente sin "help") y que los tiempos de espera no sean irritantes para estos usuarios. Una tendencia clara, entonces, es la aparicin de herramientas que permitan la construccin de pginas WWW dinmicas. Los tiempos de implementacin de este tipo de soluciones sern muy breves.

11

Captulo II. Introduccin a TCP/IP

2.1. Redes y TCP/IP:
Una red es un conjunto de computadoras, conectadas entre s, que pueden comunicarse compartiendo datos y recursos. Los ordenadores suelen estar conectados mediante cables. Pero si la red es extensa, las conexiones pueden realizarse a travs de lneas telefnicas, microondas, fibra ptica y satlites. Las redes se clasifican en redes de rea local (LAN: Local Area Network) y redes de rea amplia (WAN: Wide Area Network). Las redes LAN abarcan una zona no demasiado grande, mientras que las WAN pueden abarcar varios pases. Internet es una red, que a su vez se compone de otras redes, que pueden ser LANs (conectadas mediante Ethernet y diversos protocolos de red como son: IPX/SPX, AppleTalk y por supuesto el estndar de Internet: TCP/IP ) o WANs (mediante mdem a travs de lneas telefnicas, conexiones ISDN, back-bones de fibra ptica, etc...). Para que la comunicacin entre ordenadores sea posible, es necesaria la existencia de un protocolo. Un protocolo es un conjunto de convenciones que determinan como se realiza el intercambio de datos entre dos ordenadores o aplicaciones. El protocolo mayoritariamente usado por las redes que forman parte de Internet se llama abreviadamente TCP/IP. Mientras que las grandes organizaciones tienen sus propias LANs y Gateways, los usuarios particulares deben conectarse mediante mdems o cable-mdems . Existen dos formas para la conexin de estos ltimos: La conexin por Dial y por el nivel IP. La primera consiste en conectarse con el servidor del ordenador del proveedor del servicio y tener acceso a los programas y utilidades que ofrece este servidor, para este tipo de conexin solo se necesita una terminal y un mdem, ejemplos de proveedores de este servicio son Prodigy, Terra, ATT, CIX, CompuServe y Delphi. Una conexin de nivel IP es mucho ms complicada, pero ofrece mucha mayor flexibilidad. Se necesita de la instalacin de una serie de drivers de red en el ordenador local, un stack TCP/IP y un driver de bajo nivel de mdem. Una vez configurado el stack del protocolo, ya se puede ejecutar cualquier tipo de software TCP/IP que lo reconozca y tener acceso directo a Internet. Internet es una red, a travs de la cual se encuentran interconectadas una gran cantidad de redes de ordenadores, de forma que cada ordenador puede comunicarse con cualquier otro, independientemente del tipo o del sistema operativo que utilice. Por eso el protocolo comn de comunicaciones usado en Internet es el TCP/IP. Cuando se transmite informacin de un ordenador a otro, esta no es transmitida de una sola vez, sino que se divide en paquetes pequeos, evitando de esta manera la monopolizacin de los recursos de la red por un solo usuario. Por los cables de la red viajan paquetes de informacin provenientes de diferentes ordenadores y con destinos tambin diferentes. Para alcanzar su destino, estos paquetes atraviesan en el camino cierto nmero de ordenadores y otros dispositivos que hacen que la transmisin sea posible. Las distintas partes que forman Internet estn conectadas por un conjunto de ordenadores dedicados llamados Routers, cuya misin principal es redirigir los paquetes de informacin que reciben y enviarlos por el camino adecuado para que alcancen su destino. El protocolo Ipv4 (Internet Protocol) se encarga de etiquetar cada paquete de informacin con la direccin apropiada. Cada ordenador conectado, tiene una direccin Internet IP Address nica y exclusiva, que est formada por cuatro nmeros separados por puntos, cada uno de los cuales puede tomar valores entre 0 y 255. Mientras, el protocolo TCP (Transmission Control Protocol) se encarga de dividir la informacin en 12

paquetes de tamao adecuado, numerarlos para que puedan volver a unirse en el orden correcto y aadir cierta informacin extra necesaria para la transmisin y posterior decodificacin del paquete. En 1982, TCP/IP Internet inclua unos cuantos cientos de ordenadores concentrados principalmente en Norte Amrica. En la primavera de 1993, ya haba ms de 1.200.000 ordenadores conectados a Internet en 45 pases repartidos por los 5 continentes, y su tamao sigue duplicndose cada 10 meses. Al principio los usos bsicos que ofreca la red eran los de: correo electrnico, transferencia de archivos y conexiones remotas. En la actualidad existe una gran cantidad de usuarios que disean protocolos de aplicacin para construir sus aplicaciones software. La variedad de las aplicaciones que usan TCP/IP consisten en sistemas de monitoreo y control de plataformas industriales, sistemas de control de inventarios de almacn, aplicaciones que permiten compartir el acceso a archivos entre sistemas alejados geogrficamente, como tambin posibilitar teleconferencias y aplicaciones de sistemas multimedia. El protocolo TCP/IP incluye a su vez muchos protocolos de aplicacin y cada da aparecen nuevos protocolos, pero solo algunos de ellos han sido documentados y forman parte del protocolo oficial TCP/IP ( Standard Application Protocols), que entre sus aplicaciones caractersticas se encuentran: HTTP, FTP, Telnet y E-Mail. La documentacin oficial se encuentra en los llamados RFCs, que estn disponibles sobre el mismo Internet.

2.2. Definicin del conjunto de protocolos TCP/IP:

El conjunto de protocolos TCP/IP incluye los protocolos de control de transporte e Internet, los mas importantes son, entre otros:
Protocolo IP v4 IP v6 ARP TCP UDP DNS ICMP Descripcin Protocolo Internet. Protocolo de la capa de red que mueve la informacin entre ordenadores. Versin 6 del protocolo IP. Protocolo de resolucin de direcciones. Protocolo de Control de Transporte. Protocolo de la capa de transporte que mueve la informacin entre las aplicaciones. Protocolo de Datagrama de Usuario. Protocolo de la capa de transporte, ms sencillo y menos fiable que TCP. Protocolo de Dominio de Nombres. Protocolo de Control de Mensajes. Lleva los mensajes de error y notifica otras condiciones.
Figura 1 Distintos protocolos de red.

Los pasos necesarios para el intercambio fiable de datos entre dos hosts son: Empaquetar los datos. Determinar la ruta a seguir. Transmisin de los datos por el medio fsico. Ensamblado de los datos entrantes para el mantenimiento de la secuencia correcta y evitar la prdida de fragmentos. Comprobar si existen datos repetidos. Notificar al emisor los datos que no se hayan recibido correctamente. Entregar los datos a la aplicacin requerida. Manejar eventos de error y problemas de comunicacin.

13

2.3. Modelo Cliente-Servidor:

TCP/IP como otros muchos protocolos de comunicacin, provee mecanismos bsicos para transferir datos, en particular, permite al programador establecer comunicaciones entre dos programas de aplicacin y poder transferir informacin del uno al otro, es lo que se llama comunicacin peer-to-peer (par a par), este tipo de aplicaciones pueden ejecutarse en la misma mquina o en diferentes mquinas. En la prctica un mtodo organizativo domina el uso de TCP/IP, ste es el paradigma Cliente-Servidor. El fundamento principal para el modelo cliente-servidor es el problema de rendezvous, que consiste de que ambos sistemas estn conectados al mismo tiempo. Este problema se resuelve, asumiendo que en todo tipo de comunicacin entre dos sistemas, uno de ellos debe ejecutar la aplicacin y esperar a que el otro sistema se conecte. As para asegurarse de que los ordenadores estn listos para la comunicacin, muchos administradores de sistemas acuerdan que la ejecucin de los programas de comunicacin, comience automticamente cuando arranca el sistema. El modelo cliente-servidor se divide en dos categoras, dependiendo si la aplicacin espera la comunicacin o la inicia. Este modelo usa la direccin de inicializacin para averiguar si un programa es cliente o servidor. En general la aplicacin que la inicia es el cliente. Cada vez que una aplicacin cliente se ejecuta, contacta con un servidor, envindole la seal request y esperando una respuesta, que cuando le llega, le permite continuar con el proceso. Para enviar un request, la aplicacin cliente necesita de una serie de parmetros que permiten al usuario especificar totalmente la direccin del sistema destino, el servicio demandado y el nmero de puerto del servicio. Cuando se quiere disear software cliente-servidor, se debe escoger entre dos tipos de interaccin: sin conexin UDP u orientado a conexin TCP, una u otra eleccin determina el nivel de fiabilidad del sistema. TCP es el protocolo ms fiable para comunicarse a travs de INTERNET, verifica la llegada de los datos y automticamente retransmite los segmentos que no lo han hecho. Calcula un checksum y un CRC sobre los datos para determinar que no ha habido errores durante la transmisin. Usa nmeros de secuencia para asegurarse de que la informacin llega ordenada y automticamente elimina los paquetes duplicados. Dispone de un flujo de control, para asegurarse de que la velocidad de transmisin del emisor no supere la de recepcin del receptor. Finalmente TCP informa tanto al cliente como al servidor si en algn momento la red es inoperable por cualquier motivo. Sin embargo, las aplicaciones que usan UDP, no disponen de garantas sobre la fiabilidad de recuperacin de la informacin. Aqu deben ser las propias aplicaciones cliente o servidor las que tienen que tomar las apropiadas medidas para detectar y corregir errores. UDP no introduce errores, solamente depende del subyacente IP para entregar los paquetes de informacin. IP, en cambio, depende de las subyacentes conexiones hardware y de los gateways intermedios. Por lo tanto UDP funciona bien, si la red lo hace correctamente. Se suele utilizar en redes locales, donde la probabilidad de que se den errores es ms baja. Manteniendo el estado de la informacin en el servidor se puede mejorar la eficiencia de la red, pero tambin puede consumir mas recursos de los que convendra, si el sistema de transporte de datos permite las opciones de duplicados, retraso o paquetes perdidos. Una aplicacin servidor puede necesitar acceder a servicios de la red, actuando de esta forma como un cliente, en una red no es inusual que esto ocurra, pero se debe de evitar que aparezcan dependencias circulares entre los servidores. Por lo tanto, las aplicaciones no pueden ser divididas fcilmente en clientes y servidores, porque muchas de ellas realizan ambas operaciones.

14

2.3.1. Interfaz del programa a protocolos

En muchas implementaciones, el software del protocolo TCP/IP reside en los sistemas operativos de los ordenadores, as cuando un programa de aplicacin usa TCP/IP para comunicarse, debe por tanto interactuar con el sistema operativo. Las rutinas que el sistema operativo dispone para la comunicacin definen la interfase entre la aplicacin y el software del protocolo, es lo que se denomina application interface. TCP/IP fue diseado para ser compatible con una gran variedad de sistemas informticos, por este motivo, TCP/IP no especifica los detalles de como las aplicaciones interfieren con l, solo sugiere ciertos requerimientos de funcionalidad y deja que los diseadores de los sistemas escojan los detalles. La Universidad de Berkeley (California) consigui definir una interfaz para el sistema operativo UNIX, que es lo que ha llegado a conocerse como socket interface (interfaz de conexin). Tambin AT&T defini una interfaz para el sistema V UNIX conocida con las siglas de TLI (Transport Layer Interface). Una interfaz debe soportar los siguientes tipos de operaciones: Asigne recursos locales para la comunicacin. Especifique los puntos de la comunicacin: local y remoto. Iniciar una conexin (cliente). Espere a que le llegue una conexin (servidor). Enviar o recibir datos. Determinar cuando llega la informacin. Generar datos urgentes. Manipular la informacin urgente que llega. Terminar de forma correcta la conexin. Terminacin de la conexin remota. Abortar la comunicacin. Procesar las condiciones de error o de una desconexin. Liberar los recursos locales cuando termine la comunicacin.

La interfaz conceptual definida por el estndar de TCP/IP no especifica las representaciones de los datos o los detalles de programacin, solamente otorga un ejemplo de una posible interfaz que un sistema operativo puede ofrecer a los programas de aplicacin que usan TCP/IP.

2.4. TCP /IP y comunicaciones entre redes

Figura 2 Sean las redes A, B y C de la figura, estas redes forman una red comn y cada una de ellas es una subred de la misma. El que se trate de subredes no significa que realicen menos funciones que las redes convencionales, sino que las tres redes forman una nica red lgica y las subredes contribuyen en las operaciones globales de interconexin.

Los gateways (pasarelas) entre redes se disean de forma que sean transparentes a las aplicaciones de los usuarios finales. De hecho, las aplicaciones de usuarios residen en ordenadores conectados a las redes. Las 15

pasarelas no necesitan cargarse con los protocolos del nivel de aplicacin. Como no son invocados por la pasarela, sta se puede dedicar a otras tareas, como la gestin del trfico entre las redes. No se ocupa de funciones del nivel de aplicacin como acceso a bases de datos, correo electrnico y gestin de archivos. Adems de la transparencia para el nivel de aplicacin, la mayora de los diseadores intentan que las pasarelas sean transparentes a las subredes, y viceversa. El propsito principal de la pasarela es recibir una PDU que contenga informacin de direccionamiento suficiente para que se pueda encaminar hacia su destino final o hasta la pasarela siguiente.

2.5. Protocolo IP
La capa de red es el corazn de cualquier red basada en TCP/IP. Esta capa incluye al protocolo Internet (IP), el protocolo de control de mensajes de Internet (ICMP) y el protocolo de manejo de grupos de Internet (IGMP), siendo estos ltimos dos, de apoyo a IP para manejar mensajes especiales de la red, tales como los de error y transmisiones mltiples. IP es un protocolo simple, fcil de implementar que provee una interfaz estndar a partir de la cual el resto de protocolos y servicios pueden ser construidos, sin tener que preocuparse de las diferencias que existan entre las distintas subredes por las cuales circulan los datos.

2.5.1. La estructura de direcciones IP

Se aade a las direcciones fsicas, un nuevo esquema de direccionamiento, para permitir la interconexin de diferentes tipos de redes. Una direccin Internet es una direccin IP. Cada tarjeta de interfase en una red especifica contiene una direccin IP nica. Las redes TCP/IP identifican los ordenadores y las redes a las que estn conectados utilizando direcciones IP de 32 bits.
DIRECCION IP = DIR. DE RED + DIR. DE ORDENADOR

Una direccin IP es de 32 bits, es decir, 4 bytes. Aunque siempre se identifican generalmente en notacin decimal, la cual representa cada byte como una serie de nmeros decimales separados por puntos.
Ej: 235.75.70.2

Identifican un punto de conexin en una red, una mquina puede tener varias direcciones distintas. La direccin IP combina un nmero de red y un numero de direccin en la red. Siendo el byte de mayor orden el que especifica a la red y los tres bytes de menor orden identifican al host dentro de la red. Aunque no es realmente as, ya que el byte de mayor orden nos ofrece mas informacin. Dado que si fuese realmente as, slo nos permitira identificar un numero mximo de 255 redes. Para evitar esto, se ha ideado un esquema de codificacin, donde se utilizan los primeros bits de tal byte, para la identificacin de la clase de direccin. La clase de direccin, especifica cuantos bytes utiliza la direccin como nmero de identificacin de la direccin de red. Por lo tanto, las clases de direcciones IP:

16

Clase A B C D E

Bits de Mayor Orden 0 10 110 1110 11110

Bits disponibles para identificador de Red. 1 2 3 Para difusin mltiple. Reservado para uso futuro

Figura 3 Distintas clases de direcciones IP

Clase A B C D E

N Nodos 16.777.216 65.536 256 -

Mascara Asociada 255.0.0.0 255.255.0.0 255.255.255.0 -

Dir. de Comienzo 0.0.0.0 128.0.0.0 192.0.0.0 224.0.0.0 240.0.0.0

Direccin Final 127.255.255.255 191.255.255.255 223.255.255.255 239.255.255.255 255.255.255.255

Figura 4 Distintos tipos de direcciones IP, informacin complementaria

Ejemplo: Sea la direccin IP 138.100.75.19 (clase B)

Parte de Red Subred 138 100 75 Parte del nodo 19

Direcciones Especiales: Rangos de direcciones IP reservadas: Son una serie determinada de rangos de direcciones IP, que a fin de que pudieran usarse para la confeccin de redes locales, fueron excluidas de Internet.
Clase A B C Mscara Asociada 255.0.0.0 255.255.0.0 255.255.255.0 Direccin de Comienzo 10.0.0.0 172.16.0.0 192.168.0.0 Direccin Final 10.255.255.255 172.31.255.255 192.168.255.255

Figura 5 Distintos tipos de direcciones IP, informacin complementaria

Si se disea una red TCP/IP que no va a estar conectada a Internet se puede utilizar cualquier direccin IP, con la salvedad de que no se pueden utilizar direcciones IP, que comiencen por 0. Tampoco por 127, ya que se reservan para los procesos de resolucin de problemas y diagnstico de la red. Las direcciones IP de los nodos no pueden terminar con cero. Y tambin hay que tener en cuenta que a las direcciones IP de nodos no se les puede asignar el valor 255, ya que este valor se emplea para enviar broadcasts a todos los elementos de una red. La mscara de red es un valor con el mismo formato e importancia que la direccin IP. Aplicada sobre la direccin IP de un adaptador de red, establece donde termina la direccin de la red externa y dnde comienza la direccin de la red local o segmento al que se encuentra conectado dicho adaptador. Las mscaras dividen redes en subredes, y esas subredes por medio de otras mscaras pueden dividirse en redes de menor tamao. A partir de una mscara de red se puede calcular el nmero de nodos que pertenecen al mismo segmento. Ejemplo: Supngase la mscara de una red de Clase C: Decimal: 255.255.255.0 En Binario: 11111111.11111111.11111111.00000000

17

Los 1s se asocian con la parte de la red externa y los 0s con la red local. El nmero de nodos por segmento en esta red ser el mximo nmero que podamos representar con un nmero binario de tantas cifras como ceros de red local tengamos. En este caso: 28 = 256 (Excluyendo aquellos nodos con direcciones IP no permitidas). IP es un ejemplo de servicio no orientado a conexin. Permite, sin establecimiento de llamada previo, el intercambio de datos entre dos ordenadores (sin embargo, los dos ordenadores generalmente comparten un protocolo comn de transporte orientado a conexin). Como IP no es orientado a conexin, se pueden perder datagramas entre las dos estaciones de usuario. Por esta razn es fundamental un protocolo de transporte de nivel superior, como TCP, que solucione esos problemas. Dado que IP es un protocolo de tipo datagrama, no dispone de mecanismos para proporcionar fiabilidad. No proporciona procedimientos de recuperacin de errores en las redes subyacentes, ni mecanismos de control de flujo. La mayora de estos problemas se pasan al nivel superior, TCP/IP soporta operaciones de fragmentacin, que son operaciones por las que una unidad de datos de protocolo (PDU) se divide y segmenta en unidades ms pequeas, lo que es muy til, ya que no todas las redes utilizan PDUs del mismo tamao.

2.5.2. Protocolos de direccin de Internet:

Las direcciones de nivel fsico, tal es el caso de las Ethernet, son de 6 bytes de longitud, mientras que las IP son de cuatro. Para resolver este problema y realizar la oportuna traduccin de direcciones, se tienen los protocolos de resolucin de direcciones. Existen dos protocolos: ARP: Protocolo de resolucin de direcciones: Averigua la direccin fsica a partir de la direccin IP. Se encarga de modular mapas de direcciones en la capa de red (IP) a la direccin correspondiente en la capa de enlace. Siendo la direccin de la capa de enlace de una tecnologa especifica. El mapeo de ARP, es dinmico. ARP vuelve a mapear direcciones de modo automtico cuando cambia la configuracin de la red. El mensaje ARP se enva en el campo de datos de una trama. Un campo en la cabecera de la trama permite identificar el tipo de mensaje. Una estacin A quiere comunicarse con la estacin B, de la cual se conoce su direccin IP, pero no su direccin fsica. Entonces, A pregunta a B su direccin fsica mediante un proceso de difusin (parte superior de la figura). Todas las estaciones de la red reciben el mensaje, pero slo B responde. El paquete de consulta, se compondr de la direccin fsica de A, direccin IP de A y direccin IP de B. Mientras que el paquete de respuesta, a parte de todo lo anterior nos enviar la direccin fsica de B. RARP: Protocolo de resolucin de direcciones inverso: Se encarga de mapear una direccin de la capa de enlace a la direccin IP correspondiente.

18

2.6. El datagrama de IP:

El protocolo Internet IP es el sistema de entrega del conjunto de protocolos TCP/IP. IP emplea datagramas sin conexin y poco fiables para llevar la informacin a travs de una red TCP/IP. A estos datagramas se les conoce como datagramas IP o paquetes IP, cada uno de los cuales incluye un encabezado IP y los datos reales. As una red TCP/IP encapsula casi toda la informacin dentro de un datagrama IP. El encabezado IP es un flujo de datos en serie de al menos 20 bytes de longitud. El datagrama IP se enva encapsulado en el campo de datos de una trama Ethernet: FORMATO DE UN DATAGRAMA IP:
VERSION (4) | LONGITUD DE CABECERA (4) TIPO DE SERVICIO (8) LONGITUD TOTAL (16) IDENTIFICADOR (16) IDENTIFICADORES (3) | DESPLAZAMIENTO DE FRAGMENTACION (13) TIEMPO DE VIDA (8) PROTOCOLO (8) CHECKSUM DE LA CABECERA (16) DIRECCION DE FUENTE (32) DIRECCION DE DESTINO (32) OPCIONES Y RELLENO (Variable) DATOS (Variable)
Figura 6 Datagrama IP (n) = NUMERO DE BITS EN EL CAMPO

El campo versin identifica la versin de IP en uso, actualmente la 4 (Ipv4). El campo de longitud de cabecera contiene 4 bits con el valor de la longitud de cabecera del datagrama. La longitud se mide en palabras de 32 bits. (Valor mnimo = 5). El campo de tipo de servicio (TOS) se puede utilizar para identificar varias funciones QOS de Internet: El retardo de trnsito, el caudal efectivo, la prioridad y la fiabilidad. 3 bits para la prioridad (se ignoran), 4 bits para el tipo de servicio y un bit a cero. Los 4 bits de tipo de servicio permiten al usuario solicitar las condiciones deseadas (solo un bit a 1):
Minimizar el retardo Maximizar el throughput (productividad) Maximizar la fiabilidad Minimizar el coste
Figura 7 configuracin de los bits de servicio

1000 0100 0010 0001

Se recomienda el uso de los siguientes valores para el tipo de servicio, dependiendo de la aplicacin:
PROTOCOLO TELNET Sesin de Control FTP Sesin de Datos FTP TNP IGP TOS 1000 1000 0100 0001 0010 DESCRIPCIN Minimizar retraso Minimizar retraso Maximizar productividad Minimizar Coste Maximizar fiabilidad

Figura 8 Valores para los diferentes servicios de red.

El campo de longitud total especifica la longitud total del datagrama de IP. Se mide en octetos e incluye la longitud de la cabecera y de los datos. La longitud mxima de un datagrama es de 65535 bytes ( 2 16 -1). 19

El protocolo IP utiliza tres campos de datos en la cabecera que sirven para controlar la fragmentacin y ensamblado del datagrama. Son el identificador, los indicadores y el desplazamiento de fragmentacin. El campo de identificador se utiliza para identificar unvocamente todos los fragmentos de un datagrama original. Se utiliza junto con la direccin de fuente del ordenador receptor para identificar el fragmento. El campo de identificadores contiene bits que indican si el datagrama se puede fragmentar y, si se puede fragmentar, uno de los bits se puede poner a 1 para indicar el ltimo fragmento del datagrama original. El campo de desplazamiento de fragmentacin contiene un valor que especifica la posicin relativa del fragmento en el datagrama original. Su valor se inicializa a cero y se va poniendo al valor apropiado a medida que la pasarela fragmenta los datos. El valor se mide en unidades de 8 bytes. La fragmentacin de datagramas se da porque las redes imponen limitacin al tamao mximo de los paquetes (MTU: Maximum Transfer Unit). El MTU en Ethernet es de 1492 bytes (campo de datos). Cuando el datagrama pasa entre dos redes fsicas distintas, los encargados de la fragmentacin son los routers. Al fragmentar un datagrama se copian la mayora de los campos de la cabecera. El campo de identificacin, distinto para cada datagrama permite identificar todos los fragmentos de un mismo datagrama. El campo de longitud en un fragmento indica la longitud de dicho fragmento. Adems hay que tener en cuenta dos bits en el campo de flags: do not fragment: Indica que el datagrama no puede ser fragmentado. More fragments: Indica que este fragmento no es el ltimo de una serie.

Hay que tener en cuenta que en el caso de que se pierda un fragmento, esto conlleva a la prdida de todo el datagrama. El proceso de reensamblado se realiza en el receptor, que establece un plazo de reensamblado, y cuando el plazo se cumple sin que se reciban nuevos fragmentos del mismo datagrama, el host destino descarta los recibidos y enva un mensaje de error al origen. El valor recomendado para el plazo de reensamblado es de 60 y 120 segundos. El parmetro de tiempo de vida (TTL) se utiliza para medir el tiempo que un datagrama lleva en la interred. Todas las pasarelas deben observar el valor de este campo y descartarlo si es cero, deben tambin decrementar su valor en todos los datagramas que procesan. Este campo tambin se utiliza para que los ordenadores limiten el tiempo de vida de los segmentos que pasan por la interred. Idealmente, los valores del campo TTL se pueden configurar, asignndose su valor en funcin de las prestaciones observadas de la red. El campo de protocolo se utiliza para identificar el siguiente protocolo en la estructura de niveles por encima de IP que va a recibir el datagrama en el ordenador destino. Por ejemplo, el nmero 6 identifica a TCP. El checksum de la cabecera se utiliza para detectar distorsiones en la cabecera. No se realizan comprobaciones en la cadena de datos de usuario, pero exige que un protocolo de nivel superior en el ordenador sea el que realice algn tipo de comprobacin de errores para velar por la integridad de los datos.

20

El datagrama de IP lleva dos direcciones. Se denominan direccin de fuente y de destino y no se modifican durante toda la vida del datagrama. El campo de opciones se emplea para identificar diversos servicios adicionales. Este campo no se utiliza en todos los datagramas. La mayora de los esquemas utilizan este campo para gestin de la red y diagnsticos. Permite especificar: encaminamiento fuente, confidencialidad del datagrama y registro de la ruta (RR) entre otros. El campo de relleno se puede utilizar para asegurarse de que la cabecera del datagrama se alinea exactamente con una divisin de intervalo de 32 bits. Finalmente, el campo de datos contiene los datos de usuario. IP estipula que la combinacin de los campos de cabecera y de datos no puede sobrepasar 65535 bytes.

21

Captulo III. El protocolo HTTP

3.1. Introduccin
El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de informacin entre los clientes Web y los servidores HTTP. La especificacin completa del protocolo HTTP 1.0 est recogida en el RFC 1945. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin de informacin como el World Wide Web. Desde el punto de vista de las comunicaciones, est soportado sobre los servicios de conexin TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de los entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexin de los clientes Web. Una vez que se establece la conexin, el protocolo TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de errores. HTTP se basa en sencillas operaciones de solicitud / respuesta. Un cliente establece una conexin con un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operacin y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actan; cada objeto Web (documento HTML, fichero multimedia o aplicacin CGI) es conocido por su URL. Segn la especificacin del protocolo, "HTTP es un protocolo del nivel de aplicacin con la agilidad y velocidad necesaria para sistemas de informacin distribuidos, colaborativos y de hipermedia. Es un protocolo orientado a objetos, genrico, que puede usarse para muchas tareas extendiendo sus mtodos. Una caracterstica de HTTP es que permite que los sistemas se construyan independientemente de la informacin que se transfiere."

3.2. Propiedades de HTTP

Esquema de direccionamiento integral: El protocolo usa el concepto de referencia dado por URI (Universal Resource Identifier) como una ubicacin o como un nombre - URL y URN respectivamente para indicar la fuente donde debe aplicarse un mtodo. Cuando un hiperlink HTML se conforma, la URL es de la forma http://host:nmero_puerto/path/archivo.html. Para decir algo ms general, la referencia URL es del tipo servicio://host/archivo.extensin. De esta manera el protocolo puede abarcar los servicios de Internet ms bsicos. HTTP tambin se usa para la comunicacin entre agentes y gateways, permitiendo el acceso a otros protocolos de Internet existentes, como SMTP, NNTP, FTP, Gopher, etc. HTTP est diseado para permitir la comunicacin con esos gateways, vas servidores proxy, sin prdida de la informacin transportada por estos otros protocolos. Arquitectura Cliente-Servidor: HTTP se basa en el paradigma pedido/respuesta. La comunicacin generalmente se lleva a cabo sobre una conexin TCP/IP en Internet. El puerto por defecto es el 80, pero otros puertos tambin pueden usarse. Un programa cliente establece la conexin con un programa del servidor y enva un pedido a este ltimo mediante el mtodo request, URI y versin de protocolo, seguido por un mensaje que contiene los modificadores del pedido, informacin sobre el cliente y contenido. El servidor responde con una lnea de

22

estado, incluyendo su versin de protocolo y un mensaje de xito o error, seguido de un mensaje que contiene informacin del servidor, metainformacin y contenido. Sin conexin: Aunque dijimos que el cliente establece una conexin con el servidor, se dice que el protocolo es sin conexin porque una vez que el pedido est satisfecho, la conexin cae. Sin estado: Luego que el servidor responde a un pedido del cliente, la conexin cae y es olvidada. Es decir, no hay una memoria de conexiones de un cliente. Las implementaciones de servidor HTTP puras tratan todos los pedidos como si fueran nicos y nuevos. Representacin abierta y extensible de tipos de datos: HTTP usa Internet Media Types, comnmente llamados tipos de contenido MIME (Multipart Internet Mail Extension), para brindar una negociacin de tipos extensible y abierta. Con HTTP, donde el emisor y el receptor se pueden comunicar directamente, las aplicaciones tienen permitida una mayor libertad en el uso de tipos no registrados. Cuando el cliente enva una transaccin al servidor, se agregan encabezados (headers) para conformar las especificaciones estndares de e-mail (RFC822). La mayora de los pedidos de clientes esperan una respuesta en "slo texto" o en HTML. Cuando el servidor HTTP transmite informacin de vuelta al cliente, incluye un encabezado simil-MIME para informar al cliente qu tipo de dato viene despus de dicho encabezado. La traduccin depende de que el cliente procese la utilidad adecuada que corresponda a ese tipo de dato. Campos de encabezados: Una transaccin HTTP consiste de un encabezado seguido, opcionalmente, por una lnea en blanco y algn dato. El encabezado especificar cosas como la accin requerida del servidor, o el tipo de dato retornado, o el cdigo de estado. El uso de campos de encabezados enviados en las transacciones HTTP le dan gran flexibilidad al protocolo. Estos campos permiten que se enve informacin descriptiva en la transaccin, permitiendo as la autenticacin, encriptacin e identificacin de usuario. Un encabezado es un bloque de datos que precede a la informacin propiamente dicha, por lo que muchas veces se hace referencia a l como metadato - porque tiene datos sobre los datos-. Si se reciben lneas de encabezado del cliente, el servidor las coloca en las variables de ambiente de CGI con el prefijo HTTP_ seguido del nombre del encabezado. Cualquier caracter guin ( - ) del nombre del encabezado se convierte a caracteres "_". El servidor puede excluir cualquier encabezado que ya est procesado, como Authorization, Content-type y Content-length. El servidor puede elegir excluir alguno o todos los encabezados si incluirlos excede algn lmite del ambiente de sistema. Ejemplos de esto son las variables HTTP_ACCEPT y HTTP_USER_AGENT. HTTP_ACCEPT Los tipos MIME que el cliente aceptar, dado los encabezados HTTP. Otros protocolos quizs necesiten obtener esta informacin de otro lugar. Los tems en esta lista deben estar separados por una coma, como lo dice la especificacin HHTP: tipo, tipo HTTP_USER_AGENT El navegador que utiliza el cliente para enviar el pedido. El formato general para esta variable es: software/versin librera/versin El servidor enva al cliente: Un cdigo de estado que indica si el pedido fue exitoso o no. Los cdigos de error tpicos indican que el archivo solicitado no se encontr, que el pedido no est en forma o que se requiere autenticacin para acceder al archivo. La informacin propiamente dicha. Como HTTP permite enviar documentos de todo tipo y formato, es ideal para transmitir multimedia, como grficos, audio y video. Esta libertad es una de las mayores ventajas de HTTP.

23

Tambin enva informacin sobre el objeto que se retorna. Una lista de campos de encabezados que hacen esto.

3.3. Caractersticas del protocolo http

Toda la comunicacin entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original. Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado est identificado por su clasificacin MIME. Existen tres verbos bsicos o acciones (hay ms, pero por lo general no se utilizan) que un cliente puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar informacin al servidor y HEAD, para solicitar las caractersticas de un objeto (por ejemplo, la fecha de modificacin de un documento HTML). Cada operacin HTTP implica una conexin con el servidor, que es liberada al trmino de la misma. Es decir, en una operacin se puede recoger un nico objeto. No mantiene estado. Cada peticin de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada peticin como una operacin totalmente independiente del resto. Cada objeto al que se aplican los verbos del protocolo est identificado a travs de la informacin de situacin del final de la URL.

3.4. Mtodos http

Los mtodos o verbos de HTTP representan las diferentes operaciones que se pueden solicitar a un servidor HTTP. El formato general de un comando es:
Nombre del mtodo Objeto sobre el que se aplica Versin de HTTP utilizada
Figura 9 Forma en que se forma un comando HTTP.

Cada mtodo acta sobre un objeto del servidor, normalmente un fichero o aplicacin, que se toma de la URL de activacin. La ltima parte de esta URL, que representa la direccin de un objeto dentro de un servidor HTTP, es el parmetro sobre el que se aplica el comando. Se compone de una serie de nombres de directorios y ficheros, adems de parmetros opcionales para las aplicaciones CGI. El estndar HTTP/1.0 recoge nicamente tres mtodos, que representan las operaciones de recepcin y envo de informacin y chequeo de estado: El mtodo GET: Se usa para pedir un documento especfico. Cuando haces click en un link, se est usando el mtodo GET. Este mtodo debera usarse cuando el acceso URL no cambiar el estado de una base de datos. La semntica de GET cambia a un GET condicional si el mensaje de pedido incluye un campo de encabezado If-Modified-Since. Un GET condicional pide que la fuente identificada sea transferida slo si ha sido modificada despus de la fecha dada por el encabezado. El GET condicional intenta reducir el uso de la red permitiendo que las entidades que estn en cach sean refrescadas sin requerir la transferencia innecesaria de datos. El mtodo HEAD: Este mtodo slo para preguntar informacin sobre un documento, no para el propio documento. HEAD es mucho ms rpido que GET, ya que se transfiere mucha menos informacin. Es generalmente usada por clientes que usan caching para ver si el documento ha cambiado desde la ltima vez que lo accedieron. Si no cambi, la copia local puede usarse nuevamente; de otra forma, la versin actualizada debe recuperarse con GET. La metainformacin contenida en los encabezados HTTP en respuesta a un pedido HEAD deberan ser idnticos a la informacin enviada en respuesta a un pedido GET. Este mtodo se puede usar para obtener metainformacin sobre una fuente identificada por el URI 24

sin transferir la informacin. Este mtodo mucho para checar la validez, accesibilidad y reciente modificacin de links. El mtodo POST: Es usado para transferir datos del cliente al servidor; est diseado para permitir que un mtodo uniforme cubra funciones como: anotacin de fuentes existentes; envo de mensajes para un bulletin board, grupo de noticias o lista de mailing; proveer un bloque de datos (generalmente un formulario) a un proceso de manejo de datos; extensin de una base de datos. Posteriormente se han definido algunos comandos adicionales, que slo estn disponibles en determinadas versiones de servidores HTTP, con motivos eminentemente experimentales. La ltima versin de HTTP, denominada 1.1, recoge estas y otras novedades, que se pueden utilizar, por ejemplo, para editar las pginas de un servidor Web trabajando en remoto. El mtodo PUT Actualiza informacin sobre un objeto del servidor. Es similar a POST, pero en este caso, la informacin enviada al servidor debe ser almacenada en la URL que acompaa al comando. As se puede actualizar el contenido de un documento. El mtodo DELETE Elimina el documento especificado del servidor. El mtodo LINK Crea una relacin entre documentos. El mtodo UNLINK Elimina una relacin existente entre documentos del servidor.

3.5. Las cabeceras

Son un conjunto de variables que se incluyen en los mensajes HTTP, para modificar su comportamiento o incluir informacin de inters. En funcin de su nombre, pueden aparecer en los requerimientos de un cliente, en las respuestas del servidor o en ambos tipos de mensajes. El formato general de una cabecera es:
Nombre de la variable Cadena ASCII con su valor
Figura 10 Formato de una cabecera HTTP.

Los nombres de variables se pueden escribir con cualquier combinacin de maysculas y minsculas. Adems, se debe incluir un espacio en blanco entre el signo : y su valor. En caso de que el valor de una variable ocupe varias lneas, stas debern comenzar, al menos, con un espacio en blanco o un tabulador.

3.5.1. Cabeceras comunes para peticiones y respuestas

Content-Type: descripcin MIME de la informacin contenida en este mensaje. Es la referencia que utilizan las aplicaciones Web para dar el correcto tratamiento a los datos que reciben. Content-Length: longitud en bytes de los datos enviados, expresado en base decimal. Content-Encoding: formato de codificacin de los datos enviados en este mensaje. Sirve, por ejemplo, para enviar datos comprimidos (x-gzip o x-compress) o encriptados. Content-Languaje: identifica el lenguaje natural de los datos transferidos. Content-Transfer-Encoding: identifica la codificacin del mensaje para una transferencia. Por defecto es binary. Date: fecha local de la operacin. Las fechas deben incluir la zona horaria en que reside el sistema que genera la operacin. Por ejemplo: Sunday, 12-Dec-96 12:21:22 GMT+01. No existe un formato nico en las fechas; incluso es posible encontrar casos en los que no se dispone de la zona horaria correspondiente, con los problemas de sincronizacin que esto produce. Los formatos de fecha a emplear estn recogidos en los RFC 1036 y 1123.

25

Pragma: permite incluir informacin variada relacionada con el protocolo HTTP en el requerimiento o respuesta que se est realizando. Por ejemplo, un cliente enva un Pragma: no-cache para informar de que desea una copia nueva del recurso especificado.

3.5.2. Cabeceras slo para peticiones del cliente

Accept: campo opcional que contiene una lista de tipos MIME aceptados por el cliente. Se pueden utilizar * para indicar rangos de tipos de datos; tipo/* indica todos los subtipos de un determinado medio, mientras que */* representa a cualquier tipo de dato disponible. Accept-Charset: indica al servidor que conjunto de caracteres prefiere el navegador. Accept-Encoding: indica al servidor el tipo de codificacin de datos que el navegador puede aceptar. Accept-Languaje: indica al servido el lenguaje natural que prefiere el navegador.

Authorization: clave de acceso que enva un cliente para acceder a un recurso de uso protegido o limitado. La informacin incluye el formato de autorizacin empleado, seguido de la clave de acceso propiamente dicha. La explicacin se incluye ms adelante. From: campo opcional que contiene la direccin de correo electrnico del usuario del cliente Web que realiza el acceso. If-Modified-Since: permite realizar operaciones GET condicionales, en funcin de s la fecha de modificacin del objeto requerido es anterior o posterior a la fecha proporcionada. Puede ser utilizada por los sistemas de almacenamiento temporal de pginas. Es equivalente a realizar un HEAD seguido de un GET normal. Referer: contiene la URL del documento desde donde se ha activado este enlace. De esta forma, un servidor puede informar al creador de ese documento de cambios o actualizaciones en los enlaces que contiene. No todos los clientes lo envan. User-agent: cadena que identifica el tipo y versin del cliente que realiza la peticin. Por ejemplo, los browsers de Netscape envan cadenas del tipo User-Agent: Mozilla/3.0 (WinNT; I)

3.5.3. Cabeceras slo para respuestas del servidor HTTP

Allow: informa de los mtodos HTTP opcionales que se pueden aplicar sobre el objeto al que se refiere esta respuesta. Por ejemplo, Allow: GET, POST. Expires: fecha de expiracin del objeto enviado. Los sistemas de cach deben descartar las posibles copias del objeto pasada esta fecha. Por ejemplo, Expires: Thu, 12 Jan 97 00:00:00 GMT+1. No todos los sistemas lo envan. Puede cambiarse utilizando un <META EXPIRES> en el encabezado de cada documento. Last-modified: fecha local de modificacin del objeto devuelto. Se puede relacionar con la fecha de modificacin de un archivo en disco, o, para informacin generada dinmicamente desde una base de datos, con la fecha de modificacin del registro de datos correspondiente. Location: informa sobre la direccin exacta del recurso al que se ha accedido. Cuando el servidor proporciona un cdigo de respuesta de la serie 3xx, este parmetro contiene la URL necesaria para accesos posteriores a este recurso. Server: cadena que identifica el tipo y versin del servidor HTTP. Por ejemplo, Server: NCSA 1.4. WWW-Autenticate: cuando se accede a un recurso protegido o de acceso restringido, el servidor devuelve un cdigo de estado 401, y utiliza este campo para informar de los modelos de autentificacin vlidos para acceder a este recurso.

26

3.5.4. Otras cabeceras

Forwarded: Utilizado por servidores proxy para indicar los pasos intermedios entre el navegador y el servidor. Link: Describe la relacin entre dos URLs. MIME-Version: Indica la versin del protocolo MIME que se est utilizando para construir el mensaje transferido. Orig-URI: Utilizado por el cliente para especificar al servidor la URL original de la URL demandada. Public: Contiene una lista de todos los mtodos no estndar que soporta un servidor. Retry-After: Indica al cliente la cantidad de tiempo que debe esperar antes de demandar la URL pedida de nuevo. Title: Indica el ttulo de la URL. URI-Header: Especifica la URL

3.6. Etapas de una transaccin HTTP

Para profundizar ms en el funcionamiento de HTTP, veremos primero un caso particular de una transaccin HTTP; en los siguientes apartados se analizarn las diferentes partes de este proceso. Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos: 1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introducindola directamente en el campo Location del cliente Web. 2. El cliente Web decodifica la URL, separando sus diferentes partes. As identifica el protocolo de acceso, la direccin DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor. 3. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente. 4. Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST, HEAD), la direccin del objeto requerido (el contenido de la URL que sigue a la direccin del servidor), la versin del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de informacin, que incluye datos sobre las capacidades del browser, datos opcionales para el servidor. 5. El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato MIME de la informacin de retorno, seguido de la propia informacin. 6. Se cierra la conexin TCP. Este proceso se repite en cada acceso al servidor HTTP. Por ejemplo, si se recoge un documento HTML en cuyo interior estn insertadas cuatro imgenes, el proceso anterior se repite cinco veces, una para el documento HTML y cuatro para las imgenes. Veamos el proceso completo con un ejemplo: - Desde un cliente se solicita la URL http://www.unican.es/invest/default.html - Se abre una conexin TCP/IP con el puerto 80 del sistema www.unican.es. - El cliente realiza la solicitud, enviando algo similar a esto:
GET /invest/default.html HTTP/1.0 Operacin solicitada+objeto+versin de http Accept: text/plain Lista de tipos MIME que acepta o entiende el cliente Accept: text/html Accept: audio/* Accept: video/mpeg .. .. .. Accept: */* Indica que acepta otros posibles tipos MIME

27

User-Agent: Mozilla/3.0 (WinNT; I) Informacin sobre el tipo de cliente Lnea en blanco, indica el final de la peticin Figura 11 Formato de una peticin al servidor por parte de un cliente de WEB.

- El servidor responde con la siguiente informacin:

HTTP/1.0 200 OK Status de la operacin; en este caso, correcto Date: Monday, 7-Oct-96 18:00:00 Fecha de la operacin Server: NCSA 1.4 Tipo y versin del servidor MIME-version: 1.0 Versin de MIME que maneja Content-type: text/html Definicin MIME del tipo de datos a devolver Content-length: 254 Longitud de los datos que siguen Last-modified: 6-Oct-96 12:30:00 Fecha de modificacin de los datos Lnea en blanco <HTML> Comienzo de los datos <HEAD><TITLE>Recursos de investigacin en UNICAN </TITLE></HEAD> <BODY> .. .. .. .. .. .. </HTML> Figura 12 Formato de la respuesta de un servidor al cliente WEB.

- Se cierra la conexin.

3.7. Cdigos de estado del servidor

Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico que informa sobre el resultado de la operacin, como primera lnea del mensaje de respuesta. Estos cdigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. El formato de la lnea de estado es:
Versin de protocolo HTTP utilizada Cdigo numrico de estado (tres dgitos)
Figura 13 Formato delos mensajes de error HTTP.

Descripcin del cdigo numrico

Existen cinco categoras de mensajes de estado, organizadas por el primer dgito del cdigo numrico de la respuesta: 1xx : mensajes informativos. Por ahora (en HTTP/1.0) no se utilizan, y estn reservados para un futuro uso. 2xx : mensajes asociados con operaciones realizadas correctamente. 3xx : mensajes de redireccin, que informan de operaciones complementarias que se deben realizar para finalizar la operacin. 4xx : errores del cliente; el requerimiento contiene algn error, o no puede ser realizado. 5xx : errores del servidor, que no ha podido llevar a cabo una solicitud.

Los cdigos ms comunes se recogen en la siguiente tabla:

Cdigo 200 201 Comentario OK Created Descripcin Operacin realizada satisfactoriamente. La operacin ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. Este nuevo objeto ya est disponible. Puede ser utilizado en sistemas de edicin de documentos. La operacin ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. El nuevo objeto no est disponible por el momento. En el cuerpo de la respuesta se debe informar sobre la disponibilidad de la informacin. La operacin ha sido aceptada, pero no ha producido ningn resultado de inters. El cliente no deber modificar el documento que est mostrando en este momento.

202 204

Accepted No Content

28

301

Moved Permanently

302

Moved Temporarily Not Modified Bad Request Unauthorized

304 400 401 403 404 500 501 502 503

Forbidden Not Found Internal Server El servidor ha tenido un error interno, y no puede continuar con el procesamiento. Error Not El servidor no tiene capacidad, por su diseo interno, para llevar a cabo el requerimiento del cliente. Implemented El servidor, que est actuando como proxy o pasarela, ha encontrado un error al acceder al recurso Bad Gateway que haba solicitado el cliente. Service El servidor est actualmente deshabilitado, y no es capaz de atender el requerimiento. Unavailable
Figura 14 Principales cdigos de respuesta de un servidor http.

El objeto al que se accede ha sido movido a otro lugar de forma permanente. El servidor proporciona, adems, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automticamente a la nueva URL. En caso de tener capacidad, el cliente puede actualizar la URL incorrecta, por ejemplo, en la agenda de bookmarks. El objeto al que se accede ha sido movido a otro lugar de forma temporal. El servidor proporciona, adems, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automticamente a la nueva URL. El cliente no debe modificar ninguna de las referencias a la URL errnea. Cuando se hace un GET condicional, y el documento no ha sido modificado, se devuelve este cdigo de estado. La peticin tiene un error de sintaxis y no es entendida por el servidor. La peticin requiere una autorizacin especial, que normalmente consiste en un nombre y clave que el servidor verificar. El campo WWW-Autenticate informa de los protocolos de autentificacin aceptados para este recurso. Est prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la proteccin. La URL solicitada no existe.

3.8. Cachs de pginas y servidores proxy

Muchos clientes Web utilizan un sistema para reducir el nmero de accesos y transferencias de informacin a travs de Internet, y as agilizar la presentacin de documentos previamente visitados. Para ello, almacenan en el disco del cliente una copia de las ltimas pginas a las que se ha accedido. Este mecanismo, denominado "cach de pginas", mantiene la fecha de acceso a un documento y comprueba, a travs de un comando HEAD, la fecha actual de modificacin del mismo. En caso de que se detecte un cambio o actualizacin, el cliente acceder, ahora a travs de un GET, a recoger la nueva versin del fichero. En caso contrario, se proceder a utilizar la copia local. Un sistema parecido, pero con ms funciones es el denominado "servidor proxy". Este tipo de servidor, una mezcla entre servidor HTTP y cliente Web, realiza las funciones de cach de pginas para un gran nmero de clientes. Todos los clientes conectados a un proxy dejan que ste sea el encargado de recoger las URLs solicitadas. De esta forma, en caso de que varios clientes accedan a la misma pgina, el servidor proxy la podr proporcionar con un nico acceso a la informacin original. La principal ventaja de ambos sistemas es la drstica reduccin de conexiones a Internet necesarias, en caso de que los clientes accedan a un conjunto similar de pginas, como suele ocurrir con mucha frecuencia. Adems, determinadas organizaciones limitan, por motivos de seguridad, los accesos desde su organizacin al exterior y viceversa. Para ello, se dispone de sistemas denominados "cortafuegos" (firewalls), que son los nicos habilitados para conectarse con el exterior. En este caso, el uso de un servidor proxy se vuelve indispensable. En determinadas situaciones, el almacenamiento de pginas en un cach o en un proxy puede hacer que se mantengan copias no actualizadas de la informacin, como por ejemplo en el caso de trabajar con documentos generados dinmicamente. Para estas situaciones, los servidores HTTP pueden informar a los clientes de la expiracin del documento, o de la imposibilidad de ser almacenado en un cach, utilizando la variable Expires en la respuesta del servidor.

29

Captulo IV. Breve descripcin de las clases utilizadas

Las clases que continuacin se describen pertenecen al ambiente de desarrollo Delphi de Borland; se escogi este ambiente operativo despus de revisar las facilidades que daba para el desarrollo del presente sistema, tambin se estudiaron previamente las opciones que nos daba Java para el desarrollo del mismo, mas por simplicidad en el desarrollo se opto por adoptar a Delphi como base para este trabajo. Las clases que trataremos en este capitulo existen tambin en todos los lenguajes orientados a objetos, en particular Java que es el otro que se estudio, pero se escogi hacer el proyecto en Delphi por la facilidad que nos da su interfase y por hacernos un producto compilado a diferencia de java que es un lenguaje interpretado. Otra cuestin para la decisin en el lenguaje fue que ya existe Delphi para el entorno Linux. Con lo cual con pocos cambios se podra pasrsete proyecto a este Ambiente Operativo

4.1. La clase Tlist

TList mantiene una lista de punteros de objetos. Esta clase se encuentra dentro de la unidad classes. Esta clase se encuentra en el rbol de herencia de Delphi como se indica en la siguiente figura.

Descripcin Use un objeto TList para almacenar y mantener una lista de objetos, dentro del rbol de herencia se coloca inmediatamente despus de la clase Tobject la cual define a todas las clases en Delphi. TList introduce propiedades y mtodos para: Agregar o suprimir los objetos en la lista. Reacomodar los objetos en la lista. Localizar y acceder a los objetos en la lista. Ordenar los objetos en la lista.

4.1.1. Propiedades
Capacity : Especifica el tamao del arreglo de apuntadores mantenidos por el objeto TList.
property Capacity: Integer;

Descripcin Coloque en Capacity el nmero de punteros predeterminado que la lista necesitar contener. Al colocar la propiedad Capacity, una excepcin del EOutOfMemory ocurre si no se puede satisfacer la solicitud de memoria que se requiere para su nuevo tamao. Revise el valor de Capacity para saber el nmero de objetos que la lista puede almacenar sin reubicar memoria. No confunda a Capacity con la propiedad Count, que es el nmero de entradas en la lista que estn ocupadas. El valor de Capacity es siempre mayor o igual que el valor de Count. Cuando Capacity sea

30

mayor que Count, la memoria sin uso puede ser liberada colocando el valor de count en la propiedad Capacity. Cuando un objeto se agregue a una lista que ya est llena, el valor de Capacity es automticamente aumentado. Colocar el valor de Capacity adecuado antes de aadir objetos puede reducir el nmero de reasignaciones de memoria y por consiguiente puede mejorar desempeo. Count : Indica el nmero de entradas en la lista que estn en uso.
property Count: Integer;

Descripcin Revise el valor de Count para determinar el nmero de entradas en los Items del arreglo. Aumentar el tamao de Count aadir el nmero necesario de apuntadores nulos al final del arreglo. Disminuir el tamao de Count remover el nmero necesario de entradas del final del arreglo. Count no siempre es igual al numero de objetos referenciados en la lista. Algunas de las entradas en el arreglo pueden contener apuntadores nulos. Para remover los apuntadores nulos y colocar a Count al nmero de entradas que contienen referencias a los objetos, hay que llamar al mtodo Pack. Items : Lista las referencias del objeto.
property Items[Index: Integer]: Pointer;

Descripcin Use Items para obtener un puntero de un objeto especfico en el arreglo. El parmetro Index indica el exponente del objeto, donde 0 es el ndice del primer objeto, 1 es el ndice del segundo objeto, etctera. Use Items con la propiedad Count para iterar a travs de todos los objetos en la lista. No todas las entradas en el arreglo necesitan contener referencias a objetos. Algunas de las entradas pueden ser punteros nulos. List : Especifica el arreglo de punteros que forman los items del arreglo
TPointerList = array[0..MaxListSize-1] of Pointer; PPointerList = ^TPointerList; property List: PPointerList;

Descripcin Use List a acceder directamente el conjunto de Items del arreglo.

4.1.2. Mtodos
Add : Inserta un nuevo item al final de una lista.
funcin Add (Item:pointer): integer;

Descripcin

31

Al llamar a Add se inserta un objeto nuevo al final del arreglo de Items. Regresa el ndice del nuevo tem, donde el primer tem en la lista tiene como ndice 0. Add reserva ms memoria si el arreglo de Items ya sobrepasa el valor de Capacity del objeto lista. Add incrementa el valor de Count para reflejar la adicin de un nuevo puntero. Nota: Add siempre inserta el Item puntero al final del arreglo de Items, aun si el arreglo contiene punteros nulos. Clear : Borra todos los items de la lista.
Procedure clear; dynamic;

Descripcin Se llama a Clear para vaciar el arreglo de Items y colocar Count a 0. Clear tambin libera la memoria usada para almacenar el arreglo y coloca Capacity a 0. Delete : Remueve el item en la posicin dada por el parmetro Index.
Procedure delete(Index: integer);

Descripcin Se llama a Delete para remover el item en una posicin especfica de la lista. Una llamada a Delete mueve todos los items en el arreglo que siguen al item suprimido, y reduce el valor de Count. Nota: Delete no libera la memoria asociada con el item. Para liberar la memoria que se us para almacenar un tem suprimido, reduzca la propiedad Capacity. Destroy : Destruye una instancia de TList.
destructor Destroy: override;

Descripcin No llame a Destroy directamente en una aplicacin. En lugar de eso, llame a Free. Free se asegura de que la memoria del objeto TList no est ya liberada, y slo entonces llama a Destroy. Destroy libera la memoria usada para almacenar la lista de items. Nota: Destroy no libera la memoria apuntada por los elementos de la lista. Error : Sube una excepcin a la EListError.
class procedure Error(const Msg: string; Data: Integer); virtual;

Descripcin La llamada a Error se utiliza para subir una excepcin cuando ocurre un error trabajando con un objeto TList. Error ensambla un mensaje de error con la cadena que se pasa por el parmetro Msg y el valor pasado por el parmetro Data, y entonces los inserta en la EListError. Exchange : Intercambia la posicin de dos items en el arreglo.
procedure Exchange(Index1, Index2: Integer);

32

Descripcin Llame a Exchange para intercambiar las posiciones de los items en posicin Index1 e Index2 del arreglo. Expand : Aumenta la Capacidad de la lista.
function Expand: TList;

Descripcin Lame a Expand para crear ms espacio para aadir tems nuevos para la lista. Expand no realiza ninguna accin s antes no se ha cubierto la capacidad de la lista. Si Count = Capacity, Expand aumenta la capacidad de la lista como sigue. Si el valor de Capacity es mayor que 8, entonces Expand aumenta la capacidad de la lista en 16. Si el valor de Capacity es mayor que 4, pero menor a 9, la capacidad de la lista aumenta en 8. Si el valor de Capacity es menor de 4, entonces la capacidad de la lista crece en 4. El valor devuelto es el objeto expandido de la lista. First : Devuelve item[0].
function First: Pointer;

Descripcin Llame a First para obtener el primer puntero del arreglo de Items. IndexOf : Devuelve el ndice de la primera entrada en el arreglo con un valor especificado.
function IndexOf(Item: Pointer): Integer;

Descripcin Llame a IndexOf para obtener el ndice de un puntero el arreglo de Items. Especifique el puntero por medio del parmetro Item. Si un tem no est en la lista, entonces IndexOf regresa -1. Si un puntero aparece ms de una vez en el arreglo, entonces IndexOf devuelve el ndice de la primera aparicin. Insert : Aade un objeto al arreglo de Items en la posicin especificada por Index.
procedure Insert(Index: Integer; Item: Pointer);

Descripcin Llame a Insert para aadir tems en la parte interna del arreglo. Insert aade el tem en la posicin indicada, moviendo el tem que previamente ocup esa posicin, y todos subsiguientes tems, hacia arriba. Insert expande la capacidad de la lista si es necesario, y aumenta la propiedad Count. Last : Devuelve item[Count - 1] .
function Last: Pointer;

Descripcin 33

Llame a Last para recuperar el ltimo puntero en el arreglo de Items. Move : Cambia la posicin de un tem en el arreglo.
procedure Move(CurIndex, NewIndex: Integer);

Descripcin Llame a Move a mover el tem en la posicin CurIndex a fin de que ocupe la posicin NewIndex. Pack : Suprime todos los tems nulos del arreglo de Items.
procedure Pack;

Descripcin Llame a Pack para mover todos los tems nulos a la parte delantera del arreglo y hacer ms pequea la propiedad Count a el nmero de tems realmente usados. Pack no libera la memoria usada para almacenar los punteros nulos. Para liberar la memoria de las entradas sin uso movidas por Pack, coloque la propiedad Capacity con el nuevo valor de Count. Remove : Suprime la primera referencia del parmetro Item del arreglo.
function Remove(Item: Pointer): Integer;

Descripcin Llame a Remove para remover un tem especfico el arreglo cuando su ndice es desconocido. El valor devuelto es el ndice del tem en el arreglo antes de que fuera removido. Despus de que un tem haya sido removido, todo los tems que le sigan son reasignados en el arreglo y la propiedad Count es disminuida en uno. Si el arreglo contiene ms de una copia del puntero, entonces slo la primera copia es suprimida. Sort : Realiza a un QuickSort en la lista basada en la funcin de comparacin Compare.
type TListSortCompare = function (Item1, Item2: Pointer): Integer; procedure Sort(Compare: TListSortCompare);

Descripcin Llame a Sort para ordenar los tems en el arreglo. Compare es una funcin de comparacin que indica cmo deben ser ordenados los tems. Compare regresa < 0 si Item1 es menor que Item2, 0 si son iguales y > 0 si Item1 es mayor que Item2. Create : Construye un objeto e inicializa sus datos antes de que el objeto sea usado.
constructor Create;

Descripcin Create construye e inicializa una instancia del objeto. El propsito, el tamao y el comportamiento de objetos se definen. El mtodo Create defini por TObject no hace ninguna cosa especial; Esto es, inicializa los datos. La localizacin en memoria es, sin embargo, asignada automticamente cuando Create es llamado. 34

Los objetos descendientes usualmente definen a un constructor que est hecho a la medida para crear ese tipo particular de inicializacin del objeto y de los datos que necesita. Free : Destruye un objeto y libera su memoria asociada, si es necesario.
procedure Free;

Descripcin Use Free para destruir un objeto. Free automticamente llama el Destructor si la instancia del objeto no es nula. Cualquier objeto instanciado en runtime que no tiene un Owner debera destruirse por una llamada a Free, a fin de que el objeto pueda destruirse correctamente y la memoria liberada. Free tiene xito aun si el objeto es nulo, as es que si el objeto fue nunca inicializado, el llamado a Free no resultar en un error.

4.2. La clase TstringList

TStringList mantiene una lista de cadenas de caracteres. Esta clase se encuentra dentro de la unidad classes. Esta clase se encuentra dentro del rbol de herencia de Delphi como se muestra en la figura.

Descripcin Utilice un objeto TStringList para almacenar y manipular una lista de cadenas. Esta clase implementa las propiedades y mtodos abstractos que se definen dentro de la clase TStrings, e introduce nuevas propiedades, eventos y mtodos para:

Ordenar las cadenas de una lista Prohibir la duplicacin de cadenas en listas ordenadas. Responder a cambios en los contenidos de la lista.

4.2.1. Propiedades
Capacity : Especifica el nmero de cadenas que podr contener la lista de cadenas.
property Capacity: Integer;

Descripcin Capacity indica el nmero de cadenas que en primera instancia sern almacenadas en el objeto. Al colocar la propiedad Capacity, una excepcin del EOutOfMemory ocurre si no se puede satisfacer la solicitud de memoria que se requiere para su nuevo tamao. Revise el valor de Capacity para saber el nmero de objetos que la lista puede almacenar sin reubicar memoria. No confunda a Capacity con la propiedad Count, que es el nmero de entradas en la lista que estn ocupadas. El valor de Capacity es siempre mayor o igual que el valor de Count. Cuando Capacity sea 35

mayor que Count, la memoria sin uso puede ser liberada colocando el valor de count en la propiedad Capacity. Cuando un objeto se agregue a una lista que ya est llena, el valor de Capacity es automticamente aumentado. Colocar el valor de Capacity adecuado antes de aadir objetos puede reducir el nmero de reasignaciones de memoria y por consiguiente puede mejorar desempeo. Count : Indica el nmero de entradas en la lista que estn en uso.
property Count: Integer;

Descripcin Utilice Count para iterar con todos los elementos de la lista o cuando necesite conocer la posicin de una cadena en relacin a la ultima cadena de la lista. Duplicates: Especifica si una cadena repetida puede ser insertada en una lista ordenada.
type TDuplicates = (dupIgnore, dupAccept, dupError); property Duplicates: TDuplicates;

Descripcin Utilice Duplicates para especificar que accin se debe tomar al tratar de insertar una cadena duplicada en una lista ordenada. el valor que puede tomar duplicates debe ser uno de los que se especifican a continuacin:
Valor DupIgnore DupError DupAccept Descripcin Ignora todo intento de insertar una cadena duplicada dentro de la lista. Levanta una excepcin EStringListError cuando se intenta insertar una cadena duplicada en una lista ordenada Permite cadenas duplicadas en una lista ordenada.
Figura 15 Descripcin de los valores que puede tomar la propiedad Duplicates.

Nota: Duplicates no hace nada si la lista no esta ordenada. Sorted: Especifica si las cadenas en la lista sern ordenadas automticamente.
property Sorted: Boolean;

Descripcin Colocar Sorted con el valor Verdadero causa que la lista de cadenas sea ordenada automticamente en orden ascendente. Esta propiedad con un valor Falso indica que las cadenas sern insertadas al final de la lista. Cuando Sorted es igual a Falso, una lista puede ser ordenada ascendentemente llamando al mtodo Sort. Strings: posiciona el indicador en la cadena que esta referenciada por un ndice con base en 0.
property Strings[Index: Integer]: string; default;

Descripcin Utilice Strings para leer o modificar una cadena en una posicin particular, siendo 0 la posicin de la primera cadena 1 la de la segunda, etc. Para localizar una cadena en particular en la lista llame al mtodo IndexOf. 36

Strings es la propiedad por default del objeto stringlist. El identificador string puede ser omitido cuando accedemos a la propiedad strings, por ejemplo, las siguientes lneas de cdigo siguientes son entradas vlidas:
MyStringList.Strings[0] := 'This is the first string'; MyStringList[0] := 'This is the first string';

4.2.2. Mtodos
Add : Inserta una nueva cadena al final de la lista.
funcin Add (const S: string): Integer; override;

Descripcin Al llamar a Add se insertar una cadena nueva al final de la lista. Si la lista esta ordenada la cadena se colocara en el lugar apropiado. Regresa el ndice del nuevo tem, donde el primer tem en la lista tiene como ndice 0. Clear : Borra todas las cadenas de la lista.
Procedure clear; override;

Descripcin Llam a Clear para vaciar la lista de cadenas. Todas las referencias de los objetos asociados son borradas. Delete : Remueve la cadena en la posicin dada por el parmetro Index.
Procedure delete(Index: integer); override;

Descripcin Llam a Delete para remover la cadena en una posicin especfica de la lista. Destroy : Destruye una instancia de TStringList.
destructor Destroy: override;

Descripcin No llame a Destroy directamente en una aplicacin. En lugar de eso, llame a Free. Free se asegura de que la memoria del objeto TStringList no est ya liberada, y slo entonces llama a Destroy. Destroy libera la memoria usada para almacenar la lista de items. Exchange : Intercambia la posicin de dos items en el arreglo.
procedure Exchange(Index1, Index2: Integer); override;

Descripcin Llame a Exchange para intercambiar las posiciones de las cadenas en posicin Index1 e Index2 del arreglo. Find: Localiza el ndice de una cadena en una lista ordenada e indica con un valor si la cadena existe en la lista. 37

function Find(const S: string; var Index: Integer): Boolean; virtual;

Descripcin Use find para obtener el ndice de una cadena S en una lista ordenada. Si la cadena S existe en la lista, Find regresa Verdadero. En caso contrario regresa falso. El ndice de la cadena S es regresado dentro del parmetro index. IndexOf : Devuelve la posicin de una cadena en la lista.
function IndexOf(const S: string): Integer; override;

Descripcin Llame a IndexOf para obtener la posicin de la primera ocurrencia de una cadena. Si la cadena no est en la lista, entonces IndexOf regresa -1. Insert : Aade una cadena a la lista en la posicin especificada por Index.
procedure Insert (Index: Integer; const S: string); override;

Descripcin Llame a Insert para aadir la cadena S en la posicin index de la lista. Nota: si la lista esta ordenada, el llamado a este mtodo producir una excepcin. Sort : ordena las cadenas de una lista en orden ascendente.
procedure Sort; virtual;

Descripcin Llame a Sort para ordenar las cadenas de una lista que tiene la propiedad Sorted con valor Falso.

4.3. La clase TServerSocket

TServerSocket maneja un conexin de socket servidor para un servicio TCP/IP. Esta clase se encuentra definida dentro de la unidad scktcomp. Su rbol de herencia se muestra en la siguiente figura. Descripcin Utilice un objeto TServerSocket para convertir la aplicacin en un servidor del tipo TCP/IP. TServerSocket escucha por peticiones de conexiones TCP/IP desde otras mquinas, y establece las condiciones de cuando una peticin es recibida.

38

4.3.1. Propiedades
Socket: especifica el objeto TServerWinSocket que describe el trmino de una conexin de escucha.
property Socket: TServerWinSocket;

Descripcin Use la propiedad Socket para obtener: Informacin acerca de las conexiones activas actualmente en el socket servidor. Informacin acerca de los hilos de conexin que estn esperando para ser utilizados por el servidor. Acceso al manejador de sockets de Windows para escuchar la conexin que necesita para las llamadas a la API Socket de Windows.

ThreadCacheSize: especifica el nmero mximo de hilos que pueden ser utilizados por nuevas conexiones de los clientes.
property ThreadCacheSize: Integer;

Descripcin Cuando ServerType es stThreadBlocking, cada nueva conexin que es aceptada por el socket servidor es atendida por un hilo de ejecucin diferente. Con el objeto de mejorar el funcionamiento. Utilice ThreadCacheSize para especificar el numero de hilos que pueden ser almacenados para su reutilizacin. El valor ideal de ThreadCacheSize depende del numero y frecuencia de las peticiones que son recibidas por el servidor. Active: indica si la conexin del socket esta abierta y disponible para la comunicacin con otras maquinas.
property Active: Boolean;

Descripcin Antes de intentar usar o cambiar la conexin del socket, lea la propiedad Active para determinar s la conexin esta abierta y lista. Port: especifica el nmero id que identifica la conexin del servidor.
property Port: Integer;

Descripcin Para los sockets de servidor, Port es el ID de la conexin en la que el servidor escucha las peticiones de los clientes. El valor de Port es usualmente asociado con el tipo de servicio que esta brindando la aplicacin. Service: Especifica el nombre del servicio que se est utilizando.
property Service: string;

Utilice Service para identificar el uso de la conexin. Windows provee un nmero estndar de nombres de servicios como son FTP, HTTP, FINGER, etc. Servers puede especificar servicios adicionales y otros

39

puertos asociados en el archivo SERVICES. Para mayor informacin, dirigirse a la documentacin de sockets de Microsoft Windows . ServerType: Especifica como cada conexin que es aceptada por el servidor es manejada.
type TServerType = (stNonBlocking, stThreadBlocking); property ServerType: TServerType;

Descripcin Ponga ServerType a stThreadBlocking para crear automticamente un nuevo hilo de ejecucin cada vez que el socket acepta una conexin. Cuando se tiene este valor, la ejecucin de los hilos de conexin es suspendida mientras esta leyendo o escribiendo hasta que toda la informacin ha sido correctamente transferida a travs de la conexin. El hilo de cada conexin genera los eventos onClientRead o onClientWrite cuando el socket servidor necesita leer o escribir. Ponga ServerType a stNonBlocking para manejar todas las lecturas o escrituras sobre el socket de forma asncrona. Cuando ServerType tiene este valor, todas las conexiones de los clientes son manejadas por un solo hilo de ejecucin.

4.3.2. Mtodos
Create: Crea una instancia de TServerSocket.
constructor Create(AOwner: TComponent); override;

Descripcin Llame a Create para crear e inicializar un socket servidor en tiempo de ejecucin. Despus del llamado de este mtodo suceden los siguientes acciones: Asigna el objeto TServerWinSocket que encapsula la conexin Windows Socket para el servidor. Inicializa el despachador de eventos y errores para el servidor. Inicializa la propiedad ThreadCacheSize a 10.

Close: cierra la conexin del socket.

procedure Close;

Descripcin Llame a Close para cerrar la conexin del socket. Close pone la propiedad Active con el valor False. Evitando as que el servidor no escuche mas por las peticiones de los clientes. Open: abre la conexin del socket.
procedure Open;

Descripcin Llame a Open para inicializar la conexin del socket. Open pone la propiedad Active a Verdadero, permitiendo as que el servidor pueda escuchar por las peticiones de los clientes.

40

4.3.3. Eventos
OnClientRead: ocurre cuando el socket servidor debe leer la informacin proveniente del socket cliente.
property OnClientRead: TSocketNotifyEvent;

Descripcin Escriba un evento OnClientRead para manejar la lectura desde la conexin del socket. Si la propiedad ServerType es igual a stThreadBlocking, use un objeto TwinSocketStream para prevenir problemas que puedan originarse mientras se lee que podran levantar excepciones por tiempo indefinido. En otro caso use los mtodos del socket para realizar la lectura.

41

Captulo V. Diseo
5.1. Especificacin y requisitos generales.
El presente trabajo de tesis consiste en la creacin de un servidor web que sea capaz de optimizar el tiempo de respuesta, que proporciona a sus clientes, llevando con esto implcito un ahorro en la utilizacin de los recursos de la red. Para el desarrollo del sistema se sugiere la utilizacin de un sistema de almacenamiento temporal en memoria de las pginas que son solicitadas con mayor frecuencia. Se sugiere que este almacenamiento se realice sobre la memoria RAM por su velocidad de acceso. Se requiriere de una opcin para el conteo de las peticiones que recibe el servidor, es decir se necesita saber en todo momento qu pginas han sido visitadas, y cuantas veces lo han sido en un periodo de tiempo determinado. Se requiere que el mantenimiento de este cach se realice de forma automtica cada cierto periodo de tiempo que deber ser proporcionado por el administrador del servidor, dependiendo de sus necesidades particulares. Se deber llevar el control de que pginas se encuentran en un momento dado dentro del cach para que la peticin por parte del cliente sea redireccionada de manera transparente a esta copia y sea transmitida la respuesta con mayor eficiencia. Este trabajo se realiza basado en que en la actualidad todos los servidores comerciales o de cdigo libre basan la recuperacin de los recursos del disco duro provocando una latencia que se traduce en tiempo en que los recursos del WEB son consumidos. Con este trabajo se pretende reducir este tiempo de acceso de los recursos y por lo tanto liberar los servicios mas rpidamente evitando as posibles cuellos de botella en la red. El mbito en el que se desarrolla este trabajo es de los servidores de redes pudiendo ser estos de tipo HTTP, FTP, y todos aquellos que permiten la comunicacin entre mquinas. Los Requerimientos del sistema son: Un sistema operativo que soporte aplicaciones de 32 bits en particular Windows 9X, un sistema Operativo que soporte el manejo de RamDisks, y al menos 32MB de memoria RAM. El flujo que tendr la informacin dentro de este sistema se representa mediante el siguiente diagrama:

42

Figura 16 Diagrama de flujo de la informacin del sistema.

Este diagrama muestra el flujo de la informacin que sigue el sistema mientras se esta ejecutando, pero aparte de ste existen dos procesos que corren de manera independiente a este flujo de datos, estos procesos se controlan a travs de timers y son los que actualizan la informacin del cach y la de la base de documentos visitados. Para la realizacin del sistema se decidi partir desde la creacin del servidor HTTP en lugar de modificar alguno de los programas de servicio ya existentes, como puedo ser por ejemplo apache, con el fin de entender en forma mas completa como funcionan estos servicios.

5.2. Descripcin de las tareas del sistema

Actualizacin de la base de archivos solicitados.- Cada vez que se cumpla un periodo de tiempo definido por el usuario, se actualizar el archivo que contiene la informacin de los recursos que han sido solicitados por el usuario, esto se hace con el fin de tener actualizada esta base en caso de que haya una falla en la corriente elctrica o una cada del sistema operativo. Ya que esta informacin es de suma importancia para decidir cuales recursos son los que causan mayor carga de trabajo a nuestro servidor. Actualizacin del cach.- Cada vez que se cumpla el periodo de tiempo definido por el administrador, el sistema revisar la base de visitas para sacar que archivos han sido los mas visitados en ese periodo de tiempo y con esto: Eliminar del cach aquellos archivos que no cumplieron con el numero mnimo de visitas para permanecer en el cach. Colocar en el contador de los recursos incluidos en el cach el valor 0 con el fin de que aquel recurso que dentro del siguiente periodo de tiempo definido en el timer no cumpla con el valor de raiting sea eliminado del mismo. 43

Para el manejo de la base de visitas al servidor se utilizar un registro, los objetos creados se almacenarn dentro de una estructura Tlist y se mantendr un ndice ordenado de esta estructura Tstringlist. As mismo se propone en una primera etapa de la siguiente estructura bsica la cual mantendr la informacin de las consultas que hayan sido satisfechas por el servidor:
visita = record cont:integer; path:string[80]; cache:boolean; end;

Dentro de la variable path la cual esta definida como una cadena de longitud mxima de 80 caracteres se almacenar la direccin real dentro del disco duro de la mquina que sirva como servidor de los recursos existentes, una vez que hayan sido solicitados por lo menos en una ocasin. La variable cont de tipo entero nos permite llevar el registro de las veces que ha sido solicitado un recurso, su valor inicial ser 1 ya que solo se agrega un nuevo elemento a la lista si este ha sido solicitado. Se hace uso de una variable entera teniendo en cuenta que es poco probable que un recurso alcance 2,147,483,647 que es el valor positivo mas alto que puede alcanzar una variable de este tipo. La variable cache de tipo booleano nos indica si el recurso despus de haber inicializado o actualizado el cach ha sido catalogado como de alto trfico y por lo tanto almacenado en este recurso. Para la conclusin de este proyecto se considera como suficiente esta estructura para llevar a cavo las operaciones requeridas por los requisitos.

5.3. Detalles del diseo

Analizando los requisitos del sistema se observa que es necesaria la participacin de 2 archivos que le servirn de memoria de estados al sistema entre sesiones de uso del mismo, aunque se supone que un sistema de servicio de web debe estar presente todo el tiempo tambin es cierto que no podemos omitir la cada del sistema por motivos externos y por lo tanto es necesaria la participacin de estos archivos en el mismo. Uno de ellos es de tipo texto y en el se almacenan los parmetros bsicos de funcionamiento del sistema como son: Directorio raz de los recursos a compartir. Nombre del archivo de presentacin de los recursos. Letra que identifica a la unidad cach. Numero base de visitas que servir para la decisin de almacenamiento Tiempo entre el respaldo del archivo de recursos solicitados Tiempo entre las actualizaciones de la informacin existente en el cach.

El segundo archivo a utilizar es propiamente un archivo estructurado con base en el registro descrito anteriormente y que contiene los nombres, localizacin y cantidad de visitas de cada uno de los recursos que hayan sido solicitados en la sesin. Al iniciarse el servidor estos son los primeros recursos a los que hace referencia, teniendo en cuenta que si se ha ejecutado por primera vez este acceso es la creacin de estos archivos con parmetros definidos en el interior del sistema.

44

Razn por la cual se debe existir una procedimiento de inicializacin de los archivos la cual se deber comportar como se expresa en el siguiente diagrama:

Figura 17.

Una vez inicializado el sistema cuyos valores de control principales son los que se describen a continuacin:
Dirinicio Archpresent Raiting Metodo : string; : : : En esta variable se almacena la direccin del directorio que servir como raz del sitio WEB que estamos compartiendo. En esta variable se almacena el nombre del recurso HTML que servir como string; presentacin o ndice de nuestro sitio WEB. Esta variable es la encargada de almacenar el numero que servir como base para la string; decisin de s un recurso debe o no subirse a nuestro sistema de cach. Dentro de esta variable almacenaremos el comando que se ha solicitado cuando se string; detecta que ha ocurrido una peticin a nuestro sistema servidor. Nos sirve para decidir acerca de la respuesta que se le dar al cliente. Dentro de esta variable se almacenar la ruta del recurso solicitado a partir del string; directorio de inicio del sitio web es de gran importancia para saber si el recurso que se solicita existe o no en nuestro sitio. Este es un objeto definido dentro de la VCL de Delphi y permite la creacin de una lista Tlist; de cualquier tipo de objeto la cual crece conforme se requiera. Este es un objeto definido dentro de la VCL de Delphi y permite la creacin de una lista TStringList; de cadena la cual crece conforme se requiera esta se utiliza como ndice de la anterior.
Figura 18 Algunas de las variables utilizadas en el sistema.

URL Lista Indice

: : :

El sistema queda a la espera de que se produzca una peticin por parte de algn cliente para esto se le aade el cdigo correspondiente al evento OnClientRead definido en la clase TserverSocket definida dentro de la VCL. Este mtodo se comporta como indica el diagrama siguiente:

45

Figura 19 Diagrama de control del mtodo OnClientRead.

46

Captulo VI. Implementacin del sistema

6.1. Delphi como herramienta de desarrollo.
Delphi se divide en tres secciones, el compilador (con su "encadenador"), la librera, y el IDE (Ambiente de desarrollo integrado, o Integrated Development Environment). El compilador/encadenador es un programa que crea el archivo ejecutable de Windows estilo Intel, sin ningn intrprete de por medio. La librera es cdigo que nos permite usar todas las capacidades de Delphi. La librera esta escrita en su totalidad en Object Pascal (es una librera "de clases" estilo MFC, llamada VCL), y esta totalmente orientada a objetos. El "programa principal" de Delphi es un archivo de texto ASCII con extensin DPR. Esta extensin quiere decir Delphi PRoject (proyecto de Delphi). Para cada una de las ventanas que usted disea en el IDE, Delphi crea una "unidad". Una unidad es un archivo individual (tambin de texto ASCII) que representa en general a un objeto, o a una agrupacin lgica de funciones. En el caso de los "objetos" que son formas, Delphi tambin crea un archivo "DFM" (Delphi Form) para guardar la apariencia del diseo de las mismas. El IDE de Delphi se divide en tres secciones: En la parte superior podemos observar la una barra dividida en la cual se encuentran los elementos del men, una parte de botones para manejos del proyecto y el rea donde se encuentran los diferentes componentes divididos por categoras. Como se muestra en la siguiente figura.

En la parte de la izquierda de la pantalla podemos observar el inspector de objetos, que contiene las "propiedades" y "eventos" del objeto seleccionado en el diseador. Usted puede hacer click con el mouse en cualquier propiedad para modificarla. La otra pagina contiene los eventos, que son los mensajes que Delphi "atrapa" y que usted puede asignar a procedimientos. Cuando disea sus propios componentes, tambin puede aadir eventos y relacionarlos con mensajes.

Por ultimo podemos observar tambin la plantilla de diseo, dentro de est estaremos colocando los componentes que consideremos oportunos para la realizar la interfaz de nuestro sistema, podemos temer tantas plantillas como deseemos dentro de nuestra aplicacin y cada una se identificara de una manera nica en el desarrollo del sistema. Atrs de nuestra(s) plantilla(s) de diseo, se encuentra la ventana de edicin, es en est en donde podremos escribir el cdigo correspondiente a nuestra aplicacin.

47

6.2. Delphi e Internet.

En Delphi es posible la creacin de aplicaciones para Internet a travs de la interface socket que proporciona Windows. Esta interface esta formada por una biblioteca de mas de 40 funciones que nos permiten enviar o recibir datos desde cualquier punto de la red a otro. Esta interface se incluye en Delphi desde la versin 2 dentro de una unidad denominada winsock.pas que redefine en cdigo Delphi todas las funciones del API Winsock. Delphi proporciona dos componentes que facilitan la implementacin de aplicaciones cliente / servidor: TClientSocket y TServerSocket. El componente TServerSocket permanece siempre a la escucha de peticiones procedentes de otras mquinas con el fin de poder establecer conexiones TCP/IP con ellas. Las propiedades ms importantes de la clase TServerSocket son: Socket Esta propiedad utiliza el objeto TServerWinSocket que establece el punto final de una aplicacin que permanece a la escucha de peticiones procedentes de otras mquinas. Esta propiedad se utiliza para obtener informacin sobre las conexiones activas en un momento dado en el socket servidor. Active Indica si la conexin a travs del socket est abierta y disponible para poder comunicarnos con otras mquinas. Service Especfica el nombre del servicio para el cual estamos utilizando esta conexin. Port Numero de puerto TCP de la conexin. La propiedad Service prevalece sobre el nmero de puerto, es decir, se utilizar el puerto especificado en el archivo \windows\services. ServerType Especifica si cada conexin aceptada por el servidor es non-bloking en el que todas las conexiones se tratan sobre un solo thread; o stThreadBloking para utilizar un nuevo hilo para cada conexin aceptada por el servidor. Los eventos ms importantes de la clase TServerSocket son: OnAccept Ocurre cuando el servidor acepta la conexin procedente del cliente. OnClientConnect Ocurre cuando un cliente socket completa la conexin aceptada por el socket servidor. OnClientDisconnect Ocurre cuando se cierra una de las conexiones con el socket cliente. 48

OnClientRead Ocurre cuando el socket servidor debera leer la informacin procedente del socket cliente. OnClientWrite Ocurre cuando el socket servidor debera escribir datos al socket cliente.

6.3. Creacin del sistema ServerCPC

Una vez establecidos los requisitos del sistema, escogida la herramienta para su implementacin y habiendo estudiado las clases, mensajes y eventos necesarios para la comunicacin que nos proporciona esta herramienta, el primer paso fue la creacin del servidor http, siguindose los siguientes puntos: Puerto de comunicacin a utilizar.- Se decidi utilizar el puerto de comunicacin 850 para esta aplicacin, a fin de no entorpecer el funcionamiento de cualquier otro servidor http que se pudiera tener levantado en la computadora donde se instale este sistema. Por defecto stas usan el puerto 80. Se opt por utilizar la propiedad ServerType en non-bloking puesto que se encontr un ejemplo de servicio con esta propiedad as activada, y por que el curso de multithreads en el sistema que se desarroll se complicara un poco mas all de lo necesario, ya que no este tipo de programacin es menos frecuente.

El sistema desarrollado tiene la siguiente estructura para su funcionamiento: Inicializacin de las diferentes variables de apoyo (directorio de inicio, archivo de presentacin, base de comparacin de raiting, entre otras). Inicializacin del socket servidor y activacin del mismo.

Una vez realizado esto, el sistema entra en un estado de espera por las peticiones que le sean realizadas, ntese que este estado no bloquea el sistema, ya que se puede entrar al rea de configuracin del mismo permitiendo as la personalizacin del sistema dinmicamente. Por medio de la implementacin del mtodo OnClientRead, que como se dijo anteriormente, se llama cada vez que el servidor debera empezar a leer la informacin proporcionada por el socket cliente, es como se activan las fases del sistema relacionadas con la preparacin y envo de la respuesta por parte del servidor y en su momento del recurso solicitado, para esto se llevan a cabo las siguientes tareas: Leer los datos que llegaron al socket. Analizar los datos recibidos Se construye el cdigo de respuesta por parte del servidor. Enva la cabecera de respuesta del servidor. Si no se produjo una entrada no vlida por parte del servidor, mtodo no implementado o desconocido o un recurso no existente en el servidor, entonces se enva el recurso correspondiente. Se cierra la conexin del socket.

Es claro que hasta este momento solo se ha descrito la parte que corresponde a un servidor web sin ninguna caracterstica en especial adems de la de enviar los recursos que le sean solicitados sin llevar un control de los mismos. Sin embargo como lo indican los objetivos del presente trabajo se le agregaron caractersticas a esta estructura bsica de tal forma que permitiera llevar un registro de todas las peticiones exitosas realizadas al servidor y as poder hacer el manejo de los recursos ya sea colocndolos o quitndolos del disco cach. As como tambin se le agregaron los procedimientos para el manejo y localizacin de los recursos.

49

6.3.1. Registro y conteo de peticiones.

Para poder llevar a cabo un conteo y registro fiable de los recursos pertenecientes al dominio del servidor que han sido accedidos por algn cliente, se realiz la creacin de una estructura de datos, la cual nos proporciona la posibilidad de poder almacenar la informacin relevante del mismo, como son: La ruta de acceso real dentro del disco duro del recurso accedido. El conteo de las veces que este recurso ha sido solicitado. Si existe una copia del mismo recurso dentro del cach.

La declaracin de esta estructura es como sigue: visita = record cont : integer; path : string[80]; cache : boolean; end; Por medio de esta estructura y la creacin de un objeto del tipo Tlist, en el cual como se explic en un captulo anterior mantiene una lista de objetos de cualquier tipo, es posible llevar a cabo el registro de los recursos solicitados, ms esto no es suficiente para poder llevar a cabo la actualizacin de los registros, ya que para que una bsqueda sea exitosa en un objeto Tlist el objeto a buscar debe coincidir completamente y no solo de forma parcial como seria buscar un recurso por su nombre, para solucionar este problema, a la par que la lista se esta creando, tambin se esta creando una lista ndice por medio de un objeto de la clase TstringList, en el cual se almacenan en el mismo orden, que en el objeto Tlist, solo las rutas de acceso de los recursos solicitados. Es el conjunto de estas dos listas que es posible acceder un registro especifico, perteneciente a un recurso que esta siendo solicitado, y actualizar la informacin correspondiente del mismo. Con este fin se realiza lo siguiente. Cuando se detecta que el recurso solicitado por el cliente existe en el dominio del servidor, esto solo pasa despus de que se valid el mtodo, se busca dentro de la lista ndice si este recurso ha sido solicitado con anterioridad, dependiendo del resultado de esta consulta se realizan las siguientes acciones. En caso Negativo, se crea un nuevo registro que se inicializa como se explica a continuacin: o En la variable path se almacena la direccin real dentro del disco duro del recurso. o La variable Cont se inicializa con el valor 1. o La variable Cache se inicializa con el valor False. o Se agrega al objeto TList este registro. o Se agrega al objeto TStringList la ruta completa del recurso. En caso afirmativo se toma la posicin del recurso en la lista y es asignado en una variable temporal, por medio de la cual haremos referencia al registro que se encuentra almacenado dentro del objeto TList, en realidad un apuntador, y se realizan los siguientes pasos: o El valor de la variable Cont se incrementa en una unidad. o Se comprueba si este nuevo valor es mayor al almacenado en la variable raiting, si es as se prende una bandera llamada copcach, la cual nos sirve para indicarle al sistema que debe de ser subido este registro al cache. o Se comprueba el valor de la variable Cache para saber si ya existe una copia en el cach. En caso afirmativo se prende la bandera buscach.

50

Una vez que se prendieron estas banderas antes de acceder al archivo fsicamente para su envo al sistema cliente se comprueba el valor de la bandera buscach, si es verdadera se hace el cambio en la ruta para que se direccione la lectura a la copia que se encuentra dentro del cach, y se comprueba que en verdad exista este recurso, ya que puede ser que se haya sido reiniciado el sistema despus de una cada del sistema y se haya perdido esta informacin; en caso de que esta informacin no se encuentre en el cach la ruta de acceso al recurso se vuelve a fijar hacia el disco duro y se prende la bandera de copia al cach copcach, si, si existe se coloca la bandera de copiado copcach con el valor False. Lo anterior se hace con el fin de asegurar la existencia del recurso al que se pretende acceder y que las banderas buscach y copcach no estn encendidas al mismo tiempo cuando se hace la lectura del recurso ya que en este caso se intentara escribir y leer sobre el mismo archivo causando un error. Una vez que se asegura que no vaya a haber conflicto en el manejo de los archivos y las banderas de copiado y bsqueda tengan los valores correctos, se precede a la lectura del recurso solicitado para su envo al cliente. Asegurndose de que si la bandera de copiado esta encendida se realice la copia al mismo tiempo en que se va llenando el buffer que sirve como vehculo hacia el socket. Por ultimo se apagan todas las banderas de apoyo y se cierra la conexin con el socket.

6.3.2. Subsistema de respaldo de la lista de recursos visitados.

El sistema cuenta con dos objetos de tipo Timer los cuales sirven para los propsitos de actualizacin y respaldo de la informacin. Ambos son configurable a travs de la hoja de configuracin por medio de un par de objetos de tipo SpinEdit. Uno de estos objetos tipo Timer se programo para que cada cierto periodo de tiempo que el responsable del sitio Web decida se respalde la lista de visitas dentro de un archivo, esto se hace con el fin de que si existe una cada de energa o por alguna razn el sistema operativo dejara de responder la lista de visitas que sirven para la decisin de que recurso debe estar dentro del cach no se pierda del todo y solo sea cuando mas del periodo de tiempo que haya decidido el usuario del sistema para que se realicen estos respaldos. Se fijo como valor mnimo para la actualizacin de esta lista 5 minutos y como mximo el de 180 minutos. Para el respaldo de esta informacin se abre como de con el parmetro de escritura un archivo que se denomino ULV.CPC el cual es un archivo estructurado, basado en la estructura de informacin explicada anteriormente, recorriendo el objeto lista y guardndolo en este archivo.

6.3.3. Actualizacin de los recursos del cach.

Para la tener un control de los archivos que se van almacenando dentro del cach, se hace uso de un objeto del tipo TStringList el cual nos sirve cono un ndice auxiliar. Este objeto se va llenando conforme se van copiando los recursos solicitados por los clientes dentro del cach. Cuando se cumple un periodo de tiempo, definido por el usuario en el rea de configuracin, se hace un recorrido del ndice auxiliar, y para cada objeto definido en el se realiza lo siguiente: Se busca dentro del ndice de la lista de visitas la posicin de la estructura dentro del objeto Tlist. Se comprueba si la variable Cont dentro de la estructura en menor al que contiene la variable Raiting.

51

Si esta condicin se cumple se efectan las siguientes acciones: o Se borra del cach el recurso. o Se coloca la variable cach de la estructura asociada con el valor False. o Se elimina este recurso del ndice auxiliar. En otro caso, se le asigna a la variable cont, de la estructura asociada, el valor 0.

6.4. Pruebas realizadas al sistema.

Las pruebas al sistema se fueron realizando prcticamente durante su implementacin. Las primeras pruebas fueron al sistema de recepcin y envi de paginas web sin tomar en cuenta la realizacin de la parte perteneciente al cach, se comprob la cabecera que se recibe por parte del cliente as como su correcta interpretacin por parte de este sistema servidor. Una vez que las cabeceras fueron comprobadas y correctamente especificadas, se procedi a la creacin de una pagina web en una primera etapa con solo texto la cual fue solicitada por diferentes programas cliente tales como Internet Explorer y Opera, tanto de una maquina remota como tambin por el local host. Comprobando de esta forma que este sistema se comunicaba correctamente con el exterior. En una segunda etapa se realizo esta misma prueba pero agregando elementos multimedia cono son las imgenes a la pagina que se pona a disposicin de los cibernautas. Una vez que la parte del servicio de los recursos fue satisfactoria, se procedi a la creacin del disco cach a travs de los comandos del sistema operativo. A partir de este momento se plantearon las estrategias que se utilizaran para subir los recursos que as lo ameritaran al cach, es decir en que momento era oportuno crear la copia del recurso en el disco RAM y la posterior localizacin y manejo del mismo dentro de este disco. A esta etapa se le realizo como prueba la revisin, por medio del explorador de discos y visualizadores, de que en realidad se hacia la copia y que esta copia fuera correcta, tanto en informacin, as como en la ruta en la que deba estar realizada esta copia. Por ultimo por medio del trazado del sistema se prob que cuando se deba realizar la bsqueda de un recurso dentro del cach esto fuera cierto y no que estuviera enviando siempre la informacin a travs del recurso almacenado dentro del disco duro.

52

Conclusiones, limitaciones y perspectivas

Conclusiones.
El presente proyecto cubri sus expectativas funcionales en un 100%, y sus expectativas de control automatizado en un 90%, esto debido a las restricciones que encontramos por parte del sistema operativo (Windows 9x), puesto que no es posible crear, modificar ni controlar el tamao de los discos RAM en forma dinmica, como se haba propuesto dentro de los objetivos generales del sistema. Tambin se haba propuesto una opcin para el manejo de la cola de espera del servidor, pero despus del estudio de la clase y de la forma en que se defini el sistema de respuesta, se observ que esto no fue necesario, ya que el objeto maneja internamente su cola, este proceso seria conveniente llevarlo a cabo en trabajos posteriores si y solo si se cambia a una arquitectura multihilos. Con respecto al funcionamiento del servidor, y slo con la salvedad de los casos que se enlistaran en el siguiente apartado, su funcionamiento es satisfactorio.

Limitaciones.
Las limitaciones que presenta este proyecto son las siguientes. El servidor que se realiz obedece slo al comando HTTP GET el cual solicita el envo del recurso. A los dems comandos del protocolo los ignora y manda el cdigo de error correspondiente. Aunque el buffer para envio de los recursos solicitados es grande, el objeto socket tiene problemas para enviar un recurso mayor a 65KB. Producindose una prdida completa del recurso que el servidor envi, esto slo se releja en el sistema cliente que recibe solo la cabecera y el recurso el blanco. El sistema no tiene una rutina que le permita crear o reconocer de manera automtica el disco cach; la primera no es posible por causas del sistema operativo. El sistema operativo limita el tamao del disco virtual, sin el uso de algn programa externo, a 6MB conservando la propiedad de nombres largos, de este limite en adelante puede crear discos hasta 16MB con la particularidad de nombres cortos, situacin que no es muy usada en sitios WEB.

Perspectivas
El sistema que se cre en este proyecto es solo el principio de lo que es un verdadero servidor http ya que como se explic este sistema solo responde al comando GET ignorando los otros comandos que contiene este protocolo por lo tanto logrando vencer los limitantes de disco virtual con alguna componente o por medio de algn otro programa de administracin de memoria virtual como disco, este proyecto podra crecer hasta convertirse en una opcin mas eficiente que el servidor mayormente utilizado, como es Apache. Se propone para conseguir esto los siguiente pasos dentro de la primera etapa: La implementacin completa de los comandos que se tenan hasta la versin 1.0 del protocolo HTTP es decir HEAD y POST. La bsqueda de una componente o programa para administracin de Ramdisk grandes. La bsqueda o creacin de un componente que permita supervisar el espacio libre del Ramdisk con el fin de evitar errores de espacio insuficiente en disco en el momento en que se este copiando un nuevo recurso en l

53

En caso de no encontrar ninguna aplicacin o componente que permita la administracin de un Ramdisk mayor a la limitante del sistema operativo, se propone la creacin de una componente, o funciones del sistema que permitan el manejo de mltiples Ramdisk, estudiando previamente si esto es posible dentro del sistema operativo en que se implante.

Y para etapas posteriores, la implementacin completa de los comandos de la especificacin del protocolo HTTP versin 1.1, y dems facilidades descritas en el RFC2068 correspondiente al protocolo HTTP versin 1.1.

54

Glosario
HTTP TCP/IP Rating Proxy URL Firewalls Middlewar e Routers NFS API Ethernet ISDN Stack Router Checksum CRC Gateways MIME (Hypertext Transfer Protocol) Protocolo de Transferencia de HiperTexto (Transmision Control Protocol/Internet Protocol) Protocolo de Control de Transmisin / protocolo de internet Medida de audiencia. Utilizado en las redes de rea local, un proxy es un servidor virtual que realiza la conexin con el servidor real de Internet y a travs del cual se conectan el resto de los ordenadores clientes. Uniform Resource Locator. Se conoce por este nombre a las direcciones dentro de Internet. Sistema tpico que se utiliza para evitar la entrada en los ordenadores de personas no deseadas. Recibe este nombre el conjunto de servicios o facilidades a las que es posible acudir en el mbito de una arquitectura. Se denomina as al dispositivo capaz de dirigir la informacin, dividida en paquetes, por el camino ms idneo, examinando la direccin y el destino y utilizando mapas de red. Network File System. Sistema creado por Sun Microsystem para compartir ficheros dentro de una red con sistema operativo UNIX. (Aplication Program Interfaz) Programa de Aplicacin de interfaz, parte del sistema operativo que provee a las aplicaciones una interfaz de uso comn o interfaz similar. Protocolo de redes de rea local. Estndar para las lneas de telfono digitales permitiendo la transferencia de datos a una gran velocidad. Pila; rea de memoria en la cual se puede almacenar informacin y retirarla en un orden inverso al de entrada. Es un dispositivo que conecta dos redes de rea local (SUMation CHECK)esquema simple de deteccin de errores, donde cada mensaje trasmitido es acompaado de un valor numrico basado en el nmero de grupo de bits del mensaje. Tcnica para detectar errores de transmisin de datos. Es una combinacin de hardware y software que comunica dos tipos diferentes de redes. (Multipart Internet Mail Extension) Extensin de correo electrnico para multipropsitos en Internet, es un estndar que permite la transmisin de correo electrnico de cualquier tipo de archivos (Grficos, Texto, Vdeo, etc.).

55

Bibliografa.
Manual avanzado de Delphi 4. Pablo Daz Mrquez, Antonio Plaza Miguel, Francisco Javier Garca Garca, Jess Mara lvarez Llorente, Nieves Pavn Pulido; Anaya Multimedia 1999. RFC1945 Protocolo HTTP versin 1.0 Network Working Group T. Berners-Lee, R. Fielding, UC Irvine, H. Frystyk; May 1996 RFC2068 Protocolo HTTP versin 1.1 R. Fielding, UC Irvine, J. Gettys, J. Mogul, H. Frystyk, T. BernersLee; January 1997 Aplicaciones de servidor Internet/Intranet con Delphi 3.0 Pedro Agull Soliveres Publicado en Revista Profesional para Programadores (RPP) http://web.urbano.com.mx/soporte/tutoriales/mimes.php3 Tipos MIME listado y pequea explicacin. http://personal.redestb.es/raulgimenez/FrmTCPIP.htm Programacin de aplicaciones Cliente/Servidor con TCP/IP Links varios sobre cliente servidor http://www.inei.gob.pe/cpi/bancopub/libfree/lib616/ http://www.genexus.com/white/spanish/csarti.htm http://members.nbci.com/analista/publica/doc5.htm Protocolos de Red: Protocolo TCP/IP Julio Csar Chavez Urrea jchavez@dnp.gov.co Arquitectura cliente servidor Rafael Salinas Vzquez el-analista@usa.net

56