Introducción

Preámbulo

q LAN alámbrica e inalámbrica

INTRODUCCION A LAS REDES DE DATOS

1.1 Introducción

El desarrollo del hombre desde el nivel físico de su evolución, pasando por su crecimiento en en las áreas sociales y científicas hasta llegar a la era moderna se ha visto apoyado por herramientas que extendieron su funcionalidad y poder como ser viviente.

Durante la época prehistórica, el hombre se valió de la piedra, la madera y el metal para construir extensiones de su cuerpo: Un martillo o punta de lanza de piedra, obsidiana, madera endurecida al fuego para tener un alcance mayor de sus brazos y dominar a las bestias para conseguir el sustento diario.

Después domesticó a los animales y construyó artefactos cada vez más complejos: Un arco para enviar sus "brazos" (flechas) en la distancia y subyugar a animales más peligrosos. Y así como extendió sus brazos, pronto encontró la forma de extender sus piernas para alcanzar lugares más lejanos: fabricó navíos para cruzar ríos, lagos y mares; carretas que los llevaban a lugares distantes más rapido que sus pies y con cargas mayores y hasta refinó las artes que le permitieron tener en el hogar paisajes y monumentos de la naturaleza para darse la sensación de tenerlos a su alcance en todo momento.

Finalmente, y sintiéndose conciente de su habilidad creativa, metódicamente elaboró procedimientos para organizar su conocimiento, sus recursos y manipular su entorno para su comodidad, impulsando las ciencias y mejorando su nivel de vida a costa de sacrificar el desarrollo natural de su ambiente, produciendo así todos los adelantos a los que un gran sector de la población conocemos: automóviles, aeroplanos, trasatlánticos, teléfonos, computadoras, televisiones, etc.

1.1.1 El cómputo electrónico

En el transcurso de todo este desarrollo, lo que nos interesa revisar es la evolución de un sector tecnológico: El cómputo electrónico. Este nació con las primeras computadoras en la década de los 40's con los tubos al vacío y los tableros de control enchufables. Y fue así porque la necesidad del momento era extender la rapidez del cerebro humano para realizar de algunos cálculos aritméticos y procedimientos repetitivos.

1.1.2 Las generaciones de computadoras

El esfuerzo en el cómputo electrónico se reflejó en crear unidades de procesamiento cada vez más veloces conforme la tecnología en la electrónica avanzaba. Así tenemos cuatro generaciones bien definidas: la primera con tubos al vacío, la segunda con transistores, la tercera con circuitos integrados y la cuarta con circuitos integrados que permitieron el uso de computadoras personales y el desarrollo de las redes de datos.

1.1.3 Las redes de datos

Una vez resuelto el problema de extender el poder de cálculo del cerebro humano nació o se comenzó a atacar el problema de compartir los datos y la información que ese poder de cálculo produjo, lo cual nos llevó a inventar la forma de compartir recursos (impresoras, graficadores, archivos, etc) a través de algún medio de transmisión usando una serie de reglas (proocolos) para accesar y manipular dichos recursos.

1.1.4 Los sistemas distribuidos

Las redes de computadoras nos permitieron reunir esfuerzos aislados en esfuerzos conjuntos que producían bienes mayores (sinergia). Sin embargo, en una red la forma de accesar dichos recursos va de la mano con conocer la manera de llegar a esos recursos y saber cómo manipularlos, es decir, no hay transperencia. El siguiente salto tecnológico-filosófico es extender las redes de cómputo (extensiones del poder de cómputo de cerebros humanos aislados) hacia los sistemas distribuidos (una entidad vista como un todo y conformado por múltiples cerebros ubicados en localidades alejadas unas de otras que nos ofrecen servicios y recursos sin importar su ubicación).
Y si Carl Jung está en lo correcto respecto a su teoría del conciente colectivo, parece ser que los adelantos tecnológicos se van agrupando y homogeneizando hacia un conciente colectivo tecnológico. Más información acerca de sistemas distribuidos vea [COL94]

1.2 Redes para las compañias

Cuando una persona física o moral establece una empresa siempre piensa en obtener beneficios y para esto, en muchas ocasiones se requiere de compartir recursos (impresoras, digitalizadores, computadoras, discos duros, archivos, el conocimeinto de personas, etc.) y una solución es tener una red que puede ser local, metropolitana, nacional, amplia o global, dependiendo su amplitud de la dispersión geográfica de los recursos que queremos compartir. Esos recursos deben están disponibles en el momento adecuado y que los datos o información que produzcan sean altamente confiables, esto es, que no sufran deterioro durante su transmisión. En ocasiones, será vital que contemos con réplicas de algunos recursos para que, dado el caso de un desastre en algún púnto de la red, podamos consultar o accesar un recurso similar o de respaldo.

Las compañías también se han dado cuenta que resulta más barato tener una red de computadoras en donde reparten sus procesos productivos que tener una sola supercomputadora en donde concentren todo. Las ventajas de la red son: economía, capacidad de crecimiento más granular, capacidad de soportar fallas, capacidad de tener réplicas más económicas y otras.

1.3 Redes para las personas

El desarrollo tecnológico ha permitido que las computadoras sean accesibles cada vez a mayor número de personas en sus oficinas y en sus hogares, lo cual tambiém implica que se puedan crear micronegocios de alta competitividad y con gastos mínimos. Este tipo de negocios ya no tienen el problema de contar con enormes capitales, ahora su problema es el saber en dónde accesar los recursos que necesitan para proveer bienes y servicios.

Por otro lado, cada vez es más común el usar diveros servicios (correo electrónico, fax, operaciones de compra-venta, reservaciones en hoteles y líneas aéreas, pláticas interactivas persona a persona, acceso al diario en formato electrónico, WWW y videoconferencia) desde una computadora personal en el hogar.

1.4 Aspectos sociales

Desde el momento en que un monitor en casa permite el acceso a tan variados recursos, se corre el riesgo de ver cosas indeseables. Existen en Internet diversos bancos de información accesibles desde Foros de Información (newsgroups), Boletines de Información (Bulletin Board Systems), Páginas de Web, etc.

Muchos de los bancos de datos requieren de algún tipo de permiso (proveer un nombre de usuario y clave de acceso) para accesarlos. Otros permiten el acceso abierto y aquí reside el problema principal. Podemos darnos cuenta de temas que algunos sectores de la población apoyan y que van contra nuestros principios (por ejemplo el tema del aborto, la pornografía, el racismo, etc.) y en algunos casos junto a los datos podemos ver imágenes que ofenden nuestro gusto o que pueden ser traumáticas para nuestros hijos.

Y entonces enfrentamos el problema de que este vasto terreno de información puede estar fuera de control y accesible, tal vez, a personas no aptas o no preparadas para digerirlo. Este problema es similar a controlar las emisiones de las cadenas televisivas donde se sopesan la libertad de expresión contra los principios éticos y morales.

1.5 El peligro de la transculturización

