|
q
Historia
q
Preámbulo
q
Definiciones
q
Componentes
básicos de una red
q
Tipos de
redes
q
Topología
q
Características de
una red local
q
Aspectos del nivel de red
q
LAN alámbrica
e inalámbrica
q
Ejemplos de redes
|
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);
}
|