En la época moderna estamos viviendo bajo el paradigma de las modas. Se nos ha estado presionando para que tengamos en el hogar los aparatos electrónicos de moda (videos, televisores, decodificadores de cable, computadoras, teléfonos, fax, alarmas), aparatos de transporte de moda (automóvil, avión, yate, etc.), aparatos personales de moda (rasuradora eléctrica, agenda, calculadora, despertador, teléfono celular, etc.), diversiones de moda (videojuegos, viajes a lugares exóticos, centros nocturnos, clubes, conciertos, encuentros deportivos, etc) y así sucesivamente. La persona que cuenta con el mayor número de estos recursos y diversiones es la más destacada y digna de ser tomada en cuenta en conversaciones y homenajes, aunque no produzca ningún bien tangible para la sociedad. Todos estos acercamientos a las modas llevan el tiítulo lavacerebros de "progreso", "modernización", etc. y cambian totalmente la calidad de vida de las personas y la población en general.

Es tan fuerte el llamado a la "modernización", que las sociedades, al tener disponible el acceso a los medios electrónicos (por ejemplo Internet), rápidamente se van dando cuenta de costumbres y adelantos tecnológicos en todo el mundo y seguramente, si tienen o llegan a tener el recurso económico van a tratar de comprar esos adelantos. ¿ Qué país se resiste al progreso y al modernismo ? ¿ Hay otros caminos para vivir mejor ?

¿Existe alguna otra forma de vivir que no sea el de ser dueño o empleado de alguna empresa, ir a trabajar por la mañana, regresar en la noche, repetir eso todos los días y tal vez descansar los fines de semana? Ah! Y mantenerse a la moda.

Una pregunta es: ¿Cuál será la correlación entre el porcentaje de cremiento al acceso a Internet y el nivel de transculturización?

Otra pregunta es: ¿ Será todo esto un camino hacia una homogeneización de la forma de pensamiento de una sociedad global?

2. TIPOS DE REDES POR SU DISPERSION

Al crear una red, se toman en cuenta dos factores principales: el medio físico de transmisión y las reglas que rigen la transmisión de datos. Al primer factor le llamamos nivel físico y al segundo protocolos.

En el nivel físico generalmente encontramos señales de voltaje que tienen un significado preconcebido. Esas señanles se agrupan e interpretan para formar entidades llamadas paquetes de datos. La forma como se accesan esos paquetes determinan la tecnología de transmisión y se aceptan dos tipos: "broadcast" y "point-to-point".

Las redes de tipo "broadcast" se caracterizan porque todos los miembros (nodos) pueden accesar todos los paquetes que circulan por el medio de transmisión.

Las redes punto a punto sólo permiten que un nodo se conecte a otro en un momento dado.

Por la extensión de las redes "broadcast" o "punto a punto", podemos clasificarlas de acuerdo a la tabla siguiente.

2.1 Redes de Area Local

Las redes de área local son el punto de contacto de los usuarios finales. Su finalidad principal es la de intercambiar información entre grupos de trabajo y compartir recursos tales como impresoras y discos duros. Se caracterizan por tres factores: extensión, su tecnología de transmisión y su topología.

2.1.1 Extensión de las redes de área local

Su extensión va de unos cuantos metros hasta algunos kilómetros. Esto permite unir nodos que se encuentran en una misma sala de cómputo, en un edificio, en un campus o una empresa mediana y grande ubicada en una misma locación.

2.1.2 Tecnologías de transmisión de las redes de área local

Las redes tradicionales operan con medios de transmisión tales como cable de par trenzado (Unshielded Twisted Pair), cables coaxial (ya casi obsoleto porque presenta muchos problemas), fibra óptica (inmune a la mayoría de interferencias), portadoras de rayo infrarojo o láser, radio y microondas en frecuencias no comerciales. Las velocidades en las redes de área local van desde 10 Megabits por segundo ( Mbps) hasta 622 Mbps.

2.1.3 Topologías de las redes de área local

La topología de una red se refiere a la forma que ésta toma al hacer un diagrama del medio físico de transmisión y los dispositivos necesarios para regenerar la señal o manipular el tráfico. Las topologías generales son: anillo (ring), dorsal (bus), dorsal dual (dual bus), estrella (star), árbol (tree) y completas.

Las topologías de anillo, dorsal y árbol se adecuan mejor para redes de tipo "broadcast" y el resto para redes de tipo punto a punto.

Los estándares más comunes son el IEEE 802.3 llamado Ethernet y el IEEE 802.5 llamado Tojen Ring. Ethernet opera entre 10 y 100 Mbps. En este estándard, todo nodo escucha todos los paquetes de está red broadcast, saca una copia y examina el destinatario. Si el destinatario es el nodo mismo, lo procesa y si no lo deshecha para escuchar el siguiente. Para enviar un paquete escucha cuando el medio de transmisión esté libre. Si ocurre que dos nodos enviaron un paquete al mismo tiempo, se provoca una colisión y cada nodo vuelve a retransmitir su paquete después de esperar un tiempo aleatorio. Token Ring opera entre 4 y 16 Mbps y utiliza una ficha (token) que permite enviar paquetes al nodo que la posee mientras los otros escuchan. Una vez que un nodo termina de enviar paquetes, pasa la ficha a otro nodo para que transmita.

2.2 Redes de Area Metropolitana

Una red de área metropolitana es una versión más grande de una LAN en cuanto a topología, protocolos y medios de transmisión que abarca tal vez a un conjunto de oficinas corporativas o empresas en una ciudad. Las redes deservicio de televisión por cable se pueden considerar como MANs y, en general, a cualquier red de datos, voz o video con una extensión de una a variuas decenas de kilómetros. El estándard IEEE 802.6 define un tipo de MAN llamado DQDB por sus siglas en inglés Distributed Queue Dual Bus. Este estándard usa dos cables half-duplex por los cuales se recibe y transmiten voz y datos entre un conjunto de nodos.

2.3 Redes de Area Amplia

Una red de área amplia se expande en una zona geográfica de un país o continente. Los beneficiarios de estas redes son los que se ubican en nodos finales llamados también sistemas finales que corren aplicaciones de usuario (por ejemplo, algún procesador de palabras o un navegador de WWW). A la infraestructura que une los nodos de usuarios se le llama subred y abarca diveros aparatos de red (denominados en general como routers o enrutadores) y líneas de comunicación que une a las redes de área local. El término de subred también se aplica a una técnica para optimixzar el tráfico en una red de área local de tamaño medio.

En la mayoría de las redes de área amplia se utilizan una gran variedad de medios de transmisión para cubrir grandes distancias. La transmisión puede efectuarse por microondas, por cable de cobre, fibra óptica o alguna combinación de los anteriores. Sin omportar el medio, los datos en algún punto se convierten e interpretan como una secuencia de unos y ceros para formar marcos de información (frames), luego estos frames son ensamblados para formar paquetes y los paquetes a su vez construyen archivos o registros específicos de alguna aplicación.

Las redes clásicas se caracterizan porque utilizan routers para unir las diferentes LANs. Como en este caso los paquetes viajan de LAN en LAN a través de ciertas rutas que los routers establecen, siendo dichos paquetes almacenados temporalmente en cada router, a la subred que usa este pricipio se le conoce como punto-a-punto, almacena-y-envía o de enrutado de paquetes (point-to-point, store-and-forward, packet-switched).

Las topologías comunes en una red punto a punto son: de estrella, annilo, árbol, completa, anillos intersectados e irregular.

La posibilidad de usar el aire como medio de transmisión nos da lugar a las redes inalámbricas. Se pueden construir usando estaciones de radio o satélites que envían ondas a diferentes frecuencias para enlazar los correspondientes enrutadores. Como el alcance de estas ondas no puede ser restringido en un cierto radio, se deben tomar algunas medidas especiales para no entrar en conflicto con otras ondas y para restringir el acceso.

2.4 Red Global Internet e internets

La red Internet es aquella que sa ha derivado de un proyecto del departamento de defensa de Estados Unidos y que ahora es accesible desde más de 2 millones de nodos en todo el mundo, y cuyos servicios típicos son las conexiones con emulación de terminal telnet , la transferencia de archivos ftp , el W W W , el correo electrónico , los foros de información globales NetNEWS .

Por otro lado, se consideran como internets (con la letra "i" minúscula) a aquellas redes públicas o privadas que se expanden por todo el mundo. El asunto interesante es que estas internets pueden valerse del Internet en algunos tramos para cubrir el mundo. La restricción mayor para que una red privada se expanda en el mundo usando Internet es que puede verse atacada por usuarios del Internet. Un esquema de seguridad para este caso puede ser que, para las LANs que conforman la internet privada, cada una de ellas encripte su información antes de introducirla a Internet y se decodifique en las LANs destinos, previo intercambio de las claves o llaves de decodificación. Este tipo de esquemas se pueden lograr con el uso de firewalls .

3. PROTOCOLOS DE COMUNICACION

Un protocolo es un conjunto de reglas que indican cómo se debe llevar a cabo un intercambio de datos o información. Para que dos o más nodos en una red puedan intercambiar información es necesario que menejen el mismo conjunto de reglas, es decir, un mismo protocolo de comunicaciones.

Debido a la gran variedad de protocolos, se hizo necesario estandarizarlos y para eso se tomó un diseño estructurado o modular que produjo un modelo jerárquico conocido como modelo de referencia OSI (Open Systems Interconnection).

3.1 Jerarquías de protocolos

La idea central detrás del modelo es que, para que una aplicación que reside en un nodo A establezca comunicación con una aplicación en un nodo B, debe usar los servicios de una capa de la red. Llamemos a esa capa "capa de aplicación". La capa de aplicación le brinda un conjunto de servicios a las aplicaciones pero a su vez depende de otra capa inferior para trabajar. Llamemos a esa capa "capa de transporte de paquetes". La capa de transporte de paquetes es todo lo que necesita la de aplicaión para trabajar en la red y, a su vez, la capa de aplicación es todo lo que necesita la de transporte para comunicarse con la aplicación, de manera que tenemos un flujo de información en ambos sentidos. Bajo la capa de transporte residen otras capas con relaciones similares a las ya descritas, hasta llegar a la capa que se encarga del problema del medio físico por el cual viaja finalmente la información de manera electrónica. Llamemos a esta última capa "capa física". Por ejemplo, esta capa podría encargarse de detectar señales de voltaje en un cable de cobre y agruparlas como unos y ceros para formar un byte, y luego unir los bytes hasta formar una cadena de cierto tamaño predefinido por el protocolo y pasar esa cadena a la capa inmediata superior.

Los principios que rigen este diseño modular son:

Cada capa debe ser lo suficientemente pequeña para que sus funciones sean fácilmente entendibles.
Cada capa debe ser lo suficientemente amplia para que realice un conjunto de funciones que sean significativas para el protocolo en su conjunto.
Cada capa debe ofrecer un conjunto bien definido de funciones hacia la capa superior.
Cada capa debe poder hacer su trabajo usando los servicios provistos por la capa inferior.

En cada capa del modelo de referencia se puede hablar del protocolo de la capa n y cada entidad que reside en una capa usa una interfase para comunicarse con la capa inferior o con la capa superior. Esa interfase consta de un conjunto de operaciones y servicios bien definidos según los principios antes descritos. En un momento dado, se puede decir que existe una comunicsción virtual directa entre la capa n de una aplicación en un nodo con la capa n de otra aplicación en otro nodo.

Podemos decir que el conjunto de capas, sus principios y sus protocolos definen una arquitectura de red. De esta forma es sencillo que un fabricante produzca aparatos de red para algún nivel o niveles de la arquitectura de red.

3.2 Aspectos de diseño

Dependiendo de las funciones y servicios que cada capa debe proveer y usar, se deben atacar algunos problemas interesantes al diseñar la arquitectura de red.

En primer lugar, dado que en una red existen muchos nodos que quieren comunicarse entre sì, debe existir un mecanismo de direccionamiento que sea capaz de:

Identificar de manera única a una conexión que parte de un nodo n a un nodo x que está siendo requerida por procesos en dichos nodos.
Identificar de manera única para cada conexión a qué tipo de servicio pertenece.
Si la interfase soporta mensajes de tamaño restringido, se debe proveer un mecanismo de identificación de mensajes pequeños que pertenecen a uno mayor.
Identificar en un mismo medio diferentes canales activos simultáneos.

Debido a que algunos medios físicos no están libres de errores, se debe tener un mecanismo para detectarlos y en alguna de las capas debe haber un mecanismo para corregir el error.

Debido a los medios no libres de errores, en el caso de no poder corregir un error se debe pedir la retransmisión de datos.

Debido a que se puede perder la comunicación entre dos nodos, debe existir un mecanismo para asignar un tiempo máximo de espera en el envío o recepción de datos (timeout).
El protocolo debe contemplar la posibilidad de manejar un medio simplex, half duplex o full duplex.

3.3 Interfases y servicios

Como ya vimos, cada capa tiene un conjunto de operaciones que realizar y un conjunto de servicios que usa de otra capa. De esta manera identificamos como usuario de servicio a la capa que solicita un servicio y como proveedor a quien la da. Cuando una entidad se comunica con otra ubicada en la misma capa pero en diferentes nodos se dice que se establece comunicación entre entidades interlocutoras (peer entities).

Cada capa tiene un conjunto de servicio que ofrecer, el punto exacto donde se puede pedir el servicio se llama punto de acceso al servicio (Service Access Point, SAP). Por ejemplo, en el servicio telefónico se ofrecen conferencias persona a persona, el SAP es la roseta o jack donde se conecta el teléfono y la dirección es el número telefónico con quien se desea hablar.

En cada capa, la entidad activa recibe un bloque de datos consistente de un encabezado que tiene significado para el protocolo de esa capa y un cuerpo que contiene datos para ser procesados por esa entidad o que van dirigidos a otra capa.

3.4 Relaciones entre servicios y protocolos

Las capas ofrecen servicios de dos tipos generales: orientadas a conexión y no orientadas a conexión y los servicios obtenidos cumplen con cierta calidad de servicio que puede ser un servicio confiable (reliable) o no confiable (non reliable).

3.4.1 Servicios orientados a conexión

Los servicios orientados a conexión se caracterizan porque cumplen tres etapas en su tiempo de vida:

Etapa 1: Negociación del establecimiento de la conexión.
Etapa 2: Sesión de intercambio de datos
Etapa 3: Negociación del fin de la conexión

Los servicios orientados a conexión pueden ser considerados como "alambrados", es decir, que existe un conexión alambrada entre los dos interlocutores durante el tiempo de vida de la conexión.

3.4.2 Servicios no orientados a conexión

Los servicios no orientados a conexión carecen de las tres etapas antes descritas y en este caso los interlocutores envían todos paquetes de datos que componen una parte del diálogo por separado, pudiendo éstos llegar a su destino en desorden y por diferentes rutas. Es responsabilidad del destinatario ensamblar los paquetes, pedir retransmisiones de paquetes que se dañaron y darle coherencia al flujo recibido. Los servicios no orientado a conexión se justifican dentro de redes de área local en donde diversos estudios han demostrado que el número de errores es tan pequeño que no vale la pena tener un mecanismo de detección y correción de los mismos.

3.4.3 Servicios confiables y no confiables

Se dice que un servicio es confiable si nos ofrece una transmisión de datos libre de errores. Para cumplir este requisito, el protocolo debe incluir mecanismos para detectar y/o corregir errores. La corrección de errores puede hacerse con información que está incluida en en un paquete dañado o pidiendo su retransmisión al interlocutor. También es común que incluya mecanismos para enviar acuses de recibo cuando los paquetes llegan correctamente.

Se dice que un servicio es no confiable si el protocolo no nos asegura que la transmisión está libre de errores y es responsabilidad del protocolo de una capa superior (o de la aplicación) la detección y corrección de errores si esto es pertinente o estadísticamente justificable.

A un servicio que es a la vez no orientado a la conexión y no confiable se le conoce como "datagram service". Un servicio que es no orientado a la conexión pero que incluye acuse de recibo se le conoce como " acknowledged datagram service ". Un tercer tipo de servicio se le llama " request-reply " si consiste de un servicio no orientado a conexión y por cada envío de datos se espera una contestación inmmediata antes de enviar el siguiente bloque de datos. Este último servicio es útil en el modelo cliente-servidor.

Los servicios no orientado a conexión se justifican dentro de redes de área local en donde diversos estudios han demostrado que el número de errores es tan pequeño que no vale la pena tener un mecanismo de detección y correción de los mismos.

4. EL MODELO DE REFERENCIA OSI

La Organización Estándares Internacionales (ISO por sus iniciales en Inglés) emitió un modelo de referencia para la interconexión de sistemas abiertos (Open Systems Interconnection OSI) el cual formaliza el modelo prototipo explicado en secciones anteriores.

4.1 Capas del modelo de referencia

4.1.1 Capa Física

La capa física tiene que ver con el envío de bits en un medio físico de transmisión y se asegura de que si de un lado del medio se envía un 1 del otro lado se reciba ese 1. También tiene que ver con la impedancia, resistencia y otras medidas eléctricas o electrónicas del medio y de qué forma tiene (tamaño, número de patas) en conector del medio y cuáles son los tiempos aprobados para enviar o recibir una señal. También se toma en cuenta si el medio permite la comunicación simplex, half duplex o full duplex.

4.1.2 Capa de Ligado

En esta capa se toman los bits que entrega la capa física y los agrupa en algunos cientos o miles de bits para formar marcos de bits. Se puede hacer en este nivel un chequeo de errores y si no los hay enviar un marco de acuse de recibo (acknowledge). Para detectar los límites de un marco se predefinen secuencias de bits de control. Si un marco se pierde o daña en el medio físico este capa se encarga de retransmitirlo, aunque en ocasiones dicha operación provoca que un mismo frame se duplique en el destino, dado el caso es obligación de esta capa detectar tal anomalía y corregirla. También en esta capa se decide cómo accesar el medio físico.

4.1.3 Capa de Red

La capa de red se encarga de controlar la operación de la subred (medios físicos y dispositivos de enrutado). Una tarea primordial es decidir cómo hacer que los paquetes lleguen a su destino dados un origen y un destino en un formato predefinido por un protocolo. Otra función importante en este nivel es la resulocuón de cuellos de botella. En estos casos se pueden tener varias rutas para dar salida a los paquetes y en base a algunos parámetros de eficiencia o disponibilidad se eligen rutas dinámicas de salida. Otra función que se puede obtener en esta capa es el registro o reporte del tipo y cantidad de paquetes que circulan por el enrutador para efectos de cobro o de obtención de estadísticas.

4.1.4 Capa de Transporte

La obligación en esta capa es la de tomar datos de la capa de sesión y asegurarse que dichos datos llegan a su destino. En ocasiones los datos que vienen de la capa de sesión exceden el tamaño máximo de transmisión (Maximum Transmission Unit MTU) de la interfaz de red, por lo cual es necesario partirlos y enviarlos en unidades más pequeñas, lo cual da orígen a la fragmentación y ensamblado de paquetes cuyo control se realiza en esta capa.

Una vez que esta capa se encarga de procesar datos de la capa de sesión y servir de interfase con la de red, podemos afirmar que su función es la de separar a las capas superiores de los posibles cambios en el hardware de red.

Otra función en esta capa es la de multiplexar varias conexiones que tienen diferentes capacidades de transmisión para ofrecer una velocidad de transmisión adecuada a la capa de sesión. Por ejemplo, se puede decidir en un momento dado que una conexión es muy cara y que mejor se multiplexe sobre una conexión existente más barata para tener un ahorro. Estas decisiones son transparentes para la capa de sesión.

A partir de la capa de transporte (inclusive) las capas ofrecen servicios de interlocutor a interlocutor, esto es, que un programa de red en un nodo platica con otro programa similar en otro nodo de la red. En las capas inferiores esto no es posible ni requerido.

La última labor importante de la capa de transporte es ofrecer un mecanismo de nombrado que sirva para identificar y diferenciar las múltiples conexiones existentes, así como determinar en qué momento se inician y se terminan las conversaciones; es decir, en esta capa hay un mecanismo de control de flujo. Por ejemplo, si el usuario "operador" en el nodo "A" quiere iniciar una sesión de trabajo remoto (telnet) en un nodo "B", existirá una conexión que debe ser diferenciada de la conexión que el usuario "luis" necesita para transferir un archivo (ftp) del nodo "B" al nodo "A".

4.1.5 Capa de Sesión

Esta capa ofrece el servicio de establecer sesiones de trabajo entre nodos diferentes de una red. Permite el transporte de datos (spoprtado por la capa de transporte) y añade algunas facilidades para el establecimiento del flujo de datos.

Esta capa decide a quíen se le hace caso para transmitir datos entre las múltiples conexiones, una manera de hacerlo es proveer de fichas a los participantes de una conexión, de manera que aquél que tenga la ficha es el que puede transmitir (lo cual es útil en un medio half duplex). Otro servicio de esta capa es la sincronización y el establecimiento de puntos de chequeo. Por ejemplo, si se hace necesario transferir un archivo muy garnde entre dos nodos que tienen una alta probabilidad de sufrir una caída, es lógico pensar que una transmisión ordinaria nunca terminaría porque algún interlocutor se caerá y se perderá la conexión. La solución es que se establezcan cada pocos minutos un punto de chequeo de manera que si la conexión se rompe más tarde se pueda reiniciar a partir del punto de chequeo, lo cual ahorrará tiempo y permitirá tarde o temprano la terminación de la transferencia.

4.1.6 Capa de Presentación

La capa de presentación nos provee de facilidades para que podamos transmitir datos con alguna sintaxis propia para nuestras aplicaciones o para nuestro nodo. Existen computadoras que interpretan sus bytes de una manera diferente que otras (Big Endian versus Little Endian). En esta capa es posible convertir los datos a un formato independiente de los nodos que intervienen en la transmisión.

4.1.7 Capa de Aplicación

En esta capa se encuentran aplicaciones de red que nos permiten explotar los recursos de otros nodos. Dicha explotación se hace, por ejemplo, a través de una emulación de una terminal que trabaja en un nodo remoto, interpretando una gran variedad de secuencias de caracteres de contro que nos permiten desplegar en la terminal local los resultados, aún cuando éstos sean gráficos. Otra forma de explatación se da cuando transmitimos un archivo de una computadora que almacena sus archivos en un formato dado a una computadora de formato distinto. Es posible que el programa de transferencia realice las conversiones necesarias de manera que el archivo puede usarse inmediatamente bajo alguna aplicación.

4.2 Transmisión de datos en el modelo OSI

Un envío de datos típico bajo el model de referencia OSI comienza con una aplicación P en un nodo cualquiera de la red. P genera los datos D que quiere enviar a su contraparte en otro nodo. Le pasa los datos D a la capa de aplicación .

La capa de aplicación toma los datos y los encapsula añadiendo un encabezado que contiene información de control o que puede estar vacío. El paquete completo resultante se lo pasa a la capa de presentación.

La capa de presentación lo recibe y no intenta siquiera decodificar o separar los componentes del paquete, sino que lo toma como datos y le añade un encabezado con información de control de esta capa y el paquete resultante se lo envía a la capa de sesión.

La capa de sesión recibe el paquete, que también son sólo datos para ella y le añade un encabezado de control. El resultado se lo envía a la capa de transporte.

La capa de transporte recibe todo el paquete como datos y le añade su propio encabezado de control creando otro paquete que envía a la capa de red, la cual se encargará de enrutarlo a su destino apropiado, entre otras actividades que realiza. Las capas de red, ligado de datos y física toman, respectivamente, el paquete que les envía la capa superior y añaden a éste un encabezado definido por el protocolo que corresponde a cada capa y pasan el resultada a la capa inferior. La capa física traducirá el último paquete a las señales apropiadas para que viajen por el medio físico hasta el nodo destino.

En el nodo destino, la capa física toma los paquetes y les quita el encabezado de la capa física, pasando el paquete resultante a la capa de ligado de datos. La capa de ligado lo recibe y le quita el encabezado de esta capa, pasando el resultado a la capa de red, quien lo toma y le quita el encabezado de red, pasando el paquete a la capa de transporte que elimina el encabezado de transporte y pasa el resultado a la capa de sesión, quien también le quita el encabezado respectivo y pasa el paquete a la capa de presentación, que a su vez le quita el encabezado de presentación y le pasa el paquete a la capa de aplicación que, finalmente, le quita el último encabezado y le entrega el paquete de datos reales a la aplicación en el nodo destino.

De manera virtual, se establecen conexiones directas entre las capas del mismo nombre de los dos diferentes nodos. Por ejemplo, el paquete que envía la capa de red es interpretado por la capa de red en el destino y no por otra capa. Para las capas inferiores de la de red, dicho paquete fue interpretado como datos, y para las capas superiores (transporte,sesión, presentación y aplicación) como un paquete compuesto de datos y encabezado.

Por otro lado, todas las capas, excepto la de aplicación, procesan los paquetes realizando operaciones que sólo sirven para verificar que el paquete de datos real esté íntegro o para que éste llegue a su destino, sin que los datos por sí mismos sufran algún cambio.

5. EL MODELO DE REFERENCIA TCP/IP

La Agencia de Proyectos de Investigación Avanzada del Departamento de Defensa de los Estados Unidos de Norteamérica definieron un conjunto de reglas que establecieron cómo conectar computadoras entre sí para lograr el intercambio de información, soportando incluso desastres mayores en la subred. Fue así como se definió el conjunto de protocolos de TCP/IP ( TCP/IP Internet Suite of Protocols). Para los años 80 una gran cantidad de instituciones estaban interesados en conectarse a esta red que se expandió por todo EEUU. La Suite de TCP/IP consta de 4 capas principales que se han convertido en un estándard a nivel mundial.

5.1 Las capas del modelo TCP/IP

Las capas de la suite de TCP/IP son menos que las del modelo de referencia OSI, sin embargo son tan robustas que actualmente une a más de 3 millones de nodos en todo el mundo.

La capa inferior, que podemos nombrar como física respecto al modelo OSI, contiene varios estándares del Instituto de Ingenieros Electrónicos y Eléctricos (IEEE en inglés) como son el 802.3 llamado Ethernet que establece las reglas para enviar datos por cable coaxial delgado (10Base2), cable coaxial grueso (10Base5), par trenzado (10Base-T), fibra óptica (10Base-F) y su propio método de acceso, el 802.4 llamado Token Bus que puede usar estos mismos medios pero con un método de acceso diferente, el X.25 y otros estándares denominados genéricamente como 802.X.

La siguiente capa cumple, junto con la anteriormente descrita, los niveles del modelo de referencia 1,2 y 3 que es el de red. En esta capa se definió el protocolo IP también conocido como "capa de internet". La responsabilidad de este protocolo es entregar paquetes en los destinos indicados, realizando las operaciones de enrutado apropiadas y la resolución de congestionamientos o caídas de rutas.

La capa de transporte es la siguiente y está implantada por dos protocolos: el Transmission Control Protocol y el User datagram Protocol. El primero es un protocolo confiable (reliable) y orientado a conexiones, lo cual significa que nos ofrece un medio libre de errores para enviar paquetes. El segundo es un protocolo no orientado a conexiones (connectionless) y no es confiable (unreliable). El TCP se prefiere para la transmisión de datos a nivel red de área amplia y el otro para redes de área local.

La última capa definida en la suite de TCP/IP es la de aplicación y en ella se encuentran decenas de aplicaciones ampliamente conocidas actualmente. Las más populares son el protocolo de transferencia de archivos (FTP), el emulador de terminales remotas (Telnet), el servicio de resolución de nombres (Domain Name Service DNS), el WWW, el servicio de correo electrónico (Simple Mail Transfer Protocol SMTP), el servicio de tiempo en la red (Network Time Protocol NTP), el protocolo de transferencia de noticias (Network News Transfer Protocol NNTP) y muchos más.

5.2 Comparación con el modelo OSI

El model TCP/IP no tiene bieen divididas las capas de ligado de datos, presentación y sesión y la experiencia ha demostrado que en la mayoría de los casos son de poca utilidad [Tan96].

Los estándares 802.X junto con el protocolo IP realizan todas las funciones propuestas en el modelo OSI hasta la capa de red. Los protocolos TCP y UDP cumplen con la capa de transporte. Finalmente, las aplicaiones ya mencionadas son ejemplos prácticos y reales de la funcionalidad de la capa de aplicación.

5.2.1 Tipos de Comunicaciones

El modelo OSI propone tener comunicaciones orientadas y no orientadas a conexión en la capa de red, mientras que TCP/IP sólo ofrece no orientadas a conexión, mientras que OSI propone en el nivel de transporte comunicaciones orinetadas a conexión mientras que TCP/IP ofrece orientadas y no orientadas a conexión en dicha capa. [Tan96].

5.2.2 Críticas al modelo OSI

El modelo OSI tiene siete niveles que fueron propuestos debido a que IBM tenía su protocolo de siete capas SNA (Systems Network Architecture) y el comité no quiso ir contra la corriente peleando contra la preponderancia de IBM en esos días [Tan96]. Por otro lado, mientras se planeaba y discutía el modelo OSI, ya se estaba trabajando y creando redes usando TCP/IP, de manera que al estar disponible el trabajo del modelo OSI la mayoría de las compañías ya no quiso hacer el esfuerzo de migrar sus productos. En general, las críticas más importantes al modelo OSI y sus implantaciones se pueden resumir en los siguientes puntos [Tan96]:

El conjunto total de la pila de protocolos resultó sere demasiada compleja para entender e implantar.
Las capas contienen demasiadas actividades redundantes, por ejemplo, el control de errores se integra en casi todas las capas siendo que tener un único control en la capa de aplicación o presentación sería suficiente.
La enormidad de código que fue necesario para implantar el modelo OSI y su consecuente lentitud hizo que la palabra OSI se asociara a "calidad pobre", lo cual contrstó con TCP/IP que se implantó exitosamente en el sistema operativo UNIX y era gratis.
OSI tuvo poca aceptación en EEUU porque la mayoría de la gente pensó que era un estándard implantado por la comunidad europea, y todos sabemos que la tecnología o deporte que no es inventado en EEUU es discriminada rápidamente.

5.2.3 Críticas al modelo TCP/IP

El modelo TCP/IP primero fue llevado a la práctica y luego fue descrita su funcionalidad, por lo cual se acepta que no puede usarse para describir otros modelos. Las críticas en general se resumen a continuación:

El modelo no distingue bien entre servicios, interfaces y protocolos, lo cual afecta el diseño de nuevas tecnologías en base a TCP/IP.
Las capas que le faltan con respecto al modelo OSI ni siquiera se mencionan y eso es lógico porque TCP/IP fue un predecesor de OSI.
No se puede hablar propiamente de un modelo TCP/IP, pero se tiene que discutir acerca de él forzados por su uso en todo el mundo.
Algunos de los protocolos de TCP/IP fueron creados por estudiantes y para solucionar problemas viejos y las necesidades modernas requieren de otros protocolos.

Conluyendo, el modelo OSI es muy bueno como marco teórico para describir la funcionalidad de los dispositivos y protocolos que hacen funcionar una red, pero se acepta que las capas de sesión y presentación no son muy útiles [Tan96], por lo cual generalmente se usa un modelo reducido con las capas física, ligado de datos, red, transporte y apicación.

5.3 Programación en red usando sockets bajo UNIX.

BSD Sockets: Un Tutorial Introductorio
por Jim Frost y Enrique Sanchez (traducción y ejemplos)
November 22, 1989, May 1996

Los aprendices de UNIX muchas veces encontramos conceptos y facilidades que son difíciles de aprender en primera instancia. Uno de esos conceptos es la facilidad de SOCKETS. En este tutorial se explica qué son, cómo se usan y se muestran ejemplos de código fuente para su uso correcto.

Una Analogía ¿ Qué es un socket?

El socket es el método de BSD para llevar a cabo la comunicación entre procesos (Interprocess Communication o IPC). Esto quiere decir que un socket se usa para permitir que un proceso pueda platicar o intercambiar información con otro, de una manera muy parecida a cómo se usa una línea telefónica entre dos personas.

La analogía del teléfono es buena, y será usada en repetidas ocasiones para describir el comportamiento de un socket.

Instalación de un Nuevo Teléfono ¿ Cómo escuchar en la red por conexiones de socket ?

Para que una persona reciba llamadas telefónicas, primero necesita tener una línea instalada. Para que un socket pueda aceptar peticiones primero debe crearse el socket. Para crear el socket se deben seguir algunos pasos. El primero es preparar el lugar para poner el teléfono, en este caso, debemos hacer el socket con el comando socket() .

Como los sockets pueden crearse de varios tipos, debemos especificar de qué tipo lo queremos al crearlo. Una opción es indicar el formato de direccionamiento del socket. Así como el correo electrónico usa un esquema diferente para entregar correspondencia a como un teléfono funciona para lograr la comunicación, asi pueden diferir los sockets. Los dos esquemas más comunes de direccionamiento son AF_UNIX y AF_INET . El direccionamiento AF_UNIX usa senderos ( pathnames ) para identificar a los sockets y son muy útiles para la comunicación entre procesos en una misma computadora. El otro esquema, AF_INET usa direcciones de Internet (Internet Protocol Addresses o Direcciones IP) que consisten en cuatro números decimales escritos de la forma #1.#2.#3.#4, por ejemplo, (140.148.101.26). Además, cada computadora con una dirección IP puede manejar varios tipos de conexiones al mismo tiempo, cada una de ellas en un puerto distinto.

Otra opción que debemos proveer cuando creamos un socket es el tipo de socket, que indique cómo preferimos que los datos viajen por la red. Los dos tipos más comunes son SOCK_STREAM y SOCK_DGRAM . La opción SOCK_STREAM indica que los datos viajan por la red como una secuencia de letras una tras otra, mientras que SOCK_DGRAM indica que los mismos lo harán en grupos (llamados datagramas). Nosotros preferiremos SOCK_STREAM.

Después de crear un socket, debemos darle una dirección para que escuche llamadas, así como nosotros damos nuestro número telefónico a nuestros conocidos para que nos llamen. La función bind() es usada para hacer esta tarea.

Los sockets de tipo SOCK_STREAM tienen la capacidad de encolar llamadas pendientes cuando estamos ocupados en atender una llamada en particular. La función listen() es usada para establecer el máximo número de llamadas que somos capaces de encolar. Aunque no es obligatorio invocar o usar a listen(), es muy recomendable hacerlo para procesar llamadas pendientes.

Las siguientes funciones muestran cómo usar socket(), bind() y listen() para establecer un socket que acepta llamadas:

/* código para establecer un socket;
original de bzs@bu-cs.bu.edu
*/

int establece(num_puerto)
u_short num_puerto;
{ char minombre[MAXHOSTNAME+1];
int s;
struct sockaddr_in sa;
struct hostent *hp;

bzero(&sa,sizeof(struct sockaddr_in)); /* limpia nuestra direccion*/
gethostname(minombre,MAXHOSTNAME); /*Obtengo mi nombre */

hp= gethostbyname(minombre); /* Determina nuestra información */
if (hp == NULL) /* Aborto si no existo!! */
return(-1);

sa.sin_family= hp->h_addrtype; /* Esta es nuestra direccion*/
sa.sin_port= htons(num_puerto); /* Este es nuestro puerto */

/* crea socket */
if ((s=socket(AF_INET,SOCK_STREAM,0))<0)
return(-1);

if (bind(s,&sa,sizeof sa,0) < 0) {
close(s);
return(-1); /* Asigna la dirección al socket */
}

listen(s, 3); /* Encolo hasta 3 llamadas */

return(s);
}

Después de que creamos el socket, debemos esperar que alguien nos llame. La función accept() es usada para hacer esto. Esta función esperara a que alguien llame y cuando esto sucede, accept() hace una copia del teléfono original y nos la entrega. El teléfono original se queda esperando otra llamada.

La siguiente función puede ser usada para aceptar una llamada en un socket:

int descuelga_tel(s)
int s; /* s es un socket creado con establece() */
{ struct sockaddr_in isa; /* dirección del socket */
int i; /* tamano de la dirección */
int t; /* socket de la conexion */

i = sizeof(isa); /* obtiene el tamano */
getsockname(s, & isa,&i); /* obtiene el nombre del socket */

if ((t = accept(s, & isa,&i)) < 0) /* acepta la llamada y duplica */
return(-1);

return(t);
}

Así como en una central telefónica se reciben llamadas que son delegadas a una persona mientras la recepcionista se queda esperando nuevas llamadas, en UNIX usamos la función fork() para crear un nuevo proceso que atienda la llamada actual. El siguiente código muestra cómo usar la función establece() y descuelga_tel() para controlar varias conexiones simultáneas:

#include <errno.h> /* Encabezados necesarios*/
#include <signal.h> /* vea "man bind" */
#include <stdio.h> /* vea "man listen */
#include <sys/types.h> /* vea "man accept */
#include <sys/socket.h>
#include <sys/wait.h>
#include <netinet/in.h>
#include <netdb.h>

#define PORTNUM 50000 /* Puerto donde vamos a escuchar */

void bomberazo(), haz_algo();

main()
{ int s, t;

if ((s= establece(PORTNUM)) < 0) { /* instala el teléfono */
perror("establece");
exit(1);
}

signal(SIGCHLD, bomberazo); /* Para eliminar "zombis" */

for (;;) { /* Ciclo infinito para llamadas*/
if ((t= descuelga_tel(s)) < 0) { /* alguien llama */
if (errno == EINTR) /* error EINTR en accept() */
continue; /* darle chance de intentar */
perror("accept"); /* otra vez */
exit(1);
} /* Delegar esta llamada */
switch(fork()) {
case -1 : /* No se pudo delegar llamada */
perror("fork");
close(s);
close(t);
exit(1);
case 0 : /* Ya pude delegar, atiendo la */
haz_algo(t); /* llamada con haz_algo(). */
exit(0);
default : /* Soy la telefónista, espero */
close(t); /* por otra llamada */
continue;
}
}
}

/* Como atiendo llamadas delegadas, una vez que fueron atendidas
* finiquito a quien la atendió (que es un proceso hijo)
*/

void bomberazo()
{ union wait wstatus;

while(wait3(&wstatus,WNOHANG,NULL) >= 0);
}

/* Esta función haz_algo() es la que va a leer la información que
* produzca la llamada. Puede ser, por ejemplo, guardar en un
* archivo los datos, desplegarlos en pantalla o cualquier otra
* cosa.
*/

void haz_algo(s)
int s;
{
/* código tuyo para manipular la información recibida
:
:
*/
}

Haciendo la Llamada ¿Cómo llamar en el socket?

Ahora ya sabemos cómo crear un socket en el cual despachar llamadas. Así que, ¿Cómo hacemos llamadas sobre ese socket ? Los pasos para realizar una llamada es similar a como las escuchamos. Primero necesitamos el teléfono para hacer la llamada, es decir, necesitamos crear el socket. Para crearlo, usamos la función socket().

Después de conseguir el teléfono (socket), tratamos de marcar el número asignandole la dirección al socket e invocando a la función connect() . La siguiente función intenta hacer una llamada a un socket particular.

int marca_número(hostname, num_puerto)
char *hostname;
{ struct sockaddr_in sa;
struct hostent *hp;
int a, s;

/* verificamos nombre */
if ((hp= gethostbyname(hostname)) == NULL) {
errno= ECONNREFUSED; /* y dirección */
return(-1); /* error, salimos */
}

bzero(&sa,sizeof(sa)); /* limpiamos estructura*/
/* pon dirección */
bcopy(hp->h_addr,(char*)&sa.sin_addr,hp->h_length);
sa.sin_family= hp->h_addrtype;
sa.sin_port= htons((u_short)num_puerto);

/* crea socket */
if ((s= socket(hp->h_addrtype,SOCK_STREAM,0)) < 0)
return(-1);
if (connect(s,&sa,sizeof sa) < 0) { /* conexión */
close(s);
return(-1);
}
return(s);
}

Esta función regresa un teléfono (socket) ya conectado a través del cual los datos ya pueden fluir.

Conversación ¿Cómo platicar entre sockets?

Ahora que ya tenemos una conexion hecha con sockets queremos enviar datos entre ellos. Las funciones read() y write nos servirán para realizar la lectura y escritura de los mismos. La diferencia de usar las funciones read() y write() con archivos abiertos a usarlas con sockets es el número de bytes que la función regresa. Con un archivo, read() lee los bytes que se especifiquen en sus argumentos, y write() escribe tambien lo indicado en los argumentos. En un socket, esas funciones leerán o escribirán los bytes que esteén disponibles en ese momento, de manera que para leer o escribir el número deseado, es necesario realizar un ciclo de lecturao escritura hasta llegar al número deseado de bytes. Una función muy simple que realiza el ciclo mencionado se muestra enseguida:

int lee_datos(s,buf,n)
int s; /* s = socket ya conectado */
char *buf; /* buf = apuntador a un arreglo de letras */
int n; /* n = número de bytes que deseamos leer */
{ int cnt, /* cnt = bytes leidos en un instante dado */
br; /* br = bytes leidos en un paso */

cnt= 0;
br= 0;
while (cnt < n) { /* ciclo de lectura */
if ((br= read(s,buf,n-cnt)) > 0) {
cnt += br; /* incrementa bytes leidos */
buf += br; /* mueve el apuntador del buffer */
}
if (br < 0) /* si no se puede leer mando -1 */
return(-1);
}
return(cnt);
}

Una función similar debería usarse para la escritura de datos, pero se deja al lector ese ejercicio para que se divierta, y haga algo!

Colgando el teléfono ¿Cómo deshacerse de un socket después de usarlo) ?

Igual que colgamos el teléfono cuando terminamos una llamada, necesitamos cerrar la conexion que se hizo entre sockets. Para esta labor se usa la función close() , la cual debe invocarse en cada lado del socket. Si un extremo del socket es cerrado y en el otro se intenta leer o escribir, el sistema enviará un mensaje de error.

Hablando un Mismo Lenguaje (El orden de los bytes es importante)

Ahora que podemos hacer que dos computadoras platiquen entre ellas debemos tener cuidado en cómo se transmiten la informacion. Sabemos que hay diferentes formas de codificar los datos, por ejemplo usando un código ASCII o un código EBCDIC. Otro aspecto es que una misma cadena de 7 u 8 bits puede ser interpretada de dos formas diferentes: que el bit 0 sea el mas significativo y el bit 7/8 sea el menos significativo, o viceversa. Es el famoso problema de maquinas "BIG-ENDian" y "LITTLE-ENDian". Así que si comunicamos una máquina BIG-END con una LITTLE-END, es posible que un conjunto de bytes signifiquen cosas diferentes para una y otra.

Para atacar el problema del orden de bytes se usan las funciones ntohs() (netork to host short integer), htons (host to network short integer), htoni() (host to network integer),
htonl() (host to network long integer) y ntohl() (network to host long integer). Por ejemplo, para poder enviar un número entero a través de un socket en la red, primero le aplicamos la función host to network integer htoni() como se muestra enseguida.

i= htoni(i);
escribe_datos(s, &i, sizeof(i));

Y después de leer un entero de la red, debemos convertirlo con ntohi():

lee_datos(s, &i, sizeof(i));
i= ntohi(i);

Es recomendable seguir el hábito de usar estas funciones para evitar problemas del orden de bytes.

El Futuro esta en tus manos ¿Qué hacer ahora?

Usando lo que ya se ha discutido aquí debe ser suficiente para construir nuestros propios programas de comunicación con sockets. Como con todas las cosas nuevas, es buena idea revisar el código de programas ya hechos para dilucidar su funcionamiento o la aplicación novedosa de esta tecnología.

Existen muchos programas de dominio publico que usan el concepto del socket y hay muchos libros que los exploran con mucha mas profundidad de lo que aqui se hace. Al final de este documento se anexan el código de un servidor y de un cliente que usan sockets. Realizan una función muy sencilla. El servidor escucha llamadas en un puerto dado y cualquier información que reciba la vuelve a escribir al socket hacia el cliente, es decir, responde la llamada repitiendo lo que le dicen. Por otro lado, el cliente lee un renglón de texto del teclado y se lo envía al servidor, y escribe en la pantalla todo aquello que el servidor le responda.

Si tienes preguntas adicionales acerca de sockets o de este tutorial, sientete en la confianza de enviarlas a:

madd@bu-it.bu.edu
enrique@cca.pue.udlap.mx

Jim Frost Enrique Sanchez Lara
Saber Software UDLA Consultores
(617) 876-7636 (5222) 292750
madd@saber.com enrique@udlac.com.mx

/***********************************************************************
* Archivo: tutor10.c
* Creador: Enrique SL
* Proposito: Demostrar el uso de la programación en red, SERVIDOR
* Compilar con: cc -o tutor10 tutor10.c -lsocket para una SUN
**********************************************************************/
#include "inet.h" /* definiciones y rutinas propias */

main(argc,argv)
int argc;
char **argv;
{

/* declaración de descriptores de red */
/**************************************/
int sockfd, newsockfd, clilen, childpid;
struct sockaddr_in cli_addr, serv_addr;
pname = argv[0];

/* creación del socket, que es como un "pipe" pero en red */
/**********************************************************/
if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 ) {
perror("socket opening");
exit(1);
}

/* Inicialización de dirección y puerto de red del socket */
/**********************************************************/

bzero((char*) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
serv_addr.sin_port = htons(SERV_TCP_PORT);

/* Le digo al sistema que reserve el socket para mi aplicacion*/
/**************************************************************/
if (bind(sockfd,(struct sockaddr *)&serv_addr,sizeof(serv_addr))<0){
perror("binding");
exit(1);
}

/* Una vez reservado el puerto, espero por siempre por peticiones*/
/*****************************************************************/
listen(sockfd, 5);

for(;;) {

clilen = sizeof(cli_addr);
newsockfd = accept(sockfd,(struct sockaddr *)&cli_addr,&clilen);
if ( newsockfd < 0 ) {
perror("accepting");
exit(1);
}

/* Ejemplo de la creación de subprocesos */
/*****************************************/

if ((childpid = fork()) < 0 ) {
perror("forking");
exit(1);
}
else if (childpid == 0 ) {
close(sockfd);
atiende_llamada(newsockfd); /* este es el hijo */
exit(0);
}

close(newsockfd); /* aqui no llega el hijo, es el 'papa' */
}
}

/********** FIN DE TUTOR10.c ******************************************/

/***********************************************************************
* Archivo: tutor11.c
* Creador: Enrique SL
* Proposito: Demostrar la programación en red, CLIENTE
* Compilar: cc -o tutor11 tutor11.c -lsocket en una SUN
**********************************************************************/
#include "inet.h"
main(argc,argv)
int argc;
char **argv;
{
int sockfd;
struct sockaddr_in cli_addr, serv_addr;
pname = argv[0];

/* Note la diferencia con el servidor, aca se pone la direccion
* del servidor. El servidor acepta peticiones de quien sea
**************************************************************/
bzero((char*) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = inet_addr(SERV_HOST_ADDR);
serv_addr.sin_port = htons(SERV_TCP_PORT);
if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 ) {
perror("socket opening");
exit(1);
}

if ( connect(sockfd,(struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0 ) {

perror("connecting");
exit(1);
}

/* La rutina platicame lo que hace es leer del teclado o stdin
* y enviarlo al servidor, el servidor retorna lo que se le envia
* y se imprime en pantalla.
*****************************************************************/

platicame(stdin, sockfd);
close(sockfd);
exit(0);

}

Home | Redes |