INSTITUTO POLITCNICO NACIONAL

CENTRO DE INNOVACIN Y
DESARROLLO TECNOLGICO EN
CMPUTO.



IMPLEMENTACIN DE CLIENTES LIGEROS DENTRO DE UN
CENTRO DE CMPUTO

TESIS
PARA OBTENER EL GRADO DE:
MAESTRA EN TECNOLOGA EN CMPUTO



PRESENTA:
ING. RUBN GONZLEZ ZAINEZ


DIRECTOR:
M. en C. JESS ANTONIO LVAREZ CEDILLO



2008
2

3
4

NDICE DE CONTENIDO

ndice ....................................................................................................................... 2
Glosario ................................................................................................................... 7
Titulo ..................................................................................................................... 12
Resumen ................................................................................................................ 12
Abstract.................................................................................................................. 12
Antecedentes.......................................................................................................... 12
Introduccin........................................................................................................... 12
Objetivo ................................................................................................................. 14
Objetivos Particulares............................................................................................ 14
Motivacin............................................................................................................. 14
Problemtica detectada.......................................................................................... 15
Contribucin.......................................................................................................... 15
Solucin propuesta ................................................................................................ 16
Cmo trabajan estas terminales Clientes Ligeros?........................................... 17
En dnde se pueden implementar el uso de los clientes ligeros? ........................ 17
Ambientes de trabajo que funcionan bajo esta forma de trabajo........................... 17


Captulo 1
El Paradigma Cliente-Servidor

1.1 Paradigma Cliente-Servidor ............................................................................ 18
1.2 Caractersticas de clientes y servidores ........................................................... 18
1.3 Programas servidores y computadoras clase servidor ..................................... 19
1.4 Solicitudes, respuestas y direccin de flujo de datos....................................... 19
1.5 Protocolos de transportacin e interaccin cliente-servidor............................ 20
1.6 Servicios mltiples en una computadora......................................................... 20
1.7 Identificacin de los servicios ......................................................................... 21
1.8 Varias copias de un servidor para un solo servicio ......................................... 22
1.9 Creacin de servidores dinmicos ................................................................... 22
1.10 Protocolos de transportacin y comunicacin no ambigua .......................... 23
1.11 Transportacin orientada a conexin y sin conexiones ................................ 23
1.12 Servicios orientados a la conexin y no orientados a la conexin ............... 24
1.13 Primitivas de servicio ................................................................................... 26
1.14 Servicio asequible por medio de varios protocolos ...................................... 28
1.15 Interacciones cliente-servidor complejas ...................................................... 28
1.16 Interacciones y dependencias circulares ....................................................... 29
1.17 Servicios proporcionados por mltiples servidores ...................................... 29
1.18 Servidores Proxy y cach ............................................................................. 30
1.19 Procesos de igual a igual .............................................................................. 31
1.20 Variaciones en el modelo cliente servidor ................................................ 32
5
1.21 Cdigo mvil ................................................................................................. 32
1.22 Agentes mviles ........................................................................................... 33
1.23 Computadoras de red.................................................................................... 34
1.24 Clientes ligeros ............................................................................................. 34
1.25 Implementacin de clientes Ligeros ............................................................. 35


Captulo 2
Protocolo TCP/IP

2.1 Introduccin a TCP/IP .................................................................................... 36
2.2 Historia de TCP/IP ......................................................................................... 37
2.3 objetivos de TCP/IP ........................................................................................ 38
2.4 El protocolo IP ................................................................................................ 39
2.4. 1 La funcin de IP ......................................................................................... 42
2.4.2 Direccionamiento IP .................................................................................... 42
2.4.3 Formato de cabecera de datagramas IP ....................................................... 46
2.4.4 IP versin 6 .................................................................................................. 47
2.5 TCP.................................................................................................................. 48
2.5.1 Servicio Terminal a Terminal y datagramas ................................................ 49
2.5.2 Formato de segmento TCP .......................................................................... 50
2.5.3 Corrientes de datos en TCP ......................................................................... 51
2.5.4 Control de flujo por medio de Ventanas en TCP ....................................... 52
2.5.5 Confiabilidad ............................................................................................... 52
2.5.6 Comunicacin fiable con TCP .................................................................... 53
2.5.7 Precedencia y seguridad .............................................................................. 53
2.6 Sockets utilizados por TCP/IP ........................................................................ 54
2.7 Puntos fuertes y dbiles de TCP/IP ................................................................ 54
2.8 Clases de direcciones Internet ........................................................................ 54

Captulo 3
Protocolos Remotos

3.1 El Papel de los Protocolos .............................................................................. 56
3.2 Definicin de Protocolo de red ....................................................................... 56
3.3 Introduccin a Protocolos Remotos ............................................................... 56
3.4 Protocolo TELNET ........................................................................................ 57
3.4.1 Cmo funciona TELNET ............................................................................ 57
3.4.2 Limitaciones de TELNET ........................................................................... 58
3.4.3 Transmisin de datos en TELNET .............................................................. 58
3.5 DHCP (Configuracin Dinmica de Hosts) ................................................... 59
3.5.1 Funcionamiento del protocolo DHCP ......................................................... 60
3.6 FTP ................................................................................................................. 61
3.6.1 Anatoma de FTP ......................................................................................... 62
3.7 NFS (Network File System Sistema de archivos de red) ............................ 62
3.8 SNMP (Protocolo Simple de Administracin de Red) ................................... 62
3.8.1 Elementos de Mensajes SNMP .................................................................. 63
6
3.9 SMTP .............................................................................................................. 64
3.9.1 Arquitectura del correo SMTP .................................................................... 65
3.9.2 Entrega de correo electrnico ...................................................................... 65
3.9.3 Caractersticas de SMTP ............................................................................. 65
3.10 DNS (Dominio de nombres de Sistemas) ..................................................... 66
3.10.1 Elemento del servicio DNS ....................................................................... 66
3.10.2 Transporte de mensajes DNS .................................................................... 67
3.11 http (Hypertext Transfer Protocol) ............................................................... 67
3.11.1 Conceptos sobre http ................................................................................. 68
3.12 POP3 (Post Office Protocol) ......................................................................... 68
3.13 Funcionamiento del protocolo POP3 .......................................................... 69
3.14 PPP (Point to Point Protocol) ....................................................................... 69
3.15 IRC (Internet Relay Chat) ............................................................................ 70
3.16 RIP (Routing Information Protocol) ............................................................. 70
3.17 OSPF (Open Shortest Path First). ................................................................. 71
3.18 IRDP (IICMP Router Discovery Protocol) ................................................ 72
3.19 VNC Virtual Network Computing (Computacin en Red Virtual) ............. 72
3.20 SSH ............................................................................................................... 73
3.20.1 Caractersticas del protocolo ..................................................................... 74
3.20.2 Puerto TCP/IP y otras opciones ................................................................. 75
3.20.3 Identificacin de la versin del protocolo ................................................ 75
3.20.4 Intercambio de claves y autentificacin del equipo servidor .................. 76
3.20.5 El nombre de usuario ................................................................................ 76
3.20.6 Fase de autentificacin ............................................................................. 77
3.20.7 Operaciones de preparacin ....................................................................... 77
3.20.8 Sesin interactiva e intercambio de datos ................................................. 78
3.21 SSH2 ........................................................................................................... 78
3.21.1 Arquitectura ............................................................................................... 78
3.22 Rdesktop ....................................................................................................... 80
3.23 X-WINDOW: Interfaces Grficas de Usuario para UNIX ........................... 80


Captulo 4
Diseo e Implementacin

4.1 Qu es un cliente Ligero ................................................................................. 83
4.1.1 Propiedades de un Cliente Ligero................................................................. 83
4.2 Progresos tecnolgicos en computadoras........................................................ 83
4.3 Depreciacin de Computadoras en Mxico.................................................... 86
4.4 Construccin de un cliente ligero ................................................................... 87
4.4.1 Construccin del gabinete del cliente Ligero ............................................... 88
4.5 Diseo de un sistema para clientes ligeros en GNU/LINUX. ........................ 90
4.5.1 Porque programar en Linux......................................................................... 90
4.5.2 Kernel .......................................................................................................... 90
4.5.3 Los mdulos cargables del kernel ................................................................ 92
4.5.4 Distribuciones Live CD............................................................................. 92
7
4.5.5 Qu es Syslinux. .......................................................................................... 94
4.5.6 Que no es Syslinux ....................................................................................... 94
4.5.7 Arranque desde Kanoppix live CD.......................................................... 94
4.6 Creacin de nuestra distribucin para Clientes ligeros .................................. 95
4.7 Protocolos de conexin en la interfaz de Gambas .......................................... 98
4.7.1 SSH (Secure Shell) ...................................................................................... 98
4.7.2 VNC. (Virtual Network Computing) ......................................................... 110
4.7.3 RDESKTOP. (Remote Desktop Protocol).................................................. 113
4.7.4 TELNET. (Terminal Networking)............................................................. 114
4.7.5 TERMINAL X ........................................................................................... 117
4.8 Gambas (Gambas Almost Jeans BASIC) ..................................................... 117
4.8.1 Elementos de Gambas ............................................................................... 119
4.9 Pruebas realizadas......................................................................................... 120




Captulo 5
Conclusiones

5.1 Conclusiones.................................................................................................. 122
5.2 Trabajos futuros............................................................................................. 125

Anexo .................................................................................................................. 127
Referencias ......................................................................................................... 137








8
NDICE DE FIGURAS



1.1 Cliente y servidor que usan el protocolo TCP/IP por una interred..........................20
1.2 Dos servidores de una computadora, accedidos por clientes de otras dos
Computadoras..........................................................................................................21
1.3 Seis tipos de servicios diferentes orientado y NO orientado a la conexin.............25
1.4 Cinco primitivas de servicio para la implementacin de un
servicio simple orientado a conexin ......................................................................26
1.5 Paquetes enviados en una interaccin simple cliente-servidor
sobre una red orientado a conexin.........................................................................27
1.6 Clientes que invocan a servidores individuales.......................................................30
1.7 Un servicio proporcionado por mltiples servidores...............................................30
1.8 Un servidor Proxy de tipo WEB..............................................................................31
1.9 Una aplicacin distribuida basada en procesos de igual a igual..............................32
1.10 Clientes ligeros y servidores de clculo ..................................................................35
2.1 Campos de la cabecera de datagrama IP. Tanto la fuente como
el destino son direcciones de Internet......................................................................47
2.2 Ejemplo de interred ilustra porqu el TCP es un protocolo de
transportacin Terminal a Terminal. El TCP ve al IP como mecanismo
que le permite intercambiar mensajes con un TCP remoto.....................................50
2.3 Formato de segmento TCP. Todos los mensajes transmitidos por el TCP
de una mquina al de otra tienen este formato, incluidos datos y
acuses de recibo.......................................................................................................51
4.1 Calculo de la depreciacin sobre algunos activos personales .................................87
4.2 Lamina metlica y aparatos electrnicos descompuestos........................................88
4.3 Construccin del gabinete utilizando material de desecho......................................89
4.4 Montaje de la fuente de voltaje y tarjeta madre (Desktop Boards) .........................89
4.5 Montaje de CD-ROM, disco duro y conexiones en general....................................89
4.6 Estructura de Linux .................................................................................................91
4.7 Protocolos de Cifrado en SSH.................................................................................99
4.8 Protocolos de Autentificacin .................................................................................99
4.9 Funcionamiento de TELNET ................................................................................115
4.10 Tabla de resultados experimentales con distintos procesadores............................120
5.1 Computadoras obsoletas, cinco Power PC, dos G3 y tres Pentium III..................125
5.2 Computadoras obsoletas en el centro de cmputo del IIA....................................126






9
GLOSARIO

ACTIVE X: Lenguaje de programacin al estilo de Java propuesto por Microsoft.
ANSI AMERICAN NATIONAL STANDARD INSTITUTE.: Instituto Nacional
Americano de Estndar.
API Aplication Program Interface. Interfaz de Aplicacin del Programa. Es el conjunto
de rutinas del sistema que se pueden usar en un programa para la gestin de entrada/salida,
gestin de ficheros etc.
ARCHIE: Software utilizado para localizar archivos en servidores FTP. A partir de 1994
ha cado en desuso debido a la aparicin del WWW, o Web.
ARCHIVO DE TEXTO: Archivo que utiliza solamente caracteres del estndar ASCII y
por lo tanto que puede ser enviado por correo electrnico sin ningn tipo de modificacin.
ASCII: American Standard Code for Information Interchange. Estndar Americano
para Intercambio de Informacin. La tabla bsica de caracteres ASCII esta compuesta por
128 caracteres incluyendo smbolos y caracteres de control. Existe una versin extendida de
256
AUI: Asociacin de usuarios de Internet.
BANDWITH: Ancho de Banda. Capacidad mxima de un medio de transmisin y/o
enlace.
BASE DE DATOS: conjunto de datos organizados de modo tal que resulte fcil acceder a
ellos, gestionarlos y actualizarlos.
BIOS Basic Input Output System. Sistema Bsico de Entrada/Salida. Programa residente
normalmente en Eprom que controla la iteracciones bsicas entre el hardware y el Software.
BIT Binary Digit. Digito Binario. Unidad mnima de informacin, puede tener dos estados
"0" o "1".
BOOTP Bootstrap Protocol. Protocolo de Arranque-Asignacin. Proporciona a una
mquina una direccin IP, Gateway y Netmask. Usado en comunicaciones a travs de lnea
telefnica.
BROWSER. Navegador. Trmino aplicado normalmente a los programas que permiten
acceder al servicio WWW.
BUS. Va o canal de Transmisin. Tpicamente un BUS es una conexin elctrica de uno o
ms conductores, en el cual todos los dispositivos ligados reciben simultneamente todo lo
que se transmite.
Byte 1 Byte es un carcter y equivale a 8 bits, 1Kbyte equivale a 1024 bytes
CD. Compact Disc. Disco Compacto. Disco ptico de 12 cm de dimetro para
almacenamiento binario. Su capacidad "formateado" es de 660 Mb. Usado en principio para
almacenar audio. Cuando se usa para almacenamiento de datos genricos es llamado CD-
ROM.
COMANDO: Instruccin determinada que indica en un programa la ejecucin de una
accin especfica como guardar, salir, conectar, etc.
CONFIGURACIN: Declaracin de las opciones o caractersticas con las que deber
ejecutarse determinado archivo programa.
DATAGRAMA. Usualmente se refiere a la estructura interna de un paquete de datos.
DNS Domain Name System: Sistema de nombres de Dominio. Base de datos distribuida
que gestiona la conversin de direcciones de Internet expresadas en lenguaje natural a una
direccin numrica IP. Ejemplo: 121.120.10.1
10
EBCDIC: Extended Bynary Coded Decimal Interchange Code Cdigo Extendido de
Binario Codificado Decimal. Sistema mejorado de empaquetamiento de nmeros decimales
en sistema binario.
ETHERNET:Diseo de red de rea local normalizado como IEEE 802.3. Utiliza
transmisin a 10 Mbps por un bus Coaxial. Mtodo de acceso es CSMA/CD.
FASTETHERNET: Diseo de red Ethernet, donde se alcanzan velocidades de hasta 100
Mbps, comnmente son inteligentes y se les permite identificar los nodos que trabajarn
ms rpido que otros.
FTP: File Transfer Protocol. Protocolo de Transferencia de Archivos. Uno de los
protocolos de transferencia de ficheros mas usado en Internet.
FUNCION: En programacin, una rutina que hace una tarea particular. Cuando el
programa pasa el control a una funcin, sta realiza la tarea y devuelve el control a la
instruccin siguiente a la que llamo.
GATEWAY: Pasarela. Puerta de Acceso. Dispositivo que permite conectar entre si dos
redes normalmente de distinto protocolo o un Host a una red.
GUI: Graphic User Interface Interfaz Grfica de Usuario.
Hardware: A los componentes que es posible ver y tocar se les llama en jerga
computacional "hardware", palabra inglesa cuyo significado es mquina o "cosa dura".
HDLC: High-Level Data Link Control, Control de Enlace de Datos de Alto Nivel. Es un
protocolo orientado al bit.
HDSL: High bit rate Digital Subscriber Linea, Linea Digital de Abonado de alta velocidad.
Sistema de transmisin de datos de alta velocidad que utiliza dos pares trenzados. Se
consiguen velocidades superiores al Megabit en ambos sentidos.
HOST: Anfitrin. Computador conectado a Internet. Computador en general.
HPFS: high performance file system, Sistema de Archivos de Alto Rendimiento. Sistema
que utiliza el OS/2 opcionalmente para organizar el disco duro en lugar del habitual de
FAT.
HTML: HyperText Markup Language, Lenguaje de Marcas de Hipertexto. Lenguaje para
elaborar paginas Web actualmente se encuentra en su versin 3. Fue desarrollado en el
CERN.
http: HyperText Transfer Protocol, Protocolo de Transferencia de Hypertexto. Protocolo
usado en WWW.
IANA: Internet Assigned Number Authority, Autoridad de Asignacin de Nmeros en
Internet. Se trata de la entidad que gestiona la asignacin de direcciones IP en Internet.
ICMP: Internet Control Message Protocol, Protocolo Internet de Control de Mensajes.
INTERNET: Conjunto de redes y ruteadores que utilizan el protocolo TCP/IP y que
funciona como una sola gran red.
IPI: Intelligent Peripheral Interface: Interfaz Inteligente de Perifricos. En ATM: Initial
Protocol Identifier. Identificador Inicial de Protocolo.
IPX: Internet Packet Exchange: Intercambio de Paquetes entre Redes. Inicialmente
protocolo de Novell para el intercambio de informacin entre aplicaciones en una red
Netware.
IRC:Internet Relay Chat, Canal de Chat de Internet. Sistema para transmisin de texto
multiusuario a travs de un servidor IRC. Usado normalmente para conversar on-line
tambin sirve para transmitir ficheros.
11
ISDN: Integrated Services Digital Network, Red Digital de Servicios Integrados. Servicio
provisto por una empresa de comunicaciones que permite transmitir simultneamente
diversos tipos de datos digitales conmutados y voz.
ISO: International Standard Organization, Organizacin Internacional de Estndares.
ISP: Internet Service Provider, Proveedor de Servicios Internet.
ISS: Internet Security Scanner, Rastreador de Seguridad de Internet. Programa que busca
puntos vulnerables de la red con relacin a la seguridad.
ITU: International Telecommunications Union, Union Internacional de
Telecomunicaciones. Forma parte de la CCITT. Organizacin que desarrolla estndares a
nivel mundial para la tecnologa de las telecomunicaciones.
LAN: Local Area Network, Red de Area Local. Una red de rea local es un sistema de
comunicacin de alta velocidad de transmisin. Estos sistemas estn diseados para
permitir la comunicacin y transmisin de datos entre estaciones de trabajo inteligentes,
comnmente conocidas como Computadoras Personales. Todas las PCs, conectadas a una
red local, pueden enviar y recibir informacin. Como su mismo nombre lo indica, una red
local es un sistema que cubre distancias cortas. Una red local se limita a una planta o un
edificio.
LCP: Link Control Protocol, Protocolo de Control de Enlace
Link Enlace: Unin. Se llama as a las partes de una pgina WEB que nos llevan a otra
parte de la misma o nos enlaza con otro servidor.
LINUX: Versin Shareware(software distribuido en calidad de prueba) y/o
Freeware del conocido sistema operativo Unix. Es un sistema multitarea multiusuario de 32
bits para PC.
NCP: Network Control Protocol, Protocolo de Control de Red. Es un protocolo del
Network Layer
NET: Red
NETBIOS Network BIOS: Network Basic Input/Output System. Bios de una red, es decir,
Sistema Bsico de Entrada/Salida de red.
Nic Network Interface Card: Tarjeta de Red.
NSA: National Security Agency, Agencia Nacional de Seguridad. Organismo americano
para la seguridad entre otras asuntos relacionados con la informtica.
NSF: National Science Fundation, Fundacin Nacional de Ciencia. Fundacin americana
que gestiona gran parte de los recursos de Internet.
ODBC Open DataBase Connectivity: es una interfaz standard para acceder a bases de
datos relacionales utilizando SQL. Esto le permite trabajar con los datos de una base de
datos como: Oracle, Sybase, Informix, desde cualquier aplicacin que soporte ODBC.
OSI Open Systems Interconnection: Interconexin de Sistemas Abiertos. Modelo de
referencia de interconexin de sistemas abiertos propuesto por la ISO. Divide las tareas de
la red en siete niveles.
POP Post Office Protocol: Protocolo de Oficina de Correos. Protocolo usado por
computadores personales para manejar el correo sobre todo en recepcin. PPP Point to
POINT PROTOCOL: Protocolo Punto a Punto. Un sucesor del SLIP. El PPP provee las
conexiones sobre los circuitos sncronos o asncronos, entre router y router, o entre host y la
red. Protocolo Internet para establecer enlace entre dos puntos.PROXY. Servidor Cach. El
Proxy es un servidor de que conectado normalmente al servidor de acceso a la WWW de un
proveedor de acceso va almacenando toda la informacin que los usuarios reciben de la
12
WEB, por tanto, si otro usuario accede a travs del proxy a un sitio previamente visitado,
recibir la informacin del servidor proxy en lugar del servidor real.
PROGRAMA: Es una coleccin de instrucciones que indican a la computadora que debe
hacer. Un programa se denomina software, por lo tanto , programa, software e instruccin
son sinnimos.
PROTOCOLO: Un conjunto de reglas formales que describen como se trasmiten los
datos, especialmente a travs de la red.
RARP: Reverse Address Resolution Protocol. Protocolo de Resolucin de Direccin de
Retorno. Protocolo de bajo nivel para la asignacin de direcciones IP a maquinas simples
desde un servidor en una red fsica.
RAM: Random Access Memory. Memoria de Acceso Aleatorio. Varios son los tipos de
memoria que se usa en las computadoras. La ms conocida son las RAM. Se les llama as
porque es posible dirigirse directamente a la clula donde se encuentra almacenada la
informacin. Su principal caracterstica es que la informacin se almacena en ellas
provisoriamente, pudiendo ser grabadas una y otra vez, al igual que un casette de sonido.
La memoria RAM se puede comparar a un escritorio, donde se coloca los papeles con que
se va a trabajar. Mientras ms grande el escritorio ms papeles soporta simultneamente
para ser procesados.
RAS Remote Access Server: Servidor de Acceso Remoto. RDSI Red Digital de
Servicios Integrados. Red de telefnica con anchos de banda desde 64Kbps. Similar a la
red telefnica de voz en cuanto a necesidades de instalacin de cara al abonado, pero
digital. En ingls ISDN.RFC Request For Comment. Peticin de comentarios. Serie de
documentos iniciada en 1967 que describe el conjunto de protocolos de Internet. Los RFC
son elaborados por la comunidad Internet.
RIP Routing Information Protocol: Protocolo de Informacin de Routing.
ROM Read Only Memory: Memoria slo de lectura. Las memorias ROM se usan para
mantener instrucciones permanentes, que no deben borrarse nunca. Estas memorias vienen
grabadas de fbrica. Son como los discos fonogrficos, que slo permiten reproducir el
sonido. Tienen la ventaja de ser de alta velocidad y bajo costo.
ROOT: Raz. En sistemas de ficheros se refiere al directorio raz. En Unix se refiere al
usuario principal.
ROUTER: Dispositivo conectado a dos o mas redes que se encarga nicamente de tareas
de comunicaciones
RTC Red Telefnica Conmutada: Red Telefnica para la transmisin de voz.
RTP Real Time Protocol: Protocolo de Tiempo Real. Protocolo utilizado para la
transmisin de informacin en tiempo real como por ejemplo audio y video en una video-
conferencia.
SERVIDOR: computadora central de un sistema de red que provee servicios y programas
a otras computadoras conectadas. Sistema que proporciona recursos (por ejemplo,
servidores de archivos, servidores de nombres). En Internet este trmino se utiliza muy a
menudo para designar a aquellos sistemas que proporcionan informacin a los usuarios de
la red.
SLIP Serial Line Internet Protocol: Protocolo Internet en Lnea Serial. Protocolo,
antecesor del PPP, que permite establecer conexiones TCP/IP a travs de enlaces seriales.
SMPT Simple Mail Transfer Protocol: Protocolo de Transferencia Simple de Correo. Es
el protocolo usado para transportar el correo a travs de Internet.
13
SISTEMA OPERATIVO: programa que administra los dems programas en una
computadora.
SOFTWARE: Esta palabra inglesa que significa "cosa suave", tiene dos significados: (a)
uno amplio, de "procedimientos lgicos, para la cooperacin armnica de un grupo de
personas y mquinas, persiguiendo un objetivo comn"; (b) el otro restringido, de
"programas de computadora", o conjunto de instrucciones, que se pone en la memoria de
una computadora para dirigir sus operaciones.
SQL: Structured Query Language. Lenguaje de Peticin Estructurada. Lenguaje para base
de datos.
SSL: Secure Sockets Layer. Capa de Socket Segura. Protocolo que ofrece funciones de
seguridad a nivel de la capa de transporte para TCP.
TCP/IP: Transmission Control Protocol / Internet Protocol: Protocolo de Control de
Transmisin / Protocolo Internet. Nombre comn para una serie de protocolos desarrollados
por DARPA en los Estados Unidos en los aos 70, para dar soporte a la construccin de
redes interconectadas a nivel mundial. TCP corresponde a la capa (layer) de transporte del
modelo OSI y ofrece transmisin de datos. El IP corresponde a la capa de red y ofrece
servicios de datagramas sin conexin. Su principal caracterstica es comunicar sistemas
diferentes. Fueron diseados inicialmente para ambiente Unix por Victor G. Cerf y Robert
E. Kahn. El TCP / IP son bsicamente dos de los mejores protocolos conocidos.
TELNET: Protocolo y aplicaciones que permiten conexin como terminal remota a una
computadora anfitriona, en una localizacin remota.
TIME-OUT: Parmetro que indica a un programa el tiempo mximo de espera antes de
abortar una tarea o funcin. Tambin mensaje de error.
TOPOLOGA: La "forma" de la red. Predominan tres tipos de tecnologas: Bus, Estrella y
Anillo.
TX: Abreviatura de Transmisin o Transmitiendo.
UDP: User Datagram Protocol. Protocolo de Datagrama de Usuario. Protocolo abierto en
el que el usuario (programador) define su propio tipo de paquete.
UNICAST Se refiere a Protocolos o Dispositivos que transmiten los paquetes de datos de
una direccin IP a otra direccin IP.
UNIX: Sistema operativo multitarea, multiusuario. Gran parte de las caractersticas de
otros sistemas mas conocidos como MS-DOS estn basadas en este sistema muy extendido
para grandes servidores. Internet no se puede comprender en su totalidad sin conocer el
Unix, ya que las comunicaciones son una parte fundamental en Unix.
URL: Uniform Resource Locator. Localizador Uniforme de Recursos. Denominacin que
no solo representa una direccin de Internet sino que apunta aun recurso concreto dentro de
esa direccin.
UTP: Unshielded Twisted Pair, par trenzado no apantallado) es un tipo de cableado
utilizado principalmente para comunicaciones.
WWW: WEB o W3 World Wide Web. Telaraa mundial. Sistema de arquitectura cliente-
servidor para distribucin y obtencin de informacin en Internet, basado en hipertexto e
hipermedia. Fue creado en el Laboratorio de Fsica de Energa Nuclear del CERN, en
Suiza, en 1991 y ha sido el elemento clave en el desarrollo y masificacin del uso de
Internet.
X Window System: Sistema de Ventanas X. El sistema de Ventanas X permite que cada
ventana se conecte con una computadora remota.

14
IMPLEMENTACIN DE CLIENTES LIGEROS DENTRO UN
CENTRO DE CMPUTO

Resumen

El siguiente proyecto trata sobre la fabricacin de prototipos de clientes ligeros a partir de
computadoras obsoletas o hardware especialmente diseado para ser utilizado como cliente
ligero. El prototipo obtenido funciona con un sistema operativo Linux especialmente
adaptado, optimizado y personalizado para trabajar en un ambiente cliente servidor bajo
una interfaz de conexin elaborada en el lenguaje de programacin visual Gambas que
satisface las necesidades de los usuarios tanto en ambientes Linux como Windows.


Abstract

The next project is about the manufacture of prototypes of "thin clients" from obsolete
computers or hardware designed to be used as a thin client. The prototype earned runs with
a Linux operating system tailored, optimized and customized to work on a environment
client-server under a connection interface developed in the programming language Visual
Gambas that meets the needs of users in both Linux and Windows environments.

Antecedentes

Introduccin

En la actualidad, diariamente las empresas e instituciones estn cambiando sus ambientes
de trabajo personalizados por la adecuacin del sistema de trabajo cliente servidor, para
obtener servicios. La adaptacin del sistema cliente - servidor en la mayora de los casos no
se realiza de una forma optima, la colocacin de las computadoras cliente representan una
fuerte inversin para empresas e instituciones, considerando que hay que invertir en
equipos robustos respecto a hardware y en software propio para ellos, los equipos
cuentan con recursos como procesador y memoria RAM, licencia de sistema operativo,
licencia de antivirus y las licencias de programas comerciales de oficina los que se
necesiten para llevar a cabo sus actividades.

Este esquema es claramente costoso e ineficiente sumado a esto las empresas deben de
contar con personal dedicado para brindar mantenimiento, correctivo y preventivo a todos
los equipos que lo requieran.

15
Pero estas computadoras clientes se tienden a volverse obsoletas conforme hay nuevos
adelantos en hardware y software y tienen que ser sustituidas peridicamente.

El presupuesto de instituciones educativas destinado a la compra de computadoras nunca es
suficiente y rara vez cubre las necesidades que ao con ao se presentan. Es urgente
encontrar una forma de seguir aprovechando las computadoras obsoletas y de hacer del
sistema cliente servidor eficiente tanto en lo operativo como en lo econmico.

Existe un modelo de estacin de trabajo o Terminal llamado Cliente Ligero, en ingls Thin
Client, modelo poco conocido en Mxico, se puede implementar a partir de computadoras
obsoletas, de bajo rendimiento o hardware especialmente fabricado para utilizarse como
cliente ligero.

El usuario de los clientes ligeros continua utilizando los mismos programas a los que esta
acostumbrado, bajo la adaptacin del sistema Cliente Ligero Servidor, que es una
conexin segura, econmica y ecolgica.


16

Objetivo:

Fabricacin de prototipos de clientes ligeros a partir de computadoras obsoletas con
hardware especialmente diseado para ser utilizado como cliente ligero, que opere bajo un
sistema operativo mnimo en GNU/Linux y que permita elegir el servidor con que se desee
trabajar ya sea que funcione en las plataformas Linux o Windows a la vez que permita
escoger el protocolo de conexin con el servidor. La construccin y la adaptacin de esta
estacin de trabajo debe realizarse a un bajo costo.

Objetivos Particulares:

Construir prototipos de cliente ligeros a partir de computadoras obsoletas, o bien
hardware especializado fabricado para ser utilizado como cliente ligero. Este ltimo
tiene la ventaja de ser de bajo consumo elctrico, dimensiones pequeas, comparado
con el Hardware de computadoras obsoletas.

Crear una distribucin de GNU/Linux propia y optimizada para clientes ligeros y
que se adapte a distintos entornos de trabajo de tal manera que puede ejecutarse
desde CD-ROM, disco duro y memoria USB flash Drive.


Elaborar una interfaz grfica por medio del lenguaje de programacin visual
Gambas. Que pueda ser personalizado para cualquier centro de cmputo de
universidades y escuelas.

Implementar el modelo, cliente ligero servidor por medio de los protocolos que
soportan ambientes grficos Terminal X, RDesktop y VNC, y de protocolos que no
soportan grficos como son Telnet y SSH.

Utilizar el modelo cliente ligero servidor y comprobar su ventaja con otros
modelos de conexin a servidor remoto.


Motivacin

Las computadoras nuevas siguen siendo caras a pesar de la amplia oferta que ofrecen los
fabricantes. Elevndose el precio de estas al complementarlas con un sistema operativo, un
programa antivirus, programas bsicos de oficina, etc.

Muchas de las computadoras nuevas se instalan con un conjunto de programas y
aplicaciones en su disco duro local y estas computadoras son utilizadas para realizar una
conexin remota con un servidor. Dejando en evidencia un claro desperdicio de recursos
17
tanto de hardware y software; estas computadoras representan un tipo de problema para el
personal de soporte tcnico con lo que en pocos aos sern equipos obsoletos.
Los procesadores y dispositivos de las computadoras son cada da ms potentes y demanda
de mayor energa por lo tanto tambin demanda un mtodo de enfriamiento.

Existe un componente que puede evitar a todos estos problemas y este es el cliente ligero.

Otra motivacin muy especial es el desarrollar aplicaciones con aplicaciones de libre
distribucin tales como el sistema operativo Linux y el lenguaje de programacin visual
Gambas; de esta forma se evita la adquisicin de licencias de software de propietario como
lo es el sistema operativo Windows junto con sus aplicaciones.

Es aspecto ecolgico es muy importante, porque al crear clientes ligeros a partir de
computadoras obsoletas, la vida til se incrementa considerablemente en aos, evitando la
compra y el desecho innecesario de computadoras.

Problemtica Detectada

Los adelantos en hardware, software y nuevos perifricos hacen que las computadoras en
buenas condiciones sean desplazadas por nuevas, antes que su vida til termine
convirtiendo en un problema para su almacenaje y se convierten en basura informtica.

Esto representa un gasto econmico tanto para comprar nuevas computadoras como para su
almacenaje, y posteriormente el desecho de computadoras obsoletas.

Cuando se utiliza el modelo cliente- servidor muchas veces la computadora cliente, trae
instalado sistema operativo completo y comercial adems que contiene aplicaciones que
residen en su disco duro, el usuario a su vez utiliza aplicaciones y almacena su informacin
de manera combinada tanto en su servidor como en computadora local. Esta forma no es
adecuada pues exige una buena computadora del lado del cliente y por lo tanto esta
computadora quedar obsoleta cuando ya no pueda manejar nuevas aplicaciones residentes
en el disco duro de la computadora que trabaja como servidor.

Las computadoras al tener disco local, CD-ROM, DVD sistema operativo, y la facilidad
para que el usuario personalice la computadora las convierte en medios inseguros y un
trabajo constante para el personal de soporte tcnico.



Contribucin

Las contribuciones son muchas, no es nada ms por el aspecto econmico,
18
Se demuestra la versatilidad del GNU/Linux para poder ser reducido y
personalizado de acuerdo al tipo y necesidades del trabajo que se requiera, en este
caso creacin de clientes ligeros.

Se demuestra la versatilidad del Lenguaje de programacin visual gambas, que se
utiliz para la creacin de la interfaz de conexin de un cliente ligero con un
servidor.


Los Protocolos Telnet, SSH, VNC, Terminal X y RDesktop son protocolos que en
su conjunto pueden satisfacer a cualquier usuario, para obtener servicios del
servidor para ejecutarse en ambiente Windows o Linux.

Queda de manifiesto que la implementacin de clientes ligeros tiene como
consecuencia el ahorro de licencias en entornos Microsoft.

Se comprueba que conexin cliente ligero-servidor, es la mas eficiente dentro del
paradigma cliente servidor. Por lo que se puede trabajar con servidores remotos a
un bajo precio y con un reducido consumo de hardware y software por parte del
cliente.

Es posible fabricar clientes ligeros con material de desecho.

Solucin Propuesta.

Se propone la adaptacin del modelo cliente servidor como estructura de trabajo, por lo que
se utiliza una computadora que funciona como servidor con capacidad de almacenamiento
de informacin grande como por ejemplo 500 GB, una memoria RAM de 2 GB, procesador
que acepte procesamiento por lotes, como Core 2 dual ideal para la atencin de solicitudes
concurrentes. Como equipos clientes se propone la construccin fsica de las estaciones de
trabajo, que este caso se denominan clientes ligeros, cuya construccin estar basada en la
reutilizacin de componentes internos en buen estado de computadoras en desuso, adems
como forma de conexin se propone que tenga flexibilidad de establecer comunicacin con
el servidor por diferentes formas, empleando para ello protocolos de conexin remota y
algunos de ellos con soporte de grficos, creando para esto una interfaz grfica que le
permita realizar la seleccin del tipo de conexin. Para la creacin de esta se utiliza el
lenguaje de programacin visual Gambas. Como sistema operativo propuesto para que
estos equipos funcionen se plantea la produccin de un sistema mnimo que es una versin
reducida del sistema operativo Linux pero adaptada y optimizada para trabajar con estos
equipos.

19
Cmo trabajan estas terminales Clientes Ligeros?
Lo ms destacable de los Clientes Ligeros, es su habilidad para separar: la interfaz de una
aplicacin respecto de la ejecucin de la aplicacin. Durante una sesin de trabajo, slo la
digitacin en el teclado, los clicks del mouse o las actualizaciones de las pantallas transitan
a travs de las redes de interconexin.
Todo el procesamiento de los datos se realiza en un servidor central denominado terminal
server.
Es por esta razn, que un Cliente Ligero (thin client) slo requiere un dcimo del ancho
de banda requerido por una aplicacin convencional cliente/servidor.
Basta un terminal server central, dotado de un Sistema Operativo para permitir a cada
Cliente Ligero el acceso ilimitado a las aplicaciones instaladas en el servidor.
Adicionalmente, el uso de Clientes Ligeros, se ve complementado con la posibilidad de
emplear PC's antiguas con un software de emulacin. Por ejemplo, si una empresa debe
reemplazar 50 PC's /Pentium II y Pentium III, podr optar por mantener estas computadoras
con el ahorro respectivo. Una PC Pentium III emulando un Cliente Ligero, comenzar a
prestar sus servicios operando con aplicaciones de 32-bits, solo utilizando el software de
emulacin. An cuando las aplicaciones son realmente ejecutadas en el servidor, el
usuario final percibe el mismo efecto que si ejecutase sus aplicaciones en una PC instaladas
en su escritorio.
En este entorno, todos los usuarios siempre ejecutarn una misma versin de la aplicacin,
pues sta se encuentra cargada en el servidor, a diferencia de una operacin
cliente/servidor, donde cada PC cuenta con una versin separada de la aplicacin.

En dnde se puede implementar el uso de los clientes ligeros?

La aplicacin de estas terminales es amplia, estos equipos pueden ser instalados en aulas de
enseanza, puntos de venta, call centers, salas de Internet, supermercados, bancos, etc. Sin
duda su aplicacin es variada, puede representar una inversin muy exitosa.

Ambientes de trabajo que funcionan bajo esta forma de trabajo

En Mxico el uso de estos equipos es poco conocido sin embargo empresa norteamericanas
con sucursales en Mxico, ya trabajan bajo este esquema de trabajo del sistema cliente
servidor tales como Walt Mart y Burger King, el modelo cliente servidor funciona de
manera ptima a un bajo costo.
20
Captulo 1
El paradigma Cliente-Servidor


En este captulo se presenta el concepto fundamental de todas las aplicaciones de red:
interaccin cliente-servidor. Se explica el modelo cliente-servidor y se detalla que esta
interaccin proviene de la manera en que operan los protocolos de red.

1.1 Paradigma cliente-servidor

El paradigma que dispone que una aplicacin espere pasivamente a que otra inicie la
comunicacin penetra una parte tan grande del cmputo distribuido que tiene un nombre:
paradigma de interaccin cliente-servidor.

Los trminos cliente y servidor se refieren a las dos aplicaciones que participan en la
comunicacin. La aplicacin que inicia el contacto se llama cliente, y la que espera
pasivamente se denomina servidor.


1.2 Caractersticas de clientes y servidores

Aunque existen variaciones menores, la mayor parte de las instancias de interaccin
cliente-servidor poseen las mismas caractersticas generales. Por lo general el software de
cliente:

Es un programa de aplicacin arbitrario que se vuelve cliente temporalmente
cuando se necesita acceso remoto, pero que tambin lleva a cabo otro cmputo
local.

Lo llama directamente el usuario y se ejecuta slo durante una sesin.

Se ejecuta localmente en la computadora personal del usuario.

Inicia el contacto con el servidor.

Puede acceder a varios servicios, segn se necesite, pero contacta activamente con
un servidor remoto a la vez.

No se necesita hardware especial ni un sistema operativo complicado.

En contraste, el software de servidor

Es un programa privilegiado de propsito especial dedicado a ofrecer un servicio,
pero puede manejar varios clientes remotos al mismo tiempo.
21

Se inicia automticamente al arranque del sistema y continua ejecutndose en varias
sesiones. Opera en una computadora compartida.

Espera pasivamente el contacto de los clientes remotos.

Acepta el contacto de varios clientes, pero ofrece un solo servicio.

Necesita hardware poderoso y un sistema operativo complicado.


1.3 Programas servidores y computadoras clase servidor

El trmino servidor a veces produce confusiones. Formalmente, se refiere a un programa
que espera pasivamente una comunicacin y no a la computadora en la que se ejecuta. Sin
embargo, a una computadora que se dedica a ejecutar uno o varios programas servidores se
le suele llamar errneamente servidor. Los proveedores de hardware contribuyen a la
confusin porque clasifican las computadoras de CPU rpida, gran memoria y sistema
operativo poderoso como mquinas servidoras.

Lo recomendable es apegarse a la terminologa correcta desde el punto de vista cientfico y
usar el trmino servidor para referirse al programa y no a la computadora. El trmino
computadora clase servidor se refiere a una computadora poderosa que sirve para ejecutar
software servidor.


1.4 Solicitudes, respuestas y direccin de flujo de datos

La informacin puede pasar en ambas direcciones entre el cliente y el servidor. Por lo
comn, el cliente transmite una solicitud al servidor y ste da respuesta al cliente. En
algunos casos, el cliente manda varias solicitudes y el servidor emite una serie de
respuestas como por ejemplo, una base de datos cliente podra permitir que un usuario
busque ms de un elemento a la vez. En otros casos, el servidor ofrece salida continua sin
ninguna solicitud, y tan pronto como el cliente contacta con el servidor, ste inicia el envo
de datos.

Es importante entender que los servidores pueden aceptar la informacin de entrada as
como entregar la informacin de salida. Por ejemplo, casi todos los servidores de archivos
estn configurados para exportar a los clientes un grupo de archivos. Esto quiere decir que
un cliente transmite una solicitud con un nombre de archivo y el servidor responde con una
copia. Sin embargo, el servidor de archivos tambin puede estar configurado para importar
archivos, es decir, para permitir que el cliente transmita un archivo que el servidor acepta y
almacena en disco.



22
1.5 Protocolos de transportacin e interaccin cliente-servidor

Como parte de los programas de aplicacin, el cliente y el servidor necesitan un protocolo
de transportacin para comunicarse. En la figura 1.1 se ilustra un cliente y un servidor que
utilizan la pila TCP/IP.



Figura 1.1 Cliente y servidor que usan el protocolo TCP/IP por una interred


Como se muestra en la figura 1.1, la aplicacin cliente-servidor interacta directamente con
el protocolo de la capa de transportacin para establecer la comunicacin y transmitir o
recibir informacin. Enseguida, el protocolo de transportacin emplea protocolos de nivel
mas bajo para transmitir y recibir mensajes. Por lo tanto, cada computadora necesita la pila
completa de protocolos para operar un cliente o un servidor.


1.6 Servicios mltiples en una computadora

Una computadora bastante poderosa puede ejecutar varios clientes y servidores al mismo
tiempo; se necesitan dos capacidades. Primero, debe tener suficientes recursos de hardware
como por ejemplo, procesador rpido y gran memoria, segundo, debe tener un sistema
operativo que permita que varios programas de aplicacin se ejecuten a la vez como por
ejemplo Windows UNIX. En tales sistemas, se ejecuta un programa servidor y por cada
servicio ofrecido. Ejemplo, una computadora puede ejecutar un servidor de archivos y un
servidor WEB. En la figura 2.2 se ilustra una forma de organizacin.


cliente
transportacin
interred
Interfaz de red
servidor
transportacin
interred
Interfaz de red
interred
23



Figura 1.2 Dos servidores de una computadora, accedidos por clientes de otras dos
computadoras. El cliente 1 puede acceder al servidor 1 y el cliente 2 al servidor 2.

En la figura 1.2 se ilustran los clientes de dos computadoras que acceden a dos servidores
de una tercera computadora. Aunque una computadora puede operar varios servidores, slo
necesita una conexin fsica a la interred.

Es til que la computadora opere varios servidores, pues de este modo varios servicios
comparten el hardware. La consolidacin de servidores en una computadora grande, clase
servidor, tambin reduce la sobrecarga de la administracin del sistema, pues son menos las
computadoras que hay que mantener. Adems la demanda ha demostrada que la demanda
de servidores suele ser espordica, cualquier servidor puede quedar en reposo por largos
periodos, por lo tanto, si la demanda de servicios es escasa, la consolidacin de los
servidores en una sola mquina disminuye los costos sin reducir significativamente el
rendimiento.

1.7 Identificacin de los servicios

Los protocolos de transportacin ofrecen mecanismos para que los clientes especifiquen sin
ambigedades el servicio deseado. El mecanismo asigna a cada servicio un identificador
nico y requiere que tanto el cliente como el servidor, lo utilicen. Al comenzar la ejecucin
el servidor se registra con el protocolo local especificando el identificador del servicio que
ofrece. Cuando el cliente contacta con el servidor remoto, especifica el identificador del
servicio deseado. Al hacer una solicitud el protocolo de transportacin del servidor usa el
identificador para determinar el programa servidor que manejar la solicitud. Por ejemplo,
el protocolo TCP (Protocolo de Control de Transmisin), para identificar los servicios, el
cliente 1
transportacin
interred
Interfaz de red
servidor 2
transportacin
interred
Interfaz de red
interred
servidor 1
transportacin
interred
Interfaz de red
servidor 2
24
TCP usa enteros de 16 bits conocidos como nmeros de puerto de protocolo. El TCP asigna
un nmero de puerto de protocolo nico a cada servicio. El servidor indica el nmero de
puerto del servicio que ofrece y espera una comunicacin. El cliente indica el nmero de
servicio deseado al transmitir una solicitud. El TCP del servidor usa el nmero de puerto de
protocolo del mensaje de entrada para determinar el servidor que debe recibir la solicitud.


1.8 Varias copias de un servidor para un solo servicio

Tcnicamente, se dice que los sistemas de cmputo que permiten la ejecucin simultnea
de varios programas de aplicacin manejan el principio de concurrencia, y que un programa
con ms de un proceso se llama programa concurrente. La concurrencia es fundamental en
el modelo de interaccin cliente-servidor porque un servidor concurrente sirve a varios
clientes a la vez, sin que un cliente tenga que esperar la terminacin de otro.

Para entender la importancia del servicio simultneo, podemos considerar lo que sucede si
un servicio necesita bastante tiempo para satisfacer cada solicitud el nombre del archivo y
el servidor le devuelve una copia. Si el cliente solicita un archivo pequeo, el servidor
puede mandarlo completo en unos cuantos milisegundos. Sin embargo, pude necesitar
varios minutos para transferir un archivo con imgenes digitalizadas de alta resolucin.

Si un servidor de archivos maneja una solicitud a la vez, los dems clientes deben esperar
mientras el servidor transfiere un archivo a cada uno. Por el contrario, un servidor de
archivos concurrente maneja varios clientes a la vez. Al llegar una solicitud, el servidor
asigna la solicitud a un proceso que se ejecuta concurrentemente con los dems procesos
existentes. En esencia, cada solicitud la maneja una copia del servidor. As las solicitudes
breves son satisfechas con rapidez, sin esperar la terminacin de solicitudes mas grandes.


1.9 Creacin de servidores dinmicos

Casi todos los servidores concurrentes operan dinmicamente. El servidor crea un proceso
nuevo para cada solicitud. De hecho, el servidor esta compuesto de dos partes: una que
acepta las solicitudes y crea nuevos procesos para ellas, y otra que consiste en el cdigo
para manejarlas. Al iniciar un servidor concurrente, slo se ejecuta la primera parte; es
decir el proceso principal del servidor ejecuta la primera parte, que espera la llegada de una
solicitud. Al llegar, el proceso principal crea un proceso nuevo que la maneja: El proceso
que maneja la solicitud ejecuta la segunda parte es decir la atiende y termina. Mientras, el
proceso principal mantiene en funciones el servidor tras crear un proceso nuevo para
manejar una solicitud, el proceso principal espera la llegada de otra.

Si N clientes usan un servicio de una computadora, hay N+1 procesos que ofrecen el
servicio: el proceso principal espera solicitudes adicionales y estn interactuando N
procesos de servicio con otros tantos clientes.



25

1.10 Protocolos de transportacin y comunicacin no ambigua

Al existir varias copias de un servidor existe el problema de saber como interacta el
cliente con la copia correcta. Por ello el mtodo utilizado por los protocolos de
transportacin para identificar a los servidores, considerando que se asigna a cada servicio
un nmero de identificador nico, y que las solicitudes del cliente incluyen el identificador
de servicio, lo que permite que el protocolo de transportacin de la computadora asocie la
solicitud de entrada con el servidor correcto. En la prctica, la mayor parte de los
protocolos de transportacin asigna a cada cliente un identificador nico y requiere que el
cliente incluya su propio identificador al hacer una solicitud. El protocolo de transportacin
del servidor usa ambas identificaciones, la del cliente y la del servidor usa ambas
identificaciones, la del cliente y la del servidor, para seleccionar la copia creada para
manejar al cliente.

Como ejemplo, considere los identificadores de una conexin TCP. El TCP pide que cada
cliente seleccione un nmero de puerto de protocolo local no asignado a otro servicio. Al
mandar un segmento TCP, el cliente debe poner su propio nmero de puerto de protocolo
en el campo de PUERTO FUENTE y el nmero de puerto en el servidor en el campo
PUERTO DESTINO. En la computadora del servidor, el TCP usa la combinacin de
nmeros de puerto fuente y puerto destino, as como las direcciones IP del cliente y el
servidor, para identificar la comunicacin. As pueden llegar mensajes de varios clientes
para el mismo servicio sin causar problemas. El TCP pasa cada segmento de entrada a la
copia del servidor que ha acordado manejar el cliente.



1.11 Transportacin orientada a conexin y sin conexiones

Los protocolos de transportacin manejan dos formas bsicas de comunicacin: orientada a
conexin y sin conexiones. Para usar un protocolo de transportacin orientado a conexin,
debe establecerse una conexin entre dos aplicaciones, que entonces transmiten datos por
ella. Por ejemplo, el TCP ofrece una interfaz orientada a conexin entre las aplicaciones. Al
emplear TCP, una aplicacin debe solicitar primero que se establezca una conexin con
otra. Una vez establecida, ambas intercambian datos. Al terminar la comunicacin, debe
cerrarse.

La alternativa es una interfaz sin conexiones que permita que una aplicacin transmita
mensajes a un destino en cualquier momento. Al emplear un protocolo de transportacin sin
conexiones, la aplicacin transmisora debe especificar un destino en cada mensaje que
transmite. Por ejemplo, en el grupo de protocolos TCP/IP, el Protocolo de Datagrama de
Usuario UDP ofrece una transportacin sin conexiones. La aplicacin que utiliza UDP
puede transmitir una secuencia de mensajes, cada uno a un destino diferente.

Para comunicarse, los clientes y servidores empelan protocolos orientados a conexin o
bien sin conexiones. En el primer caso, el cliente comienza por establecer la conexin con
26
el servidor. La conexin subsiste mientras el cliente transmite solicitudes y recibe
respuestas. Al terminar de usar el servicio, el cliente cierra la conexin.

Los clientes y servidores que utilizan protocolos sin conexiones intercambian mensajes. Por
ejemplo, muchos servicios de transportacin sin conexiones necesitan que el cliente
transmita cada solicitud como un solo mensaje y que los servidores regresen las respuestas
de la misma manera.


1.12 Servicios orientados a la conexin y no orientados a la conexin

El servicio orientado a conexin se concibi con base en el sistema telefnico, para hablar
con alguien, se levanta el telfono, se marca el nmero, se habla y luego se cuelga. Del
mismo modo, para usar un servicio de red orientado a la conexin, el usuario del servicio,
primero establece una conexin, la utiliza y luego la abandona. El aspecto fundamental de
una conexin es que funciona como un tubo: el emisor empuja objetos (bits) en un extremo
y el receptor los toma en el otro extremo. En la mayora de los casos se conserva el orden
para que los bits lleguen en el orden en que se enviaron.

En algunos casos, al establecer la conexin, el emisor, el receptor y la subred realizan una
negociacin sobre los parmetros que se van a utilizar, como el tamao mximo de
mensajes, la calidad del servicio solicitado y otros temas. Por lo general, un lado hace una
propuesta y el otro la acepta, la rechaza o hace una contrapropuesta.

En contraste, el servicio no orientado a la conexin, se concibi con base en el sistema
postal. Cada mensaje (carta) lleva completa la direccin de destino y cada una se enruta a
travs del sistema, independientemente de las dems. En general, cuando se envan dos
mensajes al mismo destino, el primero que se enve ser el primero en llegar. Sin embargo,
es posible que el que se envi primero se dilate tanto que el segundo llegue primero.

Cada servicio se puede clasificar por la calidad del servicio. Algunos de los servicios son
confiables en el sentido de que nunca pierden datos. Por lo general en un servicio confiable
el receptor confirma la recepcin de cada mensaje para que el emisor est seguro de que
lleg. Este proceso de confirmacin de recepcin introduce sobrecargas y retardos, que con
frecuencia son valiosos pero a veces son indeseables.

Una situacin tpica en la que un servicio orientado a conexin es apropiado es en la
transferencia de archivos. El propietario del archivo desea estar seguro de que lleguen
correctamente todos los bits y en el mismo orden en que se enviaron. Muy pocos clientes
que transfieren archivos preferiran un servicio que revuelve o pierde ocasionalmente
algunos bits, aunque fuera mucho ms rpido.

Un servicio orientado a la conexin confiable tiene dos variantes menores: secuencias de
mensaje y flujo de bytes. En la primera variante se conservan los lmites del mensaje.
Cuando se envan dos mensajes de 1024 bytes, llegan en dos mensajes distintos de 1024
bytes, nunca en un solo mensaje de 2048 bytes. En la segunda, la conexin es simplemente
un flujo de bytes, sin lmites en los mensajes. Cuando llegan los 2048 bytes al receptor, no
27
hay manera de saber si se enviaron como un mensaje de 2048 bytes o dos mensajes de 1024
bytes o 2048 mensajes de un byte. Si se envan las pginas de un libro en mensajes
separados sobre una red a una fotocomponedora, podr ser importante que se conserven los
lmites de los mensajes. Por otra parte cuando un usuario inicia sesin en un servidor
remoto, todo lo que se necesita es un flujo de bytes desde la computadora del usuario al
servidor. Los lmites del mensaje no son importantes.

Como se menciono antes, para algunas aplicaciones, los retardos del trnsito ocasionados
por las confirmaciones de recepcin son inaceptables. Una de estas aplicaciones es el
trfico de voz digitalizada. Es preferible para los usuarios de telfono escuchar un poco de
ruido en la lnea de vez en cuando que experimentar un retardo esperando las
confirmaciones de la recepcin.

No todas las aplicaciones requieren conexiones, por ejemplo, conforme el uso del correo
electrnico se volvi mas comn, tambin la basura electrnica se torn mas comn. Es
probable que el emisor de correo electrnico basura no desee enfrentarse al problema de
configurar una conexin y luego desarmarla slo para enviar un elemento. Tampoco es 100
por ciento confiable enviar lo esencial, sobre todo si eso es mas costoso. Todo lo que se
necesita es una forma de enviar un mensaje nico, que tenga una alta, aunque no
garantizada, probabilidad de llegar. Al servicio no orientado a la conexin no confiable, es
decir; sin confirmacin de recepcin se le conoce como servicio de datagramas, en
analoga con el servicio de telegramas, que tampoco devuelve una confirmacin de
recepcin al emisor.

En otras situaciones se desea la conveniencia de no tener que establecer una conexin para
enviar un mensaje corto, pero la confiabilidad es esencial. Para estas aplicaciones se puede
proporcionar el servicio de datagramas confirmados. Es como enviar una carta certificada y
solicitar una confirmacin de recepcin. Cuando esta regresa, el emisor esta absolutamente
seguro de que la carta se ha entregado a la parte destinada y no se ha perdido durante el
trayecto.

Otro servicio ms es el de solicitud-respuesta. En este servicio el emisor transmite un solo
datagrama que contiene una solicitud, a continuacin el servidor enva la respuesta. El
esquema de solicitud-respuesta se usa comnmente para implementar la comunicacin en el
modelo cliente-servidor: el cliente emite una solicitud y el servidor la responde. La figura
1.3 resume los servicios que se acaban de exponer:


Tipo de conexin Servicio Ejemplo
Flujo confiable de mensajes Secuencia de pginas
Flujo confiable de bytes Inicio de sesin remoto Orientado a la conexin
Conexin no confiable Voz digitalizada
Datagrama no confiable Correo electrnico basura
Datagrama confirmado Correo certificado No orientado a la conexin
Solicitud-respuesta Consulta de base de datos

Figura 1.3 Seis tipos de servicios diferentes orientado y NO orientado a la conexin
28

El concepto del uso de la comunicacin no confiable podra ser confuso al principio.
Primero que nada, la comunicacin confiable en este caso, con confirmacin de recepcin
podra no estar disponible. Por ejemplo, Ethernet no proporciona comunicacin confiable.
Ocasionalmente, los paquetes se pueden daar en el trnsito. En segundo lugar, los retardos
inherentes al servicio confiable podran ser inaceptables, particularmente para aplicaciones
en tiempo real como multimedia. Estas son las razones de que coexistan la comunicacin
no confiable y la confiable.


1.13 Primitivas de servicio

Un servicio se especifica formalmente como un conjunto de primitivas (operaciones)
disponibles a un proceso de usuario para que acceda al servicio, estas primitivas le indican
al servicio que desempee alguna accin o reporte sobre una accin que ha tomado una
entidad igual. Si la pila de protocolos se ubica en el sistema operativo, como suele suceder,
por lo general las primitivas son llamadas al sistema. Estas llamadas provocan un salto al
modo de kernel, que entonces cede el control de la mquina al sistema operativo para
enviar los paquetes necesarios.

El conjunto de primitivas disponible depende de la naturaleza del servicio que se va a
proporcionar. Las primitivas de servicio orientado a conexin son diferentes de las del
servicio no orientado a conexin. Como ejemplo mnimo de las primitivas para servicio que
se podran proporcionar para implementar un flujo de bytes confiable en un ambiente
cliente-servidor, vase las primitivas listadas en la figura 1.4

Primitiva Significado
LISTEN Bloquea en espera de una conexin entrante
CONNECT Establece una conexin con el igual en espera
RECEIVE Bloquea en espera de un mensaje entrante
SEND Enva un mensaje al igual
DISCONNECT Da por terminada una conexin

Figura 1.4 Cinco primitivas de servicio para la implementacin de un
servicio simple orientado a conexin.

Estas primitivas se podrn usar como sigue. En primer lugar, el servidor ejecuta LISTEN
para indicar que esta preparado para aceptar las conexiones entrantes. Una manera de
implementar LISTEN es hacer que bloquee la llamada al sistema. Despus de ejecutar la
primitiva, el proceso del servidor se bloquea hasta que aparece una solicitud de conexin.

A continuacin, el proceso de cliente ejecuta CONNECT para establecer una conexin con
el servidor. La llamada CONNECT necesita especificar a quin conecta con quin, as que
podra tener un parmetro que diera la direccin del servidor. El sistema operativo, en
general, enva un paquete igual solicitndole que se conecte como se muestra en el paso 1
de la figura 1.5. El proceso del cliente se suspende hasta que haya una respuesta. Cuando el
29
paquete llega al servidor es procesado ah por el sistema operativo. Cuando el sistema ve
que el paquete es una solicitud de conexin, verifica si hay un escuchador. En ese caso hace
dos cosas: desbloquea al escuchador y enva de vuelta una confirmacin de recepcin, paso
2. La llegada de esta confirmacin libera entonces al cliente. En este punto tanto el cliente
como el servidor estn en ejecucin y tiene establecida una conexin. Es importante sealar
que la confirmacin de recepcin 2 es generada por el cdigo del protocolo mismo, no en
respuesta a una primitiva al nivel de usuario. Si llega una solicitud de conexin y no hay un
escuchador, el resultado es indefinido. En algunos sistemas el paquete podra estar puesto
en cola durante un breve tiempo de espera de un LISTEN.



Figura 1.5 Paquetes enviados en una interaccin simple cliente-servidor
sobre una red orientada a la conexin.

El paso siguiente es que el servidor ejecute RECEIVE para prepararse para aceptar la
primera solicitud. Normalmente, el servidor hace esto de inmediato en cuanto esta libre de
LISTEN, antes de que la confirmacin de recepcin pueda volver al cliente. La llamada
RECEIVE bloquea al servidor.

Entonces el cliente ejecuta SEND para transmitir sus solicitudes paso 3, seguidas de la
ejecucin de RECEIVE para obtener las respuesta.
La llegada del paquete de solicitud a la mquina servidor desbloquea el proceso del
servidor para que pueda procesar la solicitud. Una vez hecho su trabajo, utiliza SEND para
devolver las respuestas al cliente, paso 4. La llegada de este paquete desbloquea al cliente,
que ahora puede revisar la respuesta. Si el cliente tiene solicitudes adicionales las puede
hacer ahora. Si ha terminado puede utilizar DISCONNECT para finalizar la conexin. Por
lo comn un DISCONNECT inicial es una llamada de bloqueo, que suspende al cliente y
enva un paquete al servidor en el cual le indica que ya no es necesaria la conexin, paso 5.
Llamadas de
sistema
Kernel
Controla
dores
Pila
de
proto
colos
Proceso del
servidor
Kernel
Controla
dores
Pila
de
proto
colos
Mquina cliente Mquina servidor
1
2
3
4
5
6
1 Solicitud de conexin 2 ACK
3 Solicitud de datos 4 Respuesta
3 Desconecta 6 Desconecta
Proceso
del
cliente
Sistema
operativo
30
Cuando el servidor recibe el paquete tambin emite un DISCONNECT, enviando la
confirmacin de recepcin al cliente y terminando la conexin. Cuando el paquete del
servidor, paso 6, llega a la mquina cliente, el proceso del cliente se libera y finaliza la
conexin. Y as es el modo en que funciona la comunicacin orientada a la conexin.

Lo anterior no del todo tan sencillo, hay muchas cosas que pueden fallar. La temporizacin
puede estar mal por ejemplo, CONNECT se hace antes del LISTEN, se pueden perder
paquetes, etc.


1.14 Servicio asequible por medio de varios protocolos

Los servicios no necesitan elegir entre transportacin sin conexiones y orientada a
conexin; es posible usar ambas. Esto quiere decir que el mismo servicio puede estar
disponible en varios protocolos de transportacin aumenta la flexibilidad puesto que hace
disponible el servicio a clientes que tal vez no tengan acceso a uno de los dos protocolos de
transportacin.

Existen dos posibles implantaciones de un servidor multiprotocolo. La primera es directa:
existen dos servidores para el mismo servicio. Uno se vale de la transportacin sin
conexiones y el otro de la transportacin orientada a conexin. La segunda es ms
complicada: un solo programa servidor interacta a la vez con varios protocolos de
transportacin. El servidor acepta solicitudes de cualquiera de ellos y usa el protocolo en el
que llegan para transmitir sus respuestas.


1.15 Interacciones cliente-servidor complejas

Parte de la funcionalidad mas interesante y til del cmputo cliente-servidor se deriva de
las interacciones arbitrarias entre clientes y servidores. En particular se nota:

Una aplicacin cliente no esta restringida a acceder a un solo servidor para un servicio. Una
aplicacin puede ser primero cliente de un servicio y luego de otro. El cliente contacta con
otro servidor, tal vez de otra computadora, para cada servicio.

Una aplicacin cliente no esta restringida a acceder un solo servidor para cada servicio
dado. En algunos servicios, cada servidor ofrece informacin diferente a la de otros
servidores de otras computadoras. Por ejemplo, un servidor calendario puede dar la hora y
fecha de la computadora en que se ejecuta. Un servidor de una computadora de otro huso
horario da una respuesta diferente. En otros servicios, todos los servidores dan la misma
informacin. En tales casos, el cliente puede mandar una solicitud a varios servidores para
mejorar el desempeo, el cliente usa la informacin del servidor que responde primero.

No se evita que una aplicacin servidora lleve a cabo ms interacciones cliente-servidor, el
servidor de un servicio puede ser cliente de otro. Por ejemplo, un servidor de archivos que
necesita registrar la hora a la que se accedi a un archivo puede ser el cliente de un servidor
horario. Es decir, al manejar una solicitud por un archivo, el servidor de archivos transmite
31
una solicitud al servidor horario, espera una respuesta y contina manejando la solicitud de
archivo.


1.16 Interacciones y dependencias circulares

Se deben planear con mucho cuidado los servidores para evitar dependencias circulares,
para evitar el surgimiento de varios problemas como por ejemplo, un servidor de archivos
que utiliza un servidor horario para obtener la hora actual al acceder a un archivo. Puede
resultar una dependencia circular, si el servidor horario tambin utiliza al servidor de
archivos. Por ejemplo si se pide a un programador que modifique el servidor horario para
que lleve un registro de cada solicitud. Si el programador decide que este servidor se vuelva
cliente del servidor horario que, a su vez, es cliente del servidor de archivos, puede resultar
un ciclo; el servidor de archivos, se vuelve cliente del servidor horario, que, a su vez es
cliente del servidor de archivos, etc.

Aunque las dependencias entre pares de servidores son fciles de detectar y evitar, un grupo
de dependencias ms grande tal vez no sea tan obvio. Imagine un ciclo de dependencias que
comprenda una docena de servidores, operando cada uno en una computadora
independiente. Si un programador diferente mantiene cada servidor, puede ser difcil
identificar las dependencias.


1.17 Servicios proporcionados por mltiples servidores.

Los servicios pueden implementarse como distintos procesos de servidor en computadoras
separadas interaccionando, cuando es necesario, para proporcionar un servicio a los
procesos clientes. Los servidores pueden dividir el conjunto de objetos en los que est
basado el servicio y distriburselos entre ellos mismos, o pueden mantener copias replicadas
de ellos en varias mquinas. Figura 1.6.

El Web proporciona un ejemplo tpico de paricin de datos en el que cada servidor Web
administra su propio conjunto de recursos. Un usuario puede emplear un navegador para
acceder al recurso en cualquiera de los servidores.

La replicacin se utiliza para aumentar las prestaciones y disponibilidad y para mejorar la
tolerancia a fallos. Proporciona mltiples copias consistentes de datos en proceso que se
ejecutan en diferentes computadoras figura 1.7. Por ejemplo, el servicio Web
proporcionado por altavista.digital.com se encuentra redirigido hacia varios servidores con
la base de datos replicada en memoria.

Otro ejemplo de un servicio basado en datos replicados es el servicio de Informacin de
Red de Sun (NIS, Network Information Service), que se utilizara en una red de rea local
(LAN) cuando los usuarios entran en el sistema. Cada servidor NIS tiene su propia rplica
del archivo de contrasea que contiene una lista de los nombres de usuarios y las claves de
acceso con criptografa.
32



Figura 1.6 Clientes que invocan a servidores individuales.





Figura 1.7 Un servicio proporcionado por mltiples servidores


1.18 Servidores Proxy y cach.

Una cach es un almacn de objetos de datos utilizados recientemente, y que se encuentran
ms prximos que los objetos en s. Al recibir un objeto nuevo en una computadora se
aade al almacn de la cach, reemplazando, si fuera necesario, algunos objetos existentes.
Cuando se necesita un objeto de una copia actualizada. Si no, se buscar una copia
actualizada. La cach pueden estar ubicadas en cada cliente o en un servidor Proxy que
puede compartirse desde varios clientes.
Cliente
Cliente
Servidor
Servidor
Invocacin
Resultado
Invocacin
Resultado


Computadora
Proceso
Cliente
Cliente
Servidor
Servidor
Servidor
Servicio
33

La cach se utilizan intensivamente en la prctica. Los navegadores Web mantiene una
cach de las pginas visitadas recientemente, y de otros recursos Web, en el sistema local
de archivos del cliente; entonces utilizan una peticin especial http para comprobar si dicha
pginas han sido actualizadas en el servidor antes de sacarlas en pantalla.

Los servidores Proxy para el Web proporcionan una cach compartida de recursos Web a
las mquinas cliente de uno o ms sitios. El propsito de los servidores Proxy es
incrementar la disponibilidad y prestaciones del servicio, reduciendo la carga en redes de
rea amplia y en servicio Web. Los servidores Proxy pueden desempear otros roles. Por
ejemplo, pueden ser utilizados para acceder a servidores Web remotos a travs de un
cortafuego. Figura 1.8.




Figura 1.8 Un servidor Proxy de tipo WEB.


1.19 Procesos de igual a igual

En esta arquitectura todos los procesos desempean tareas semejantes, interactuando
cooperativamente como iguales para realizar una actividad distribuida o cmputo sin
distincin entre cliente y servidores. En este modelo, el cdigo en los procesos parejos o
iguales mantiene la consistencia de los recursos y sincroniza las acciones a nivel de la
aplicacin cuando es necesario. Un ejemplo con tres instancias de estas situaciones; n
procesos parejos podrn interactuar entre ellos, dependiendo el patrn de comunicacin de
los requisitos de la aplicacin. Figura 1.9.

Cliente
Cliente

Servidor
proxy
Servidor
web
Servidor
web
34



Figura 1.9 Una aplicacin distribuida basada en procesos de igual a igual.



1.20 Variaciones en el modelo cliente servidor.

Pedemos distinguir distintas variaciones del modelo cliente servidor, dependiendo de la
consideracin de los factores siguientes:

El uso de cdigo mvil y agentes mviles.

Las necesidades de los usuarios de computadoras de coste bajo y con recursos
hardware limitados, que son muy sencillos de manejar.

El requisito de aadir o eliminar de una forma conveniente dispositivos mviles.


1.21 Cdigo mvil.

Los applets
1
son el ejemplo ms conocido y ms ampliamente extendido de cdigo mvil;
un usuario que ejecute un navegador y que seleccione un enlace con un applet, cuyo cdigo
est almacenado en un servidor Web, descargar el cdigo en el navegador y se ejecutar
all, Una ventaja de ejecutar el cdigo descargado localmente es que puede proporcionar
una buena respuesta interactiva puesto que no sufre ni de los retardos ni de la variabilidad
del ancho de banda asociados con la comunicacin en la red.


1
George Couloris y otros 2001 George Colouris, jean Dollimore, Tim Kindberg.(2001) Sistemas
Distibuidos Conceptos y Diseo. Pp 34-35.
Aplicacin

Cdigo de
coordinacin
Aplicacin

Cdigo de
coordinacin
Aplicacin

Cdigo de
coordinacin
35
Acceder a los servicios significa ejecutar cdigo que pueda invocar sus operaciones.
Algunos servicios estn probablemente tan estandarizados que podemos acceder a ellos
mediante una aplicacin existente y bien conocida, el Web es el ejemplo ms comn, pero
incluso en este caso, algunos sitios Web utilizan funcionalidades que no se encuentran en
los navegadores estndar y precisan la descarga de cdigo adicional. Este cdigo adicional
puede. Por ejemplo, comunicar con el servidor. Consideremos una aplicacin donde se
necesita que los usuarios dispongan de informacin actualizada segn se hagan cambios en
el origen de los datos en el servidor. Esto no se puede conseguir mediante las interacciones
normales con el servidor Web, que siempre se inician por conseguir mediante las
interacciones con el servidor Web, que siempre se inicia por parte del cliente. La solucin
es utilizar software adicional que trabaja de una forma a la que a veces se refiere como
modelo push, donde el servidor, en lugar del cliente, es el que inicia las interacciones.

Por ejemplo, un corredor de bolsa puede proporcionar un servicio personalizado para
notificar a los usuarios los cambios en las cotizaciones; para utilizar dichos servicio, cada
usuario debiera haber descargado un applet especial, que recibe las actualizaciones del
servidor del corredor, las presenta en pantalla al usuario y quiz realiza operaciones
automticas de compra y venta, desencadenadas por las condiciones prefijadas por el
usuario y almacenados localmente en la computadora del mismo.


1.22 Agentes mviles

Un agente mvil es un programa en ejecucin
2
(lo incluye tanto cdigo como datos) que se
traslada de una computadora a otra en la red realizando una tarea para alguien; por
ejemplo, recolectando informacin, y retornando eventualmente con los resultados. Un
agente mvil puede hacer muchas solicitudes a los recursos locales de los sitios que visita,
por ejemplo, accediendo a anotaciones individuales en una base de datos. Si se compara
esta arquitectura con un cliente esttico que realiza solicitudes de algunos recursos,
transfiriendo posiblemente grandes cantidades de datos, hay una reduccin en el coste de la
comunicacin y en el tiempo con la sustitucin de las solicitudes remotas por las locales.

Se puede utilizar agentes mviles para instalar y mantener software en las computadoras de
una organizacin, o comparar los precios de los productos de un nmero de vendedores
visitando el sitio de cada vendedor y realizando una serie de operaciones sobre la base de
datos. Un ejemplo inicial, con una idea similar, es el llamado programa gusano (Word)
desarrollado en Xerox PARC, y que se diseo para utilizar las computadoras desocupadas
con el fin de realizan clculos intensivos
2
.

Los agentes mviles (como el cdigo mvil) son una amenaza potencial de seguridad para
los recursos de las computadoras que visitan. El entorno que recibe el agente mvil debe
decidir a cul de los recursos locales le estar permitido tener acceso, en base a la doble
identidad de ste debe incluir de una forma segura en el cdigo y los datos del agente

2
George Couloris y otros 2001 George Colouris, jean Dollimore, Tim Kindberg.(2001) Sistemas
Distibuidos Conceptos y Diseo. Pp 35-36.

36
mvil. Adems, los agentes mviles tambin pueden ser vulnerables, y pueden no ser
capaces de finalizar su tarea si se les niega el acceso a la informacin que necesitan. Las
tareas realizadas por agentes mviles pueden realizarse por otros medios. Por ejemplo, Los
escaladores (crawlers) Web que necesitan acceder a recursos en servidores Web a travs de
Internet trabajan bastante bien realizando invocaciones remotas a los procesos del servidor.
Por esta razones. La aplicabilidad de agentes mviles puede ser limitada
3
.


1.23 Computadoras de red.

Las aplicaciones se ejecutan en una computadora de oficina local del usuario. El sistema
operativo y el software de aplicacin para computadoras de oficina necesitan normalmente
que gran parte del cdigo y datos activos estn ubicados en un disco local. Pero la gestin
de los archivos de aplicacin y el mantenimiento del software de base local precisa un
esfuerzo tcnico considerable y de una naturaleza que la mayora de los usuarios no estn
cualificados para proporcionarlo.

La computadora de red es una respuesta a este problema. Descargar su sistema operativo y
cualquier aplicacin software que necesite el usuario desde un servidor de archivos
remotos. Las aplicaciones se lanzan localmente pero los archivos se gestionan desde un
servidor de archivos remoto. Tambin pueden ejecutarse aplicaciones en red, como un
navegador Web. Como todos los datos y el cdigo de las aplicaciones estn almacenados en
un servidor de archivos, los usuarios pueden migrar de una computadora de red a otra. Las
capacidades de procesador y de memoria de una computadora de red pueden restringirse
con el fin de reducir el costo.

Si se incluyera un disco, alojara un software mnimo
3
. El resto del disco se utilizara como
almacenamiento intermedio (cach) manteniendo copias de los archivos de programas y
datos que hayan sido cargados recientemente desde los servidores. El mantenimiento de la
cach no precisa esfuerzo manual alguno: los objetos de la cach se invalidan cuando se
escribe una nueva versin del archivo en el servidor relevante.


1.24 Clientes ligeros.

El trmino cliente ligero se refiere a una capa de aplicacin que soporta una interfaz de
usuario basada en ventanas sobre una computadora local del usuario mientras se ejecutan
programas de aplicacin en una computadora remota
3
. Esta arquitectura tienen los mismos
costos bajos de gestin y hardware que en el esquema de computadoras de red, pero en
lugar de descargar el cdigo de las aplicaciones en la computadora del usuario, se ejecuta
en un servidor de cmputo, un potente computador que tiene capacidad para ejecutar gran
nmero de aplicaciones simultneamente. El servidor de cmputo ser normalmente un

3
George Couloris y otros 2001 George Colouris, jean Dollimore, Tim Kindberg.(2001) Sistemas
Distibuidos Conceptos y Diseo. Pp 36-37.

37
multiprocesador o un sistema de computadores fuertemente acoplado (cluster), y que
ejecuta una versin multiprocesador de un sistema operativo como UNIX o Windows NT.

El principal inconveniente de una arquitectura de cliente ligeros se encuentra en actividades
grficas fuertemente interactivas, como CAD o procesos de imagen, en las que los retrasos
experimentados por los usuarios se ven aumentados por la necesidad de transferir imgenes
e informacin vectorial entre el cliente ligero y los procesos de aplicacin, padeciendo
latencias tanto de red como de sistemas operativos
4
. Figura 1.10



Figura 1.10 Clientes ligeros y servidores de clculo


1.25 Implementacin de clientes Ligeros

Los sistemas de clientes ligeros son sencillos en concepto y sus implementaciones son
inmediatas en algunos entornos. El producto WinFrame de Citrix, es una implementacin
comercial del concepto de cliente ligero, utilizada ampliamente, que funciona de una forma
similar. Este producto proporciona un cliente ligero que puede ejecutarse en una gran
variedad de plataformas y soporta un entorno (desktop) que proporciona acceso interactivo
a las aplicaciones corriendo en mquinas Windows. Otras aproximaciones incluyen los
sistemas de computadoras de red virtual (Teleporting y Virtual Network Computer, VNC)
desarrollados en los laboratorios AT&T de Cambridge, Inglaterra. VNC establece las
fronteras en el nivel de operacin de pxeles en pantalla y mantiene el contexto grfico para
los usuarios cuando stos se mueven entre computadoras
4
.


Proceso de
la aplicacin
Cliente
ligero

Red
Servidor de clculo
Computadora de red o PC
38
Captulo 2
Protocolo TCP/IP


En este captulo se estudia el TCP, el protocolo de transportacin principal del grupo de
programas TCP/IP y se explica cmo ofrece servicio confiable.

El TCP cumple una tarea que parece imposible: usa el servicio de datagramas del IP, que
no es confiable, para transmitir datos a otra computadora, pero ofrece un servicio de entrega
confiable a los programas de aplicacin. El TCP debe compensar la prdida o el retardo de
la interred para ofrecer un servicio eficiente de transferencia de datos, y debe hacerlo sin
sobrecargar las redes y los enrutadores. Tras analizar el servicio ofrecido por el TCP a las
aplicaciones se explicarn las tcnicas para lograr la confiabilidad.

2.1 Introduccin a TCP/IP

Hasta hace poco tiempo, los sistemas informticos eran islas que slo podan comunicarse
entre s con dificultad, Al adquirir una computadora, adquira igualmente un sistema de
comunicaciones de red.

En los aos setentas y ochentas, coexistan varias docenas de arquitecturas de red. Los
equipos de las compaas de supercomputadoras denominadas mainframes como IBM,
Digital, Burroughs y Honeywell estaban aislados, ya que no podan comunicarse entre s
debido a que cada empresa aplicaba su propia arquitectura de red. En la poca en que los
fabricantes obtenan su beneficio en la venta de hardware, tendan a concebir los sistemas
propios como un modo de vincular a sus clientes a una marca especfica de computadoras y
equipamiento de red.

A finales de los ochentas, cuando el uso de las LAN (Local Area Network Red de rea
local) era habitual, que los fabricantes siguieran utilizando sus propios protocolos: por
ejemplo Novell utilizaba su protocolo IPX/SPX, Apple dispona de AppleTalk y Microsoft
e IBM se concentraron en NetBEUI. La tarea de comunicar un tipo de LAN con otro de la
competencia poda resultar dantesca. Para que una PC pudiera entenderse con una
mainframe, era preciso utilizar tecnologas que lo convirtieran en una Terminal tonta
integrable en la esfera de influencia de la mainframe. Con frecuencia la simple tarea de
trasladar datos de un entorno a otro requera utilizar un disco intermedio o una cinta que
pudiera leerse desde el sistema de destino. Resultaba prcticamente imposible que dos
sistemas distintos compartieran archivos y datos de manera transparente.

Al final de la dcada de los ochentas, el aislamiento de los sistemas informticos empezaba
a ser inaceptable. Las empresas comenzaban a darse cuenta de que las LAN, consideradas
secundarias en sus inicios, se utilizaban cada vez ms para resolver necesidades en sus
organizaciones y no slo documentos de texto y hojas de clculo. Las LAN se estaban
39
convirtiendo en depsitos de datos crticos a los que deban acceder los programas de las
mainframes.

Si hubiera dependido de ellos, probablemente los fabricantes de computadoras seguiran sin
ponerse de acuerdo sobre el diseo de una arquitectura comn de red. Afortunadamente
para la comunidad de usuarios, un movimiento marginal ha conseguido lo que las empresas
comerciales no han podido lograr. Gracias a una serie de acontecimientos, ha emergido una
arquitectura que permite interconectar distintas redes y distintos tipos de computadoras.

Un grupo de usuarios haba estado haciendo durante mucho lo que otros deseaban hacer.
Durante ms de veinte aos Internet ha sido el contexto en que se han interconectado miles
de computadoras a lo largo del mundo. TCP/IP es el lenguaje de Internet.


Desde su nacimiento, en los ao 70, el grupo de protocolos TCP/IP se ha convertido en el
estndar de la industria de los protocolos de transferencia de datos para niveles de red y de
transporte del modelo OSI. Adems, el grupo incluye muchos otros protocolos que operan a
un nivel tan bajo como el nivel de enlace de datos y tan alto como el nivel de aplicacin.

Los protocolos utilizados en Internet son los nicos que, siendo totalmente operativos
pueden considerarse completamente abiertos. TCP/IP es el nico disponible sin coste
alguno y est definido en un entorno totalmente pblico.

Una de las consecuencias de esta apertura es que TCP/IP ha evolucionado hacia un
conjunto de protocolos y aplicaciones extremadamente variado y rico. El nombre por el que
se conoce comnmente al conjunto de protocolos es irrelevante, ya que TCP/IP son slo
dos protocolos entre los muchos que componen el conjunto.

La intencin de los diseadores de TCP/IP fue que los protocolos funcionaran con las
arquitecturas de red existente. A lo largo de los aos, La popularidad de TCP/ IP ha
inspirado a los diseadores de redes para adaptar los protocolos a la prctica totalidad de las
redes.


2.2 Historia de TCP/IP

Es posible que ninguna organizacin supere en complejidad las necesidades de las redes del
Departamento de Defensa de los Estados Unidos de Amrica. Las computadoras del
departamento de defensa necesitan estar conectadas con los contratistas y las
organizaciones implicadas en la investigacin, incluyendo muchas universidades. Los
componentes de red relacionados con la defensa deben ser muy tolerantes a los daos para
que las defensas de los Estados Unidos permanezcan operativas en caso de desastre.

No es sorprendente que el departamento de Defensa de los Estados Unidos iniciara la
investigacin de paquetes. De hecho, la investigacin sobre protocolos que desemboc en
el conjunto TCP/IP se inicio en 1969.
40

En 1968, ARPA (Advanced Research Project Agency) Agencia de Proyectos de
Investigacin sobre redes utilizando la tecnologa que hoy se denomina intercambio de
paquetes.

La primera red experimental conect cuatro ubicaciones distintas: University of California
at Los Angeles (UCLA), University of California at Santa Barbara (UCSB), University of
UTA y SRI Internacional. Las primeras pruebas fueron esperanzadoras y se fueron
aadiendo nuevas ubicaciones a la red. La red ARPANET, como era denominada, lleg a
incorporar 20 hosts, computadoras anfitrin, en 1972.

El conjunto inicial de protocolos TCP/IP se desarroll a principios de los ochentas y se
convirti en la norma para ARPANET en 1983.

En 1986, el terreno estaba abonado para comercializar la red ARPANET. En ese momento
comenzaron los trabajos de aislamiento de las redes militares de ARPANET. La espina
dorsal, ARPANET, fue desmantelada y sustituida por una red financiada por la NSF
(Nacional Science Foundation Fundacin Nacional de las Ciencias). Actualmente,
NSFNET es la espina dorsal de Internet, gestionada por ANS (Advanced Network
Services). La evolucin de ARPANET dio lugar a una comunidad de usuarios que se
involucraron en los debates y en la especificacin de las normas de la red. Muchos
protocolos de red se desarrollan bajo el control de sus empresas propietarias. Sin embargo,
los debates sobre los protocolos de Internet se desarrollaron en un foro pblico y, por tanto,
los protocolos no pertenecen a ninguna compaa en particular. La responsabilidad de
establecer las normas de Internet recae sobre el Internet Activities Borrad (Comit de
Actividades Internet).

En el ao 1992 dej de funcionar la red que dio origen a Internet, ARPANET, pero en ese
mismo ao, Tim Berners Lee (actualmente el director del WWW Consortium) cre el
lenguaje HTML (Hypertext Markup Language), con el que naci la World Wide Web.

La evolucin del conjunto de protocolos TCP/IP contina en respuesta a la evolucin de
Internet. En los ltimos aos, el acceso a Internet ha sobrepasado a la comunidad original y
est virtualmente disponible para cualquier usuario que disponga de una computadora. Este
crecimiento espectacular ha saturado Internet y ha puesto en evidencia las limitaciones del
diseo de varios protocolos. En Internet nada es permanente excepto el cambio.


2.3 objetivos de TCP/IP

Entre los objetivos principales que requera el departamento de defensa de los Estados
Unidos de Amrica se encontraban los siguientes:

Protocolos comunes. El departamento de defensa de los Estados Unidos requera un
conjunto comn de protocolos que pudiera especificarse en todas las redes para
simplificar los procesos.
41

Interoperabilidad. Si los equipos de distintos fabricantes pudieran funcionar
conjuntamente, el desarrollo sera ms eficiente y se fomentara la competitividad
entre los proveedores. TCP/IP se dise para dar soporte a la incipiente Internet,
entonces denominada ARPANET, en una poca anterior a la aparicin de las PC, en
que la interoperatividad entre productos informticos realizados por diferentes
fabricantes era, cuando menos, algo sin precedentes. Internet estaba, y est
compuesta por muchos tipos diferentes de computadoras y lo que se necesita era un
grupo de protocolos comunes a todas ellas.

Comunicaciones slidas. Era necesario obtener una norma especialmente fiable para
atender las necesidades de defensa de los Estados Unidos. Los protocolos deban
proporcionar conexiones fiables y de alto rendimiento utilizando las tecnologas de
redes de rea extensa relativamente primitivas que estaban disponibles en aquel
momento.

Facilidad de reconfiguracin. Dado que el departamento de defensa de los Estados
Unidos de Amrica dependera de la red, era indispensable poder reconfigurar la red
y aadir o eliminar computadoras sin interrumpir las comunicaciones.


2.4 El protocolo IP

El protocolo IP (Internet Protocol) Protocolo de Internet. A diferencia de la mayora de los
protocolos de capa de red anteriores, ste se diseo desde el principio con la interconexin
de redes en mente. Una forma de visualizar la capa de red es la siguiente. Su trabajo es
proporcionar un medio de mejor esfuerzo es decir; sin garanta, para el transporte de
datagramas del origen al destino, sin importar si estas mquinas estn en la misma red, o si
hay otras redes entre ellas.

Para comenzar con el estudio de la capa de red Internet se explica el formato de los
datagramas de IP mismos. Un datagrama IP consiste en una
La comunicacin en Internet funciona como sigue. La capa de transporte toma flujos de
datos y los divide en datagramas. En teora, los datagramas pueden ser de hasta 64 Kbytes
cada uno pero en la prctica por lo general son de unos 1500 bytes por lo tanto, se ajustan
en una trama de Ethernet. Cada datagrama se transmite a travs de Internet, posiblemente
fragmentndose en unidades ms pequeas en el camino. Cuando todas las piezas llegan
finalmente a la mquina de destino, reensambladas, por la capa de red, dejando el
datagrama original. A continuacin este datagrama se entrega a la capa de transporte, que lo
introduce en el flujo de entrada del proceso receptor.

El protocolo IP, fue diseado para interconectar sistemas basados en redes de intercambio
de paquetes. Dicho sistema se ha venido llamado modelo catanet.

El protocolo IP es el encargado de transmitir datagramas desde un host a otro, si fuera
necesario, va routers intermediarios. El formato completo de los paquetes IP es bastante
42
complejo. IP proporciona un servicio de entrega que se puede describir como no fiable o
como el mejor posible, best-effort, porque no existe garanta de entrega. Los paquetes se
pueden perder, ser duplicados. Sufrir retrasos o ser entregados en un orden distinto al
original, pero esos errores surgen solo cuando las redes subyacentes fallan o cuando el
buffer en el destino est lleno. La nica comprobacin de errores realizada por IP es la
suma de comprobacin, chechsum, de la cabecera, que es asequible de calcular y asegurar
que no se han detectado alteraciones en los datos bien de direccionamiento o bien de
gestin de paquete.

No existe comprobacin de errores en los datos, lo que evita sobrecargas cuando se cruzan
routers, confiando en las comprobaciones para detectar errores de los protocolos de nivel
superior, TCP y UDP.

La capa IP coloca los datagramas IP en paquetes de red adecuados para ser transmitidos
por la red subyacente. Cuando un datagrama IP es mayor que La MTU de la red
subyacente, se divide en el original en paquetes ms pequeos y se reensamblan en su
destino final. Los paquetes pueden seguir siendo fragmentados para adecuarse a las
caractersticas de las distintas redes que cruzan en su camino desde el origen al destino
(cada paquete tiene un identificador de fragmento que hace posible el ensamblado de los
paquetes que llegan desordenados.)

La capa IP debe insertar una direccin fsica de red del destino del mensaje antes de
confirselo a la capa inferior. Esa direccin la obtiene del mdulo de resolucin de
direcciones en la capa de Interfaz de Red Internet.

IP funcion inicialmente sobre ARPANET, que constaba de hosts y de una versin
temprana de routers (llamados PSE) conectados por enlaces de datos de larga distancia.
Hoy en da se utiliza sobre casi todo tipo de tecnologa de red conocida ATM, redes de rea
local como Ethernet y redes Token Ring. IP se encuentra implementado sobre lneas serie y
circuitos telefnicos va el protocolo PPP, haciendo posibles su utilizacin en las
comunicaciones con mdem y otros enlaces serie.

El xito de TCP/IP se basa en su independencia de la tecnologa de transmisin subyacente,
haciendo posible construir intercedes a partir de varias redes y enlaces de datos
heterogneos. Los usuarios y los programas de aplicacin perciben una nica red virtual
que soporta TCP y UDP, y los constructores de TCP y UDP ven una nica red IP virtual,
ocultando la diversidad de medios de transmisin

El protocolo de Internet permite el intercambio de bloques de datos, denominados
datagramas, entre hosts conectados a una red, cada uno de ellos tiene una direccin nica
denominada direccin IP.

IP implementa dos funciones bsicas, el encaminamiento y la fragmentacin. Para la
primera de las funciones se sirve de uno de los campos que aparecen en la cabecera de los
datagramas, se trata de la direccin IP del host destino. Esta direccin es utilizada para
transmitir los datagramas hacia el host correspondiente.

43
La segunda de las funciones est influenciada por el nivel de enlace. Los datagramas
generados por IP deben amoldarse al tamao mximo que es capaz de tratar la red, el cual
est limitado por la capa del nivel de enlace. Si el tamao mximo de una trama (nombre
que recibe la unidad de datos a nivel de enlace) es menor que el datagrama generado por IP,
entonces la capa IP se ve obligada a fragmentar, de manera que los datagramas resultantes
pueden ser enviados por la red.

El protocolo IP trata cada datagrama como una unidad independiente del resto de los
datagramas, no existen conexiones ni circuitos virtuales en el envo de la informacin. Para
llevar a cabo su servicio, IP utiliza cuatro campos especiales:

Tipo de servicio, indica la calidad del servicio deseada.

El tipo de vida establece el tiempo mximo que un datagrama puede tardar en alcanzar su
destino. Este tiempo se va disminuyendo a medida que el datagrama atraviesa los
diferentes nodos de la red. Cuando el valor de este campo llega a cero, el datagrama se
descarta.

Opciones, proporciona la funcionalidad de control en algunas situaciones, se incluyen entre
otros, mecanismos de seguridad, encaminamiento especial, etc.

El campo checksum, proporciona la verificacin de que la informacin se ha recibido de
manera correcta; sin embargo, esta comprobacin se hace nicamente a nivel de la
cabecera, por lo que no existe garanta de que la informacin que transporta el datagrama
sea correcta. Si el checksum falla el datagrama se descarta.

IP es el protocolo de base de la infraestructura TCP/IP y debe formar parte de toda
implementacin TCP/IP. Ha podido comprobar que IP lleva a cabo muchas tareas
esenciales de la red, por ejemplo la entrega de datos entre hosts y el encaminamiento entre
interredes. Sin embargo, IP no es suficiente por s mismo. Si las aplicaciones tuvieran que
utilizar IP como interfaz directa, necesitaran conocer a fondo el funcionamiento de la red
incluyendo su tamao mximo de mensaje. Las aplicaciones que enviaran mensajes de gran
tamao deberan fragmentarlos y reensamblarlos. En otras palabras, toda aplicacin debera
resolver parte de los problemas de comunicacin inherentes a la red.

Para hacer posible la entrega de paquetes IP en una Ethernet, cada computadora conectada
a la red debe implementar el protocolo de resolucin de direcciones (Address Resolution
Protocol, ARP). Considrese primero el caso en el que un host conectado a una Ethernet
utiliza IP para transmitir un mensaje a otro host en la misma Ethernet del receptor que
encuentra en el paquete IP a la correspondiente direccin Ethernet antes de que el paquete
pueda ser entregado. Para hacer invoca el mdulo ARP del computador emisor.

Este enfoque sera ineficiente. Resulta mucho ms conveniente que las aplicaciones estn
aisladas en la medida de lo posible con respecto a la red para que puedan desarrollar su
trabajo aunque se comuniquen con el hardware local.

44


2.4. 1 La funcin de IP

La funcin de IP es encaminar datagramas a travs de una serie de redes interconectadas.
Este proceso se lleva a cabo pasando los datagramas desde un mdulo de Internet hacia
otro, hasta alcanzar el destino deseado. Se entiende por mdulo Internet aquellos servicios
que lleva a cabo la capa de red dentro de una arquitectura TCP/IP.

El protocolo IP trabaja con direcciones IP, el trabajo de traducir nombres de hosts a
direcciones IP es labor de los protocolos de nivel superior.

Una direccin IP est formada por cuatro nmeros enteros, cada uno de ellos de un byte y
separados por un punto. Las direcciones IP se componen de dos partes, la primera de ellas
hace referencia a una red y la segunda a un host concreto dentro de la red. Dependiendo del
nmero de bytes que destinemos a cada parte, nos podemos encontrar con cuatro tipos de
redes A, B, C y D.


2.4.2 Direccionamiento IP

Quizs uno de los aspectos que ofrecieron un mayor desafo en el diseo de los protocolos
de Internet fue la construccin de esquemas de nombres y direccionamientos para los host
que pudieran permitir el encaminamiento de los paquetes IP a sus destinos, El esquema
utilizado deba satisfacer los siguientes requisitos:

Debera ser universal: Cualquier host debera ser capaz de enviar paquetes a
cualquier otro host en Internet.

Debera ser eficiente en el uso del espacio de direccionamiento: es imposible
predecir el tamao ltimo de Internet y el nmero de redes y de hosts a considerar.
El espacio de direccionamiento debe ser repartido cuidadosamente para asegurar
que las direcciones no se agoten Entre 1978-1982, cuando se comenzaron a
desarrollar las especificaciones para los protocolos TCP/IP, se consider que con 2
32

o lo que es aproximadamente lo mismo, con 4000 millones de hosts direccionales
(aproximadamente la poblacin del mundo en esa poca) se tendran suficientes
direcciones. Se ha demostrado que esta estimacin se quedo corta por dos razones:

1. La tasa de crecimiento de Internet ha excedido por mucho todas las
predicciones.
2. El espacio de direccionamiento ha sido reservado y utilizado mucho menos
eficientemente de lo esperado.

El esquema de direccionamiento debe conducir por s mismo al desarrollo de un
esquema de encaminamiento flexible y eficiente, pero las direcciones no deben
45
contener muchas ms informacin de la estrictamente necesaria para que los
paquetes sean encaminados a su destino.

El esquema elegido asigna una direccin IP a cada host en Internet; un nmero de 32 bits
formado por un identificador de red, que identifica de forma nica a una de las subredes de
Internet, y por un identificador de host, que identifica de manera inequvoca al host
conectado a esa subred.

Los trabajos preliminares de TCP/IP se desarrollaron cuando todava no existan las LAN.
No existan normas comnmente aceptadas para las capas de protocolos de red ni para la
asignacin de direcciones fsicas de los dispositivos. TCP/IP utiliza una direccin que
emplea el protocolo IP siguiendo un esquema que permite identificar de manera nica cada
nodo de la red. La identificacin de un nodo en una Internet requiere el uso de dos
porciones de informacin, la red especfica a l que est conectado el nodo y la
identificacin del nodo en esa red.

Los protocolos de las capas superiores de TC/IP no utilizan directamente las direcciones del
hardware de la red. En su lugar, se decidi utilizar un sistema de direcciones fsicas para
identificar los hosts (hosts es el nombre oficial de una estacin terminal de una red
TCP/IP). Las identificaciones lgicas, denominadas direcciones IP, ofrecen varias ventajas.
El encaminamiento se simplifica gracias a que la informacin de una direccin de red se
codifica en la direccin IP. Adems, las direcciones lgicas permiten que TCP/IP, sea
resistente a los cambios en el hardware de la red, si se cambia la tarjeta adaptadora de red,
su direccin fsica es distinta. Aunque cambie por completo la tecnologa de una red si un
dispositivo permanece en la misma red, la direccin IP utilizada por los protocolos de las
capas superiores puede ser la misma.

Hay una gran estabilidad cuando se configura hosts TCP/IP, ya que la configuracin de un
host incluye informacin acerca de otros hosts en forma de direcciones IP. Por ejemplo,
cada host se configura con una gateway predeterminada. Si cambia la direccin de la
gateway debido a una actualizacin del hardware, sera necesario volver a configurar cada
host de la red manualmente. El esquema de direcciones IP simplifica considerablemente la
configuracin de la red.

stas caractersticas particularmente importante en Internet, ya que los usuarios y las
aplicaciones acceden con frecuencia a otros hosts de la red. Resultara muy complicado
informar constantemente a los usuarios de los cambios de direcciones. El servicio de
nombres de dominio (DNS Domain Name Service) reduce la gravedad de este problema
permitiendo que los usuarios identifiquen los hosts mediante nombres en lugar de nmeros.
Inicialmente, los nombres de los hosts y sus direcciones IP se guardaban manualmente en
archivos de texto. El flujo constante de nuevas direcciones habra hecho imposible la
administracin de la red.

Tradicionalmente, los encaminadores se denominan gateways en las redes TCP/IP. El uso
de este trmino ha decado gradualmente, y los ltimos RFC utilizan el termino
encaminador.
46

Una direccin IP identifica al equipo en la red de forma que los paquetes de datos IP se
puedan enrutar correctamente hacia el equipo. Los paquetes de datos IP se puedan enlutar
correctamente hacia el equipo. Los paquetes de datos IP se puedan enrutar correctamente
hacia el equipo. Los paquetes de datos IP son simplemente datos encapsulados en formato
IP destinados a transmitirse mediante TCP/IP. Cada direccin IP de la red debe ser nica;
un conflicto entre direcciones IP entre dos o ms equipos impide que esos equipos tengan
un buen acceso y aprovechamiento de la red.

Lo primero que debe comprender de una direccin IP es que es un nmero que consta de 4
nmeros de 8 bits separados por puntos (algunas veces se llama cuatro octetos). Octeto
significa ocho bits. Por lo tanto, cada octeto en el formato decimal se escribe como un
nmero de o a 255. Este intervalo se ve como 256 nmeros posibles, porque los equipos
consideran que 0 es un valor que se puede utilizar.

El concepto de nmero o direcciones IP se puede entender mejor si se establece una
analoga entre computadoras y telfonos. Del mismo modo que cada telfono posee un
nico nmero a nivel mundial, cada computadora conectada directamente a la red Internet
tendr asignado un nico nmero IP a nivel mundial. Por lo tanto, cualquier computadora
del planeta puede conectar con cualquier otra computadora, siempre y cuando conozca su
nmero IP y, adems, exista un camino fsico (formado en lneas telefnicas conmutadas,
enlaces va satlite, lneas de fibra ptica, etc.) que una o ambas computadoras para que
puedan intercambiar informacin.

La comunicacin entre computadoras se lleva a cabo mediante el intercambio de paquetes.
La semntica de los conjuntos de bytes que recibe una computadora viene dictada por la
aplicacin a la cual van destinados. Los paquetes de informacin que se difunden a travs
de una red de computadoras son encaminados hacia un equipo o host en concreto y dentro
de dichos host a un puerto.

Se puede pensar en un puerto como un canal de comunicacin. Cada computadora dispone
de un total de 65536 canales o puertos, los cuales pueden estar reservados o no estar
activos. Para que un puerto est activo es necesaria una aplicacin que tome el control del
mismo y sea capaz de administrar los paquetes de bytes que llegan por dicho puerto.
Cuando un host recibe un paquete examina su cabecera o seccin de informacin para
averiguar a que puerto va destinado, si existe una aplicacin escuchando dicho puerto,
entonces se le pasan los bytes del paquete para que sta los interprete y acte
consecuentemente. El host no responder a peticiones de conexin encaminadas hacia un
puerto para el cual no existe ninguna aplicacin escuchando o esperando. Es decir, de los
paquetes de bytes remitidos hacia una computadora en concreto, slo se va a atender
aquellos paquetes para los cuales existen una aplicacin escuchando en el puerto al cual van
encaminados.

Los programas de servidores deben contener cdigo que maneje situaciones de:

Autentificacin Verificar la identidad del cliente.
47

Autorizacin Determinar si un cliente dado posee permisos para acceder al
servicio que suministra.

Seguridad de datos Garantizar que la informacin no es revelada, de manera no
intencionada, a clientes sin autorizacin.

Privacidad Preservar la informacin de un usuario de accesos no autorizados.

Proteccin Garantizar que las aplicaciones de red no puedan abusar de los
recursos del sistema.

La distincin entre servicios estndares y no estndares es importantes nicamente cuando
la comunicacin se lleva ms all del entorno local. Dentro de un entorno dado. Los
administradores del sistema suelen definir los nombres de servicio de tal modo que el
usuario final no puede distinguir entre servicios locales y servicios estndares. Los
programadores que construyen aplicaciones en la red que sern empleadas por otros lugares
repartidos a lo largo de todo el planeta deben entender y tomar en cuenta la distincin y
tener cuidado para evitar la dependencia sobre servicios que estn nicamente disponibles
en el entorno local.

Aunque TCP/IP define muchos protocolos de aplicacin estndares, la mayora de los
distribuidores de computadoras suministran solamente una parte de los programas cliente
con su software TCP/IP. Muchas organizaciones disean aplicaciones personalizadas que
emplean el protocolo TCP/IP para comunicarse entre s. Las aplicaciones personalizadas
no-estndares incluyen diversos servicios como puede ser la transmisin de imgenes y de
vdeo para tele conferencia, transmisin de voz, todo tipo de servicios en lnea, acceso a
bases de datos distribuidas, control remoto de sistemas etc.

Cuando los programadores disean software cliente servidor, deben de escoger entre dos
tipos de interaccin: orientada a conexin o no orientada a conexin. Si el cliente y el
servidor utilizan UDP (User datagram Protocol). La iteracin es sin conexin; por el
contrario, si emplean TCP (Transfer Control Protocol), la iteracin es orientada a conexin.
Desde el punto de vista del programador de aplicaciones, la distincin entre el estilo sin
conexin y orientado a conexin es crtica ya que determina el nivel de funcionalidad
proporciona el sistema.

TCP proporciona toda la funcionalidad necesaria para establecer una comunicacin entre
computadoras a travs de Internet Verifica que los datos lleguen al destinatario, y
automticamente retransmite paquetes que por cualquier motivo no llegan al destinatario o
le llegan con errores. Comprueba la integridad de los datos para garantizar que no se
corrompan durante su transmisin. Emplea secuencias de nmeros para asegurar que los
paquetes de datos llegan al destinatario en el orden correcto, los paquetes duplicados son
eliminados automticamente por el protocolo TCP. Proporciona un control de flujo para
asegurar que el emisor no transmita datos ms rpido de lo que pueden ser consumidos por
48
el receptor. Finalmente, TCP informa tanto al cliente como al servidor si la red deja de estar
operativa por algn motivo.

Por contraste, los clientes y servidores que emplean UDP no tienen garantas de que la
informacin enviada a la red vaya a llegar realmente a su destinatario. Cuando un cliente
enva una peticin, esta puede perderse, ser duplicada o los paquetes de datos pueden llegar
al destinatario fuera de orden. Del mismo modo, la respuesta del servidor puede perderse,
duplicarse, retardarse o llegar desordenada. Los programas de aplicacin cliente servidor
deben llevar a cabo las acciones oportunas para detectar y corregir tales situaciones de
error.

Sin embargo, el empleo del protocolo UDP puede ser una alternativa interesante ya que
permite un transporte de informacin ms eficaz. UDP no introduce errores, nicamente se
fundamenta en la red IP para transportar paquetes. Por el contrario, IP depende del
hardware de red sobre el que se asienta y las puertas de enlace intermedias. Desde el punto
de vista del programador, la consecuencia de emplear UDP es que este trabaja bien si la red
sobre la que se asienta funciona bien. Por ejemplo. UDP funciona bien en un entorno local
porque los posibles errores raramente se producen. Los errores se suelen producir cuando
la comunicacin se expande a una red de rea extendida (WAN)

Los programadores a veces cometen el error de elegir un protocolo sin conexin(UDP),
construyendo una aplicacin que hace uso del mismo, pero verificando el funcionamiento
de las aplicaciones en una red de rea local.. Debido a que una red de rea local raramente o
nunca retrasa los paquetes, los pierde o los entrega fuera de orden, la aplicacin da la
sensacin de que funciona correctamente. Sin embargo, si se hace una prueba en una red de
rea extensa, puede darse el caso de que el programa falle o genere resultados incorrectos.

Los principales, del mismo modo que los profesionales experimentados, prefieren emplear
una comunicacin orientada a conexin a la hora de disear sus aplicaciones de red. Un
protocolo orientado a conexin hace que la programacin resulte ms simple, y releva al
programador de la responsabilidad de detectar y corregir errores de comunicacin.

Por norma, general, los programadores de aplicacin slo utilizaran el UDP s el
protocolo de aplicacin a implementa especifica que se debe de emplear el UDP (puede ser
que el protocolo de aplicacin haya sido diseado para manejar errores que se puede
producir durante la comunicacin). El protocolo de aplicacin relega la seguridad de
comunicacin al hardware y no importa la prdida de algunos paquetes de informacin. La
aplicacin no puede tolerar la sobrecarga (overhead) o retraso (delay) requerido por los
circuitos virtuales TCP.


2.4.3 Formato de cabecera de datagramas IP

En la figura se muestra los campos de una cabecera de diagrama IP, incluyendo la direccin
IP FUENTE, que tiene la direccin de Internet del transmisor, la direccin IP DESTINO,
que es la direccin Internet del destinatario, y el campo de TIPO, que especfica el tipo de
datos. Figura 2.1
49

0 4 8 16 19 24 31
VERS LONG C TIPO DE SERVICIO LONGITUD TOTAL

IDENTIFICACIN BANDERAS DESPLAZAMIENTO
DE FRAGMENTO

TIEMPO DE VIDA TIPO CIFRA DE COMPROBACION DE CABECERA

DIRECCION IP FUENTE

DIRECCIN IP DESTINO

OPCIONES IP (PUEDEN OMITIRSE) RELLENO

COMIENZO DE DATOS

Figura 2.1 Campos de la cabecera de datagrama IP. Tanto la fuente como
el destino son direcciones de Internet.

Los campos de la cabecera de datagrama IP tienen tamaos fijos. El datagrama comienza
con un nmero de versin de protocolo de cuatro bits la versin todava en uso es de cuatro
bits, y una longitud de cabecera de cuatro bits que indica el nmero de cantidades de 32 bits
de la cabecera. El campo de TIPO DE SERVICIO contiene una cifra que indica si el
transmisor prefiere que el datagrama viaje por una ruta con retardo mnimo o una ruta con
un mximo de rendimiento; el enrutador que conoce varias rutas al destino puede
aprovecharla para escoger la ruta. El campo de LONGITUD TOTAL tiene un entero de 16
bits que indica la cantidad de octetos del datagrama, incluyendo la cabecera y los datos.

El campo de tiempo de vida sirve para que los datagramas no viajen eternamente por una
trayectoria en ciclo ya que estas trayectorias pueden aparecer cuando falla el software o
falla el administrador configura mal las rutas. El transmisor inicia el campo de TIEMPO
DE VIDA con un valor entero entre 1 y 255. Cada enrutador que maneja el datagrama
disminuye en 1 el TIEMPO DE VIDA.

Si el campo de CIFRA DE COMPROBACIN DE CABECERA asegura que los bits de la
cabecera no cambien durante el trnsito. El transmisor calcula la suma de complemento de
uno de todas las cantidades de 16 bits de la cabecera, excluyendo el campo de cifra de
comprobacin del mismo y luego almacena el complemento de uno de la suma en el campo
de CIFRA DE COMPROBACIN DE CABECERA. El receptor calcula la misma suma de
16 bits de los datos de la cabecera, incluyendo el campo de cifra de comprobacin. Si la
cifra de comprobacin es correcta, el resultado es cero.



2.4.4 IP versin 6

La versin 4 del protocolo IP ha demostrado tener una vida especialmente larga. El RFC
791 se public en 1981 y sigue siendo la especificacin estndar de IP. Sin embargo,
50
nuevas peticiones cursadas a travs de Internet han estimulado el esfuerzo para definir un
nuevo protocolo de interred.

Las direcciones IPv6 son de son de 128 bits (16 bytes). Estos proporciona un nmero
realmente astronmico de entidades direccionales: 2
128
, o aproximadamente 3 X10
38
.
Tanenbaum calcula que esto es suficiente para asignar 7 X10
23
direcciones IP por metro
cuadrado en toda la superficie de la tierra. De manera ms moderada, Huiteman calcula
que, suponiendo que las direcciones IP sean asignadas de manera tan ineficiente como los
nmeros de telfono, a cada metro cuadrado de La Tierra (ya sea tierra o mar) le tocan 1000
direcciones.

La responsabilidad del desarrollo de la versin 6 de IP (IPv6) recae sobre el grupo de
trabajo IPNG (IP Next Generation) del IETF. Actualmente. IPv6 se encuentra en la fase de
borrado de normalizacin y existen numerosos documentos publicados en Internet. El
nuevo protocolo, IP versin 6(RFC 1883), es un protocolo optativo envas de
normalizacin. Los cambios con respecto a IPv4 ataen a las siguientes reas:

Ampliacin de las direcciones IP de 32 bits a 128 bits. El nuevo esquema admitir ms
niveles jerrquicos de direcciones, muchos ms nodos y una configuracin automtica de
las direcciones ms sencillas.

Algunos campos han sido eliminados o han pasado a se opcionales para simplificar el
formato de la cabecera.

Mejoras para facilitar el uso de extensiones y opciones.

Mejorar en la autentificacin, la integridad de los datos y la privacidad. IPv4 no es un
protocolo seguro y ha frenado el desarrollo de las transacciones comerciales en Internet.





2.5 TCP

El Protocolo de Control de Transmisin (TCP) es el mtodo ms seguro de mover trfico
de red entre un cliente y un servidor o entre subredes en general. Aunque TCP se presenta
como parte del grupo de protocolos de Internet (TCP/IP), es un protocolo de propsito
general que se puede adaptar para utilizarlo con otros sistemas de entrega.

TCP es un protocolo Orientado a Conexin que genera un circuito virtual entre dos
entidades de red y que proporciona fiabilidad extremo a extremo. Para garantizar el buen
funcionamiento de de la red, TCP utiliza diferentes tcnicas que maximizan el rendimiento
de las conexiones asegurando que los segmentos de datos que manipulan tienen un tamao
ptimo, y la velocidad de envo es la ms indicada para el circuito virtual establecido. TCP
51
utiliza una tcnica conocida como acuse de recibo para garantizar la llegada de los datos a
la entidad remota.

Las conexiones TCP funcionan de una forma muy parecida a como lo hacen las conexiones
va telefnica, El usuario que est a un lado de la lnea inicia una comunicacin y sta debe
ser aceptada por el usuario que se encuentra al otro lado.
Cuando un cliente decide establecer una comunicacin con un servidor, es necesario que
ambos estn de acuerdo en participar, de lo contrario la comunicacin no se podr llevar a
cabo.

Una conexin TCP viene identificada por una pareja de sockets, es decir, una direccin IP y
un nmero de puerto en cada extremo. La ventaja de este mtodo es que un nico host es
capaz de mantener diferentes conexiones TCP a travs de un mismo puerto. Esto es posible
debido a que los paquetes que recibe el host se diferencian unos de otros porque utilizan
sockets distintos.

TCP es un protocolo fiable. Se esfuerza por entregar los datos en su destino, verifica si se
producen errores, repite los envos cuando es necesario y slo informa a las capas
superiores si no consigue realizar una transmisin correcta. TCP se diseo para cumplir los
requisitos de solidez en las transmisiones cuando la fiabilidad de las redes de rea extensa
era baja. En la actualidad, sigue siendo adecuado para las aplicaciones que requieren un
transporte fiable. El precio de la robustez de TCP es un elevado nivel de trfico en la red. Si
no se requiere una alta fiabilidad es preferible utilizar un transporte que genere menos
trfico.

TCP (RFC 793) proporciona una comunicacin fiable entre los procesos que se ejecutan en
los hosts interconectados. La comunicacin host a host funciona con independencia de la
estructura de la red. TCP no se encarga del encaminamiento de los datos a travs de la
interred; la responsabilidad de la infraestructura de la red recae sobre IP. En la capa de host
a host, el TCP a un host se comunica directamente con el de otro sin tener en cuenta si
pertenece a la misma red o a redes remotas. De hecho, los encaminadores no implementan
TCP a menos que un host que ejecute procesos de la capa superior se encargue de realizar
el encaminamiento.

TCP desconoce la infraestructura de la red. Es posible utilizar diversas tecnologas
incluyendo las de conmutacin de circuitos o de paquetes en redes de rea local y extensa
TCP utiliza direcciones IP para identificar a los hosts sin considerar las direcciones fsicas.

2.5.1 Servicio Terminal a Terminal y datagramas

Se dice que el protocolo TCP es un protocolo Terminal a Terminal porque ofrece una
conexin directa entre la aplicacin de la computadora local y otra remota. Las aplicaciones
solicitan que el TCP establezca la conexin, transmita y reciba, y la cierre.

Las conexiones que ofrece el TCP se llaman conexiones virtuales porque se establecen en
el software. En efecto, el sistema de interred no ofrece apoyo de hardware y software a las
52
conexiones, sino que son los mdulos TCP de dos mquinas los que intercambian los
mensajes y crean as la ilusin de una conexin.

El TCP se sirve del IP para llevar los mensajes. Cada mensaje de TCP se encapsula en un
datagrama IP y se transmite por la red. Cuando llega al host de destino, el IP pasa por su
contenido al TCP, cabe sealar que aun cuando el TCP aprovecha el IP para llevar los
mensajes, ste no lee ni interpreta, por lo tanto, el TCP trata al IP como un sistema de
comunicacin de paquetes que conecta los hosts de los puntos terminales de la conexin. El
IP trata los mensajes IP como datos por transferir.

La figura 2.2 es un ejemplo de interred, condos hosts y un enrutador, que ilustra la relacin
entre TCP e IP.


Figura 2.2 Ejemplo de interred ilustra porqu el TCP es un protocolo de
transportacin Terminal a Terminal. El TCP ve al IP como mecanismo
que le permite intercambiar mensajes con un TCP remoto


2.5.2 Formato de segmento TCP

El TCP emplea el mismo formato para todos los mensajes, incluyendo datos, acuses de
recibo y mensajes del acuerdo de tres vas para crear y terminar conexiones. En el TCP se
usa el trmino segmento para referirse al mensaje, en la figura 2.2 se ilustra el formato del
segmento.






Aplicacin

TCP
IP
Interfaz de
red
Aplicacin

TCP
IP
Interfaz de
red
IP
Interfaz de
red
Red 1 Red 2
Host A
Enrutador
Host B
53
0 4 10 16 24 31

PUERTO FUENTE

PUERTO DESTINO

NMERO DE SECUENCIA

NMERO DE ACUSE DE RECIBO

LONG C


SIN USO

BITS DE CDIGO

VENTANA


CIFRA DE COMPROBACIN

APUNTADOR URGENTE


INICIO DE LOS DATOS.

Figura 2.3 Formato de segmento TCP. Todos los mensajes transmitidos por el TCP de una
mquina al de otra tienen este formato, incluidos datos y acuses de recibo.

Para entender el formato de segmento de datos, hay que recordar que las conexiones TCP
constan de dos flujos de datos, uno para cada direccin. Si las aplicaciones se transmiten
simultneamente, el TCP puede mandar un segmento con el acuse de recibo de los datos de
entrada, un anuncio de ventana con el espacio de buffer disponible y datos de salida. Por lo
tanto, algunos de los campos del segmento se refieren al flujo de datos que viaja de ida,
mientras que otro a los datos de regreso.

Cuando una computadora transmite un segmento, los campos NMERO DE ACUSE DE
RECIBO y VENTANA se refieren a datos de entrada: NMERO DE ACUSE DE
RECIBO indica el nmero de secuencia de los datos recibidos y VENTANA indica el
espacio de buffer disponible para mas datos. NMERO DE SECUENCIA se refiere a los
datos de salida. Es el nmero de secuencia de los datos del segmento. El receptor lo utiliza
para reordenar los segmentos que llegan en desorden y calcular un nmero de ACUSE DE
RECIBO. PUERTO DESTINO identifica el programa de aplicacin del receptor que debe
recibir los datos y PUERTO FUENTE identifica el programa de aplicacin que transmite
los datos. Por ltimo, el campo de CIFRA DE COMPROBACIN cubre la cabecera y los
datos del segmento TCP.


2.5.3 Corrientes de datos en TCP

Desde su perspectiva, los procesos y las aplicaciones de los hosts se comunican
transmitiendo corriente de datos. No se preocupan de los mecanismos de fragmentacin de
los datos ni del control de flujo.

54
El interfaz entre TCP y el proceso local se denomina puerto. Es un mecanismo que permite
que el proceso llame a TCP y que TCP, a su vez, entregue las corrientes de datos a los
procesos adecuados.

Los puertos se identifican mediante un nmero de puerto. Los fabricantes que implementan
TCP disponen de gran libertad para asignar nmeros de puertos a los procesos aunque La
Autoridad de Nmeros Asignados de Internet (IANA Internet Assigned Numbers
Authority) ha dedicado nmeros de puerto especficos a una serie de procesos comunes. El
RFC de nmeros asignados (RFC 1700) describe estos casos, que se denominan puerto bien
conocido. El conjunto de puertos bien conocidos resulta adecuado para establecer
conexiones entre los procesos ms comunes. Por ejemplo, el proceso telnet Server dispone
de un puerto bien conocido que facilita el inicio de una sesin Telnet desde un host.

Para especificar plenamente una conexin, la direccin IP del host se aade al nmero del
puerto. Esta combinacin se denomina socket. Por consiguiente, un nmero de socket es
nico en toda la interred. Una conexin entre dos hosts queda totalmente descrita por los
sockets asignados a cada terminal de la conexin. La conexin entre dos sockets
proporciona una ruta de comunicacin bidireccional (duplex total) entre los dos procesos.


2.5.4 Control de flujo por medio de Ventanas en TCP.

TCP se encargas de control el flujo entre los hosts y, parea ello, utiliza ventanas. El host
receptor enva una ventana al host emisor especificado el nmero de octetos que puede
aceptar el TCP receptor. El TCP emisor no transmite despus de recibir la ventana hasta
recibir un acuse que confirme la recepcin de los datos.

El tamao de ventana de recepcin TCP indica la capacidad de datos de la memoria
intermedia del host receptor. Es la cantidad mxima de datos que un host puede gestionar
en un momento dado.

La eficacia de la transmisin de mensaje aumenta cuando stos se fragmentan segn la
unidad mxima de transferencia (MTU Maximum Transfer Unit), el tamao mximo de
mensajes que puede viajar a travs de una determinada ruta de la red. Cuando se establece
una conexin, TCP utiliza la MTU de la red para adaptarse al tamao mximo de segmento
(MSS Maximum Segment Size ). Normalmente, el MSS equivale a la MTU menos 40
bytes dedicados a las cabeceras TCP e IP.


2.5.5 Confiabilidad

Para que sea confiable un protocolo de transportacin como el TCP, debe disearse con
cuidado. Los principales problemas que se presentan son: entrega no confiable del sistema
de comunicacin y rearranque de una de las computadoras. Para entender el alcance del
problema se plantea como ejemplo el caso en dos programas de aplicacin establecen una
conexin TCP, se comunican, terminan la conexin y luego establecen una conexin nueva.
55

Debido a que cualquiera de los mensajes puede perderse, duplicarse, retardarse o llegar
fuera de orden, los mensajes de la primera conexin pueden duplicarse o retardarse lo
bastante para que antes se establezca la segunda conexin. Los mensajes deben ser claros,
pues de otro modo, el protocolo los aceptar duplicados de la conexin anterior y van a
interferir con la aplicacin nueva.

Los rearranque de equipo de cmputo son otro reto difcil para los diseadores de
protocolos TCP. Por ejemplo un caso en el que dos programas establecen una conexin y
despus se rearranca una de las computadoras. Aunque el software de protocolo de esta
computadora no sabe nada de la conexin, el software de la que no arranc an considera
valida la conexin. Ms an los paquetes duplicados retardados son especialmente difcil,
porque el protocolo debe ser capaz de rechazar los paquetes de un rearranque previo es
decir debe rechazar los paquetes incluso si el protocolo no tiene registro de la conexin
anterior.

2.5.6 Comunicacin fiable con TCP.

TCP se encarga de entregar las corrientes de datos a sus destinatarios de manera fiable y
ordenada. TCP utiliza nmeros de secuencia de segmentos y acuse de recibos.

Cada octeto de un segmento cuenta con un nmero de secuencia que permite acusar su
recibo. La cabecera TCP especifica el nmero de secuencia de segmentos del primer octeto
del campo de datos. Adems, cada segmento incorpora un nmero de acuse de recibo.

Cuando TCP enva un segmento, retiene una copia y la mantiene en una cola hasta que
llega el acuse de recibo. Sino recibe el acuse, el segmento se transmite nuevamente.

Cuando TCP informa de la recepcin de un octeto con nmero de secuencia de segmento,
libera al TCP emisor de la responsabilidad de todos los octetos anteriores. El TCP receptor
asume la responsabilidad de entrega los datos del segmento al proceso apropiado de la capa
superior. Los acuses de recibo tambin forman parte del mecanismo de ventanas ya que
determinan la cantidad de datos trasmitidos que pueden quedar pendientes en un momento
dado.


2.5.7 Precedencia y seguridad

La cabecera IP proporciona los campos tipo de servicio y opcin de seguridad. TCP puede
utilizar estos campos para implementar la procedencia y la seguridad. Los mdulos TCP
que funcionan en un entorno de seguridad deben identificar los segmentos mediante la
informacin necesaria TCP tambin permite que los procesos de la capa superior
especifiquen la seguridad requerida.



56
2.6 Sockets utilizados por TCP/IP

Los sockets constituyen una interfaz de programa de aplicacin (API) entre TCP, los
procesos y las aplicaciones. Esta API permite a los programadores que sus aplicaciones
accedan a TCP.

Los sockets utilizados por TCP/IP son:

Sockets de corriente. Se utilizan con TCP para lograr un intercambio de datos fiables,
secuencial y bidireccional.

Sockets de datagramas. Se utiliza con UDP para lograr transferencias de datos no fiables y
bidireccionales.


2.7 Puntos fuertes y dbiles de TCP/IP

Estos son los puntos fuertes de TCP/IP:

Ampliamente instalado y admitido por los fabricantes.

Slido y probado a lo largo del tiempo.

Inherentemente enrutable.

Internet puede proporcionar servicios WAN gratuitos entre sitios, adems de la
conectividad de Internet.


Algunos puntos dbiles de TCP/IP:

Es necesario agregar las direcciones de red a cada nodo, Bien mediante DHCP o
bien estticamente, la direccin debe agregar a mano.

El enrutamiento y la segmentacin IP puede ser compleja si el intervalo de
direcciones registradas que tiene es pequeo.


2.8 Clases de direcciones Internet.

Existen cuatro clases de direcciones Internet: A, B, C, y D.

Las direcciones de clase A, con una capacidad de 2
24
hosts en cada subred, estn reservadas
para grandes redes como la norteamericana NSFNet y otras redes nacionales de rea
amplia.

57
Las direcciones de clase B se reservan para organizaciones que gestionan redes con ms de
255 computadoras.

Las direcciones de clase C se dedican al resto de las redes.

Las direcciones clase D se reserva para las comunicaciones de multidifusin (multicasting),
que se implementa slo sobre algunos routers.

Las direcciones Internet de 32 bits contienen un identificador de red y un identificador de
host, normalmente escritos como una secuencia de cuatro nmeros decimales separados por
puntos. Cada nmero representa uno delos cuatro bytes u octetos de la direccin IP.

En la prctica, el esquema de reserva de direcciones IP no se ha mostrado muy efectivo. La
principal dificultad es que el administrador de la red no puede predecir fcilmente el
crecimiento futuro de sus necesidades de direcciones de host y tienen a sobreestimarlas,
solicitando una direccin de clase B en caso de dudad. Al rededor de 1990 ya result
evidente que segn la tasa de reservas en ese momento, el NIC iba a agotar las direcciones
IP hacia 1996. Entonces se tomaron dos decisiones. La primera fue el inicio del desarrollo
de un protocolo IP y un nuevo esquema de direccionamiento, cuyo resultado ha sido la
especificacin IPv6. La segunda decisin fue modificar radicalmente el modo en que eran
reservadas las direcciones IP. El uso del espacio de direcciones IP se volvi ms efectivo
con un nuevo esquema de reserva y de encaminamiento lamado encaminamiento
intetdominio sin clase (classless interdomain routing,CIDR).


58
Captulo 3
Protocolos Remotos

Las primeras redes de computadoras se disearon teniendo en cuenta al hardware como
punto principal y al software como secundario. Esta estrategia ya no funciona. Actualmente
el software de redes es altamente estructurado, en este captulo se examinar en detalle el
funcionamiento de los protocolos de red.


3.1 El Papel de los Protocolos

Para que exista comunicacin la cadena de bytes que se enva en cada paquete debe tener
un significado. Los protocolos son los que se encargan de identificar cual es el formato de
los paquetes y su significado. La mayora de los paquetes tienen en su parte cabecera la
informacin que identifica su origen y destino, longitud del paquete y cdigo de cmo
tratar el cuerpo del paquete. El cuerpo del paquete ser una sucesin de datos
correspondiente a una parte de un archivo o de un mensaje de correo electrnico o puede
ser otro paquete en otro formato.

3.2 Definicin de Protocolo de red

Un protocolo de red es un conjunto de reglas que rigen el formato y el significado de los
paquetes, o mensajes, que intercambian las entidades iguales en una capa de red.

3.3 Introduccin a Protocolos Remotos

Se puede comenzar diciendo que los orgenes de lo que hoy en da se conoce como Internet
se remonta al ao 1969, cuando el departamento de los Estados Unidos de Amrica
trabajaba en un proyecto denominado DARPANET. El objetivo principal por el cual se
inici el proyecto era el poder contar con un sistema de comunicaciones fiable, capaz de
comunicar diferentes estados del pas en el caso de que los sistemas telefnicos existentes
se vieran daados tras un ataque militar.

Las investigaciones realizadas dieron como fruto el nacimiento de un protocolo
denominado TCP/IP (Transmisin Control Protocol/Internet Protocol), un sistema de
comunicacin robusto que basa el envo de informacin en una unidad elemental de datos
denominada datagrama.

Hay Varias aplicaciones TCP/IP de uso comn. Algunas, como FTP y Telnet, son
herramientas que los usuarios utilizan frecuentemente. Otras, aunque menos empleadas, son
fundamentales en las redes TCP/IP.


59
3.4 Protocolo TELNET

El acceso en modo Terminal remoto es una caracterstica de muchas computadoras. Pueden
lograrse mediante una conexin telefnica, pero no tendra sentido realizar una llamada a
California para acceder a una computadora de Berkley existiendo una red tan extensa y
operativa como Internet. Telnet es un programa que posibilita el acceso en modo Terminal
remoto a travs de una red.

Telnet. Hasta hace poco tiempo, para poder establecer una comunicacin con el host de
una red, era necesario disponer del Terminal adecuado, generalmente proporcionado por el
fabricante del propio host. El propsito del protocolo Telnet es proporcionar la facilidad
bidireccional necesaria para que diferentes computadoras (independientemente del
fabricante de estos) puedan acceder a cualquier tipo de host dentro de una red.

Una conexin Telnet utiliza el protocolo de transporte TCP para llevar a cabo el
intercambio de datos. Cuando la conexin se establece, cada extremo de la misma se
denomina Terminal Virtual de Red. El Terminal remoto, que es el host encargado de
proporcionar servicios, se denomina servidor, y el Terminal local se denomina Terminal de
usuario.

El protocolo Telnet fue desarrollado en base a dos ideas fundamentales: la primera es la
idea del Terminal Virtual de Red, la segunda es la negociacin de opciones. Esta ltima es
importante debido a que numerosos hosts dentro de una red desea proporcionar servicios
adicionales a los ya existentes mediante el Terminal Virtual de Red.

Utilizando Telnet est disponible numerosas opciones que permiten al usuario ajustar los
parmetros de la conexin, de manera que se puedan seleccionar diferentes conjuntos de
caracteres, tipos de Terminal, etc.


3.4.1 Cmo funciona TELNET

La arquitectura Telnet se basa en procesos cliente servidor. Un servidor Telnet
ejecutndose en un host remoto mantiene un Terminal virtual: una imagen software de una
Terminal que puede interactuar con el host. Un usuario inicia una seccin Telnet ejecutando
un programa cliente Telnet y conectndose al servidor Telnet. El servidor recibe las
pulsaciones de teclas del cliente y las aplica al Terminal virtual que interacta con otros
procesos del host. El servidor Telnet tambin recibe los datos destinados a la pantalla del
Terminal y los enva al cliente Telnet. La sensacin que percibe el usuario es que la sesin
de Terminal tiene lugar en la computadora local mientras que el host remoto est
interactuando con un Terminal local.

Telnet no encierra ningn secreto, se basa en la emulacin de un terminal de texto,
normalmente Digital VT220, VT100/VT102 o VT52. Estos terminales pueden Llevar a
cabo operaciones sofisticadas basadas en texto, por ejemplo mostrar mens que permitan
60
seleccionar una opcin utilizando las teclas del cursor. No obstante, slo pueden trabajar en
modo de texto.

3.4.2 Limitaciones de TELNET.

Una limitacin de Telnet consiste en que la computadora local no tiene capacidad para
procesar informacin. Todos los procesos tienen lugar en el servidor Telnet remoto, el cual
convierte el host local en una Terminal tonta. Por consiguiente, Telnet no puede
utilizarse como base para realizar operaciones sofisticadas en la red (por ejemplo para
compartir archivos). De hecho, Telnet no cuenta con un mecanismo de transferencia de
archivos y, en caso de necesidad, es preciso recurrir a una sesin independiente de FTP.

Cuando una conexin Telnet ha sido establecida, cada uno de los implicados intenta
obtener el mejor servicio posible por parte del otro. Para llevar a cabo tal cometido, el
protocolo pone a disposicin del usuario una serie de comandos.


3.4.3 Transmisin de datos en TELNET.

Aunque una conexin Telnet a travs de una red es intrnsecamente Full-duplex
(Transmisin de datos en ambas direcciones), el Terminal Virtual de Red es un dispositivo
half-duplex (Transmisin de datos en una sola direccin) que utiliza un buffer de una lnea.
Mientras el buffer del host lo permita, los datos deben acumularse en el host en el que se
estn generando hasta que se tenga una lnea completa de datos preparados para enviar o
hasta que una seal de transmisin especfica que ocurra. Esta seal puede ser generada por
el proceso o por el usuario. La razn de esta regla es debida al coste que lleva procesar
interrupciones a travs de la red. En general la mayora de los sistemas llevan a cabo las
acciones necesarias cuando se ha completado una lnea del buffer de entrada; sin embargo,
un usuario o un proceso quiz necesiten enviar datos antes de que el buffer de salida est
completamente lleno.

Cuando un proceso ha completado el envo de sus datos a una impresora conectada a un
Terminal Virtual de Red y no tiene ms informacin en su buffer de envo tiene que enviar
el comando GA (Go Ahead).

Durante una sesin Telnet, es necesario traducir una serie de cdigos de control a
comandos de Telnet y enviarlos al sistema operativo del host remoto. Estos comandos del
Telnet se representan con un byte denominado IAC (Interpret As Command) seguido de
uno o ms bytes de Cdigo.

Cuando un Terminal enva una interrupcin, el sistema operativo del host lo enva de
inmediato. Sin embargo debido a que Telnet funciona sobre TCP, Los datos se entregan en
orden, y puede ocurrir que pase un pequeo perodo de tiempo hasta que el servidor remoto
notifique la presencia del comando de interrupcin entre el flujo de datos

Cuando un usuario est ejecutando el cliente Telnet bajo un sistema X Window, puede ser
necesario que el servidor Telnet sepa la Posicin del cliente Telnet en dicho sistema de
61
ventanas, ya que por ejemplo, un usuario podra querer iniciar otras aplicaciones X desde el
host remoto utilizando la misma posicin de display que el cliente Telnet.

El esquema de conexin utilizado por el protocolo Telnet utiliza los denominados
terminales virtuales.


3.5 DHCP (Configuracin Dinmica de Hosts)

HTTP funciona generalmente sobre TCP/IP y las conexiones (por defecto) se realizan al
puerto TCP 80. Sin embargo, muchos servidores colocan el servidor WWW en un puerto
diferente, ya sea por motivos de seguridad o para tener varios servidores, cada uno con su
propio puerto, ofreciendo un mismo servicio. Dado que el nico requisito impuesto por http
es trabajar sobre un protocolo de transporte fiable, perfectamente podra utilizarse sobre
redes diferentes a TCP/IP.

El Protocolo de Configuracin dinmica de host (Dinamic Host Configuration Protocol)
proporciona los parmetros de configuracin a las estaciones de una red. Este protocolo
consta de dos componentes. El primero de ellos se encarga de entregar parmetros de
configuracin especficos de cada host desde el servidor DHCP hasta los diferentes clientes
de la red. El segundo es un mecanismo de asignacin de direcciones de red a los hosts.

El protocolo DHCP trabaja bajo una arquitectura cliente/servidor. Por lo tanto, para que un
equipo perteneciente a la red haga el trabajo de servidor DHCP, ste tiene que haber sido
expresamente asignado como tal por el administrador de la red.

El Protocolo DHCP utiliza tres mecanismos para llevar a cabo la asignacin de direcciones
IP. El primero de los mecanismos es la asignacin automtica, mediante la cual, el servidor
DHCP, asigna direcciones IP permanentes a las diferentes estaciones de la red. El segundo
de los mecanismos es la asignacin dinmica, con ella, las estaciones de la red reciben una
direccin IP durante un periodo de tiempo determinado, en la asignacin manual, las
estaciones reciben una direccin IP fijada con anterioridad por el administrador de la red, y
es el servidor DHCP el encargado de transferir dicha direccin a los clientes de la red.

http es un protocolo que se basa en la filosofa cliente/servidor. Un cliente enva un
mensaje, compuesto por un comando un identificador de recurso y la versin del protocolo,
seguido del cuerpo del mensaje, el cual contiene generalmente informacin sobre el cliente.
La respuesta que enva el servidor est formada por una lnea de estado, que incluye la
versin del protocolo, y un cdigo de respuesta, que determina de qu modo se llevo a cabo
la operacin

La conexin entre el cliente y el servidor debe se iniciada por el cliente y cerrada por el
servidor tras el envo de la respuesta a la solicitud; sin embargo, tanto los clientes como los
servidores deben tener en cuenta que una conexin puede cerrarse de manera prematura
debido a una accin del usuario, por el vencimiento de los temporizadores o simplemente
debido a un fallo del programa. Dependiendo de la versin del protocolo, la finalizacin de
la solicitud en curso (por cualquiera de las partes) puede o no finalizar la sesin actual.
62

El proceso de comunicacin entre un cliente y un servidor puede ser directo, cuando los
mensajes no atraviesan ningn intermediario, o puede ser indirecto, cuando el mensaje debe
atravesar diferentes entidades intermediarias, tales como un Proxy o un gateway.

La existencia de entidades como un Proxy mejora la velocidad y, por lo tanto el
rendimiento de la red, debido a que ste almacena en una memoria cach la informacin
devuelta como respuesta a las diferentes solicitudes que enva el cliente y, en caso de
recibir peticiones de datos que ya tienen almacenados, los devuelve sin tener que realizar
una nueva conexin al servidor que los contiene.


3.5.1 Funcionamiento del protocolo DHCP.

Cuando se diseo el protocolo, los objetivos que se buscaban eran los siguientes:

No tener configurar manualmente los clientes

Tener un protocolo que puede funcionar a travs de los routers de la red, de tal
forma que no exista la necesidad de instalar un servidor en cada subred.

DHCP debe ser capaz de interoperar con el Boota relay agent.

DHCP debe poder dar servicio a los clientes BOOTP.

Desde el punto de vista del cliente. DHCP es una extensin del protocolo BOOTP, lo cual
permite a los clientes BOOTP interactuar con los servidores DHCP sin necesidad de
cambiar el software de inicializacin de los clientes. Sin embarga existen algunas
diferencias entre ambos protocolos. En primer lugar DHCP define mecanismos a travs de
los cuales los clientes pueden recibir una direccin IP durante un perodo de tiempo finito.
En segundo lugar DHCP proporcionan los mecanismos necesarios para que un cliente de
red reciba todos los parmetros de configuracin necesarios para poder operar.

El primer servicio ofrecido por un servidor DHCP es el almacenamiento de los parmetros
de red de un cliente. Para ello, el servidor DHCP utiliza un identificador de cliente, que
generalmente suele ser el par direccin IP- nombre del host.

El cliente puede ejecutar una consulta al servidor DHCP para que ste le devuelva sus
parmetros de configuracin.

El segundo servicio ofrecido es la asignacin de direcciones IP a los clientes de la red. El
mecanismo es el siguiente: el cliente solicita el uso de una direccin IP durante un perodo
de tiempo determinado. Este periodo al que se hace referencia es conocido como periodo
de tiempo determinado. Este perodo al que se hace referencia es conocido como periodo
de alquiler, el servidor DHCP intentar asignar la misma direccin IP que dicho cliente
utiliz por ltima vez. Si el cliente lo considera necesario, puede solicitar una direccin
63
durante un perodo de tiempo infinito. En cualquiera de los casos (incluso cuando las
asignaciones son permanentes), el servidor DHCP nunca asignar una direccin IP con
perodo de alquiler infinito, debido a que debe ser capaz de detectar cundo una estacin ha
sido retirada.

En algunos, entornos debido a la escasez de direcciones IP, es necesario que el mecanismo
encargado de la asignacin de direcciones utilice aquellas direcciones cuyo perodo de
alquiler ya ha caducado.

3.6 FTP

FTP (File Transfer Protocol) Protocolo de Transferencia de Archivos es a la vez un
protocolo y un programa que puede utilizarse para realizar operaciones bsicas sobre los
archivos de un host remoto y para transferir archivos entre hosts. Como programa. FTP
permite que los usuarios realicen manualmente operaciones relacionadas con archivos. Las
aplicaciones pueden utilizar FTP como protocolo si requieren sus servicios de archivos.
FTP es una aplicacin segura y fiable, ya que opera sobre TCP. Los usuarios que acceden a
un host utilizando FTP deben autentificar su conexin y, probablemente, proporcionar su
nombre y contrasea. Estos datos pueden incorporarse a la seguridad del host de modo que
su administrador pueda restringir el acceso. FTP es seguro pero enva las contraseas en
forma de texto, lo que no garantiza su privacidad.

FTP permite la transferencia de archivos entre dos hosts de la red. Una particularidad de
este protocolo frente al resto, es que usa dos conexiones para llevar a cabo su trabajo. El
protocolo diferencia entre una conexin de control y otra conexin de datos.

La conexin de control sigue la misma filosofa que las conexiones que se realizan para
protocolos como SMTP, POP3 o NNTP, donde se envan comandos y se esperan respuestas
que indique en si la funcin solicitada se puede llevar a cabo. La diferencia radica en que
los datos no son enviados por esta conexin sino que se abre otra conexin de datos
diferentes para este fin.

La conexin de control, como las conexiones realizadas en otros protocolos, la realiza el
cliente a la direccin IP del servidor y a un puerto conocido y estandarizado para este
servicio, en este caso, el protocolo FTP tiene asignado el puerto 21.

La forma de establecer la conexin de datos se negociar entre el cliente y el servidor,
pudiendo comenzar dicha conexin cualquiera de los dos. En ambos casos se debern
indicar la direccin IP y el puerto al cual realizar dicha conexin

El protocolo FTP fue diseado para ser independiente de las representaciones particulares
que cada host de la red pudiera tener de los datos. Para lograr esta generalidad es necesario
que se indiquen al protocolo cuatro parmetros que establecern la forma en que se van a
representar los datos del archivo que se pretende transferir y estos pueden ser tipo de
archivo, formato de archivo, estructura del archivo, y Modo de transmisin.

64

3.6.1 Anatoma de FTP

FTP incluye componentes cliente y servidor. Un host que ofrece su sistema de archivos
acceden al servidor FTP deben ejecutar un software de tipo cliente FTP en sus
computadoras.

Cuando el cliente FTP abre una conexin al servidor FTP, se establece un canal lgico (un
circuito virtual definido por dos sockets) entre ambos hosts. El canal posibilita la
comunicacin entre los componentes FTP. El resultado final es similar al obtenido tras
montar el sistema de archivos remotos con acceso local limitado. No es posible ejecutar los
archivos remotos a modo de programas pero puede listar directorios, ver el contenido de los
archivos, manipular los directorios locales y copiar los archivos de un host a otro.


3.7 NFS (Network File System Sistema de archivos de red)

NFS fue desarrollado por SUN Microsystems, y muchos fabricantes disponen de licencias y
lo han implementado en varias plataformas. Un servidor NFS puede exportar parte de su
rbol de directorios para uso de los clientes NFS. Los clientes pueden montar los
directorios exportados como si formaran parte de su sistema de archivos nativos.

NFS es un protocolo sofisticado y fiable que no utiliza el transporte TCP. Por razones de
eficiencia, NFS funciona sobre UDP. NFS implementa la seguridad, la fragmentacin de
mensajes y la recuperacin de errores.


3.8 SNMP (Protocolo Simple de Administracin de Red)

La administracin de una red engloba una amplia gama de actividades. Para SNMP,
consiste en recopilar, analizar y ofrecer datos sobre el rendimiento de los componentes de
la red. Los datos recopilados por SNMP incluyen estadstica de rendimiento, informacin
rutinaria y avisos de problemas potenciales o existentes de la red.

Aunque SNMP (RFC 1157) fue diseado para Internet, no depende de los protocolos
TCP/IP y puede funcionar sobre varios protocolos de nivel inferior (por ejemplo IPX/SPX
de Novell). Si se utiliza con TCP/IP, SNMP se basa en el protocolo de datagramas UDP
para reducir el trfico de la red. Las solicitudes SNMP quedan identificadas por un nombre
de comunidad, un identificador de 32 caracteres con distincin de maysculas y minsculas
que, en cierto modo, se utiliza como contra sea. La implementacin es de SNMP pueden
restringir los caracteres vlidos de los nombres de comunidad. Estos nombres se utilizan
para identificar los mensajes SNMP pero se transmiten en formato de texto y, por tanto, no
son seguros.

SNMP es un protocolo que permite la gestin de los recursos que estn disponibles en una
red.
65

Dentro de un entorno de red gestionado con SNMP habr un conjunto de nodos de la red
que se encarguen de la gestin y un conjunto de componentes de la red (hosts, hubs,
routers, modems, etc.) que podrn ser gestionados por estas estaciones.

Para que el software que se encarga de la gestin de la red en las estaciones de gestin
pueda obtener informacin de los elementos de la red, es necesario que dichos elementos
cuenten con un software que permita su comunicacin con la estacin de gestin. Este
software se denomina agente.

Hay otra pieza importante en este entorno, y es la base de datos donde se encuentra toda la
informacin que se gestiona. Esta base de datos se denomina MIB (Management
Information Base).

El agente de gestin se encarga de supervisar un elemento de la red. Se comunica con el
gestor para atender sus peticiones y para informar de eventos acaecidos en objeto
gestionado. El agente de gestin suele residir fsicamente en el elemento gestionado.

El gestor es un software en una estacin de gestin que se comunica con los agentes y que
ofrece al usuario una interfaz a travs de la cual comunicarse con los agentes de gestin
para obtener informacin de los recursos gestionados. Adems recibir las notificaciones
enviadas por los agentes.

Los objetos gestionados son las abstracciones de los elementos fsicos de la red que se
gestionan (tarjeta de red, hub, MODEM, router, etc.). Se podrn manejar los atributos y las
operaciones que se pueden realizar sobre el objeto. De la misma forma, las notificaciones
que dicho objeto puede generar as como las relaciones con otros objetos tambin sern
susceptibles de ser controladas. La base de datos de gestin (MIB) previamente
mencionada est formada por todos los objetos gestionados.

Los protocolos de gestin, es el protocolo que especifica cmo se realizar la
comunicacin entre los agentes de gestin y el gestor.


3.8.1 Elementos de Mensajes SNMP

SNMP define cinco tipos de mensajes:

Get Request: para leer el valor de una o varias variables del MIB.
Get Next Request: para realizar lecturas secuenciales a travs del MIB.
Get Response: es el mensaje de respuesta a un Set Request, Get Requuest o Get
Next Requuest.
Set Request: mensaje enviado para establecer el valor de una variable.
Trap: a travs de este mensaje se hacen notificaciones de eventos.

66
Estos cinco tipos de mensajes SNMP son encapsulados en datagramas UDP. Los
mensajes de particin y respuestas son enviados al puerto 161, mientras que las
notificaciones de eventos usan el puerto 162.


3.9 SMTP

SMTP (Protocolo Simple de Transferencia de Correo) Probablemente, el correo electrnico
es la aplicacin ms importante de Internet. Se basa en el protocolo SMTP descrito en el
RFC 821 (el RFC 822 define el formato de los mensajes). SMTP Transporta mensajes de
correo electrnico entre distintos hosts TCP/IP. Aunque el usuario con experiencia puede
comunicarse directamente utilizando el protocolo SMTP, ste no es el procedimiento
estndar. Normalmente, varias capas de comunicacin intervienen en el proceso.

El objetivo de SMTP (Simple Mail Transfer Protocol) Protocolo de Transferencia Simple
de Correo, es enviar correo de una manera fiable y eficiente. SMTP es independiente del
sistema de transmisin y nicamente requiere un canal de envi de datos fiables y
ordenados.

Una de las caractersticas de SMTP es la capacidad de funcionar a travs de los entornos de
servicios de transporte. Un servicio de transporte proporciona un entorno de comunicacin
entre procesos. Este entorno puede cubrir una o varias redes.

El modelo en que SMTP esta basado, como resultado de una peticin de envo de correo
por parte del usuario, el emisor SMTP, que acta como cliente, establece una conexin
TCP con el receptor SMTP, que hace la funcin de servidor. Este ltimo puede ser el
equipo final al cual va dirigido el mensaje o bien un sistema intermedio. El puerto definido
para llevar a cabo una conexin SMTP es el 25.

Los Comandos SMTP son generados por el cliente y son enviados hacia el servidor Las
respuestas a dichos comandos, por su parte, funcionan de manera inversa, es decir, son
enviadas por el servidor hacia el cliente.

Una vez que el canal ha sido establecido (como Helo), El emisor enva un comando MAIL
indicando quin enva el mensaje. Si el receptor SMTP puede aceptar correo, responder
con una respuesta OK. Posteriormente, el emisor SMTP enva un comando RCPT
(recipient) identificando al destinatario del mensaje. Si el receptor SMTP puede aceptar
mensajes para dicho destinatario, responder mediante un OK, en caso contrario rechazar
el mensaje. Tanto el cliente como el servidor pueden negociar varios destinatarios. Una vez
que han llegado a un acuerdo, el cliente enva los datos del mensaje. Si el servidor recibe
los datos de manera correcta, responder con OK. El canal se cerrar con el comando
QUIIT.




67
3.9.1 Arquitectura del correo SMTP

Los hosts que admiten correo electrnico utilizan un agente de transferencia de correo
(MTA Mail Transfer Agent) para gestionar el proceso. El MTA tiene dos
responsabilidades, enviar y recibir mensajes desde/hasta otros servidores de correo y
proporcionar una interfaz que permita que las aplicaciones accedan al sistema de correo. El
MTA se encarga de proporcionar a los usuarios buzones de correo dotados de una
direccin. Los usuarios finales se comunican con el MTA utilizando uno de los muchos
agentes de usuario (UA User Agent) disponibles. El UA es un sistema de correo que evita
al usuario todas las complicaciones del proceso. Las UA utilizan un protocolo de correo
para comunicarse con el MTA, por ejemplo la versin 3 del protocolo de oficina de correo
(POP3 Post Office Protocol Versin 3; RFC1460).

El elevado uso del correo electrnico de Internet ha provocado que un importante nmero
de aplicaciones por ejemplo los navegadores Web y los examinadores de grupos de
noticias, incorporen al menos un front-end rudimentario para gestionar el correo.


3.9.2 Entrega de correo electrnico

Los sistemas de correo electrnico no estn diseados para realizar intercambio de
mensajes en tiempo real (para ello existen los programas de conversacin Chat). Envan
grandes volmenes de mensajes en un tiempo razonable (no necesariamente corto) con la
menor carga de trabajo posible en la red. Si los mensajes de correo se enviaran a travs de
Internet utilizando conmutacin de paquetes, la red quedara colapsada en pocos minutos.
Por consiguiente, la implementacin de correo electrnico se basa en que la reduccin del
tiempo de transito de los mensajes slo es permisible si reduce la carga de la red. Los
servidores de correo electrnico utilizan un mtodo de almacenamiento temporal y envo de
mensajes.

3.9.3 Caractersticas de SMTP

SMTP es un protocolo bastante antiguo, anterior a la implementacin de los terminales
grficos. Muchos de los tipos de datos que los sistemas modernos pueden transportar no
podan imaginarse en 1982, la fecha de publicacin del RFC 821. Quin podra haber
soado con el correo de archivos de imagen, voz o vdeo? SMTP fue diseado para
transferir mensajes basados en texto ASCII de 7 bits.

El envo de datos binarios a travs de los sistemas de correo SMTP requiere su codificacin
en un formato compatible con loa transmisin de caracteres de 7 bits. El host receptor
decodifica el mensaje para recuperar los datos binarios. Muchos de los agentes usuarios
realizan estas conversaciones de forma automtica en los archivos adjuntos.

SMTP fue desarrollado para prestar un servicio de mensajera no crtica a una comunidad
Internet reducida y cuyas relaciones se basaban en la confianza. Por consiguiente, la
seguridad de SMTP es pobre y no existe encriptacin de menajes. Una persona con
68
experiencia podra extraer los mensajes que viajan a travs de la red pblica. Se recomienda
encriptar los mensajes confidenciales antes de transmitirlos por correo SMTP.

3.10 DNS (Dominio de nombres de Sistemas)

Un sistema de nombre de dominio como DNS (Domain Name System) es necesario para
poder referenciar los recursos de una red mediante nombres que sean cmodos de manejar
por los usuarios. El sistema de nombres traslada estas cadenas proporcionadas por los
usuarios a direcciones de red manejables por los programas y dispositivos de la red.

Adicionalmente el sistema de nombres facilita la organizacin distribuida de los servidores
de nombres, posibilitando la delegacin del mantenimiento de ciertos conjuntos de recursos
a una organizacin y evitando as la centralizacin del servicio.

Se dice que se hace una resolucin directa cuando el usuario proporciona al servidor de
nombres el nombre de un recurso de la red y el servidor le devuelve la direccin de red de
dicho recurso.
La resolucin inversa es el proceso contrario, el usuario proporciona al servidor una
direccin de red de un recurso y obtiene el nombre o nombres con los cuales es conocido
dicho recurso en la red. Los servidores de nombre pueden o no implementar la resolucin
inversa, ya que se trata de un servidor opcional.

3.10.1 Elemento del servicio DNS

El espacio de nombres organizado en forma de rbol, cada nodo del rbol tiene una etiqueta
de un tamao mximo de 63 caracteres y adems tiene asociado un conjunto de recursos. El
nombre de dominio de un nodo es la lista de etiqueta desde el nodo raz.

Los Servidores de nombres son programas que manejan parte de la estructura del rbol, la
cual tienen almacenada localmente en sus bases de datos. Un servidor de nombres podr
contestar a solicitudes que se haga referentes a su parte del rbol y tambin podr ofrecer
referencias a otros servidores que conozcan las restantes partes del dominio de nombres. Se
dice que un servidor de nombres est autorizado sobre cierta informacin cuando sta se
mantiene localmente en este servidor.

Resolvers, son programas que hacen de intermediario entre los procesos cliente y toda la
estructura de DNS. Un resolver debe poder acceder al menos aun servidor directamente,
para obtener de l la informacin solicitada o, en su defecto, obtener referencias a otros
servidores a travs de los cuales continuar la bsqueda. El resolver generalmente ofrece un
conjunto de llamadas al sistema que permiten a cualquier proceso cliente realizar peticiones
DNS.

Con una consulta recursiva, el cliente realiza una peticin y se le devuelve directamente la
respuesta a esa peticin o un error. Si el servidor consultado conoce la respuesta la
devuelve directamente al cliente, en caso de no conocerla contactar con otro servidor de
69
nombres para preguntarle a l. Esta consulta en cadena se puede extender hasta que el
servidor reciba una respuesta o un error que pueda pasar al cliente.
En una consulta iterativa. El cliente adems de una respuesta directa o un error, puede
recibir una referencia a otro servidor de nombres para que realice la consulta en su lugar. El
servidor de nombres consultado puede devolver la respuesta en caso de conocerla, si no la
conoce devolver al cliente una referencia a un servidor para que le realice la consulta.

3.10.2 Transporte de mensajes DNS

Los mensajes DNS pueden transportar mediante TCP o mediante UCP. Ambos usando el
puerto 53 Usando UDP, el mximo tamao de los mensajes sern de 512 bytes sin contar
las cabeceras UDP ni IP. Si intenta enviar ms informacin el mensaje ser truncado y el
bit TR de la cabecera del mensaje ser puesto a 1 para indicar esta situacin.

El transporte usando UDP ser recomendable para las consultas. Hay que tener en cuenta
que UDP no es fiable, por lo que la peticin o la respuesta pueden perderse. Habr que
establecer una poltica al respecto de tal forma que se reintente la solicitud en caso de haber
algn problema.

3.11 http (Hypertext Transfer Protocol)

Hoy en da, el servicio ms extendido de Internet junto con el correo electrnico es sin
lugar a dudas, el WWW. El World Wide Web, es servicio que rene dos potentes tcnicas:
por un lado la bsqueda de informacin y por otro el hipertexto.

El hipertexto(hypertext) es una forma de organizar la informacin, de manera que algunas
partes del texto, denominadas enlaces, se muestran resaltadas, permitiendo acceder al pulsar
sobre ellas a diferentes partes del mismo documento o a otros documentos diferentes,
independiente de su localizacin.

La idea de este tipo de tcnicas de navegacin por Internet naci en el laboratorio europeo
de fsica de partculas del CERN (Suiza). Su creador fue Tim Berners-Lee.

Tras la idea de la creacin del hipertexto surgi tambin la idea de la hipermedia, en la
cual, mediante los enlaces no slo es posible acceder a otros documentos, sino tambin a
imgenes, animaciones, video, sonido, etc.

Para poder navegar por la WWW, se cre el protocolo HTTP.
http (HyperText Trafer Protocol) es un protocolo de nivel de aplicacin utilizado para el
intercambio de informacin hipermedia dentro de la WWW. Su funcionamiento es muy
sencillo:

El cliente se conecta al servidor Web

El cliente enva una peticin

70
El servidor responde a dicha peticin


3.11.1 Conceptos sobre http

http funciona generalmente sobre TCP/IP y las conexiones(por defecto) se realizan al
puerto TCP 80. Sin embargo, muchos servidores colocan el servicio WWW en un puerto
diferente, ya sea por motivos de seguridad o para tener varios servidores, cada uno con su
propio puerto, parecido un mismo servicio. Dado que el nico requisito impuesto por http
es trabajar sobre un protocolo de transporte fiable, perfectamente podra utilizarse sobre
redes diferentes a TCP/IP.

http es un protocolo que se basa en la filosofa cliente/servidor. Un cliente enva un
mensaje, compuesto por un comando, un identificador de recurso y la versin del protocolo,
seguido del cuerpo del mensaje, el cual contiene generalmente informacin sobre el cliente.
La respuesta que enva el servidor est formada por una lnea de estado, que incluye la
versin del protocolo, y un cdigo de respuesta, que determina de qu modo se llev a cabo
la operacin.

La conexin entre el cliente y el servidor debe ser iniciada por el cliente y cerrada por el
servidor tras el envo de la respuesta a la solicitud; sin embargo, tanto los clientes como los
servidores deben tener en cuenta que una conexin puede cerrarse de manera prematura
debido a una accin del usuario, por el vencimiento de los temporizadores o simplemente
debido a un fallo del programa. Dependiendo de la versin del protocolo, la finalizacin de
la solicitud en curso (por cualquiera de las partes) puede o no finalizar la sesin actual.


3.12 POP3 (POST OFFICE PROTOCOL)

El protocolo POP (Post Office Protocol) Versin 3 es utilizado para transferir correo desde
un servidor hasta una estacin de trabajo.

El servicio POP3 se encuentra disponible de forma estndar en el puerto TCP 110 Cuando
un cliente desea utilizar dicho servicio, establecer una conexin TCP con el servidor. Una
vez que la conexin ha sido realizada, tanto servidor como cliente comienzan un dilogo
alternado.

El cliente y el servidor POP3 intercambian una serie de comandos y respuestas hasta que la
conexin finaliza de manera ordenada o bien la conexin es abortada por alguno de ellos.
Los comandos del protocolo POP3 consisten en una palabra reservada seguida de uno o
varios argumentos,





71
3.13 Funcionamiento del protocolo POP3

Se pueden distinguir tres fases o estados:

Cuando un cliente inicia una conexin TCP al puerto 110, el servidor enva un saludo de
bienvenida. En este momento, la sesin entra en un estado denominado
AUTHORIZATION STATE (estado de autorizacin). Dentro de este estado, el cliente debe
identificarse ente el servidor POP3 enviando su nombre de usuario as como la contrasea.
El servidor se encarga de validar dicha informacin y aceptar o rechazar la conexin del
cliente dependiendo de si los datos son correctos o si por el contrario son errneos. Si los
datos han sido validados satisfactoriamente, la sesin entra en un estado denominado
TRANSACTION STATE (estado de transaccin), en el cual el servidor prepara toda la
informacin relativa al cliente, para que ste pueda manipular su buzn de correo mediante
una serie de comandos especficos. Tras la ejecucin de comando QUIT, la sesin entrada
en un estado denominado UPDATE STATE(estado de actualizacin), en el cual se cierra la
sesin de manera ordenada y por lo tanto se cierra tambin la conexin.

Un servidor POP3 puede tener un perodo de inactividad de hasta 10 minutos ,momento en
el cual se cierra la conexin.

3.14 PPP (Point to Point Protocol)

PPP (Point-to-Point Protocol) fue diseado para permitir el intercambio de datagramas
entre dos hosts a travs de un enlace de comunicaciones. Dicho enlace debe ofrecer una
comunicacin full-duplex y un transporte ordenado de loa datagramas.

PPP se ha establecido como el protocolo estndar para acceso a redes TCP/IP a tras de
lneas serie. El antecesor de PPP es el protocolo SLIP (Serial Line IP), algunas de sus
restricciones lo hacen poco verstil para las necesidades actuales, por lo que ha ido
perdiendo puesto frente a PPP.


El protocolo PPP tiene tres componentes ejemplares:

Encapsulacin. Ofreciendo la posibilidad de multiplexar diferentes protocolos de
nivel de red sobre un mismo enlace serie
LCP (Link Control Protocol). El protocolo de control de enlace configurar las
opciones de encapsulacin, el tamao de los paquetes, detectar cualquier error de
configuracin en los hosts, autentificar al otro extremo del enlace, terminar el
enlace, etc.
NCP (Network Control Protocol). Manejarn las particularidades de los diferentes
protocolos a nivel de red con los PPP puede trabajar.




72
3.15 IRC (Internet Relay Chat)

IRC (Internet Relay Chay) es un protocolo que permite la creacin de conversaciones
multiusuario en tiempo real.

Un escenario tpico de IRC comprende varios servidores, que forman la red de IRC, y a los
cuales se conectan los clientes. Los clientes se vern entre s siempre y cuando estn
conectados a la misma red de IRC.

El entorno en el que se desarrollan las conversaciones se organiza en canales. Un canal es
un grupo de clientes, los cuales recibirn nicamente aquellos mensajes dirigidos al canal.
Los canales son compartidos entre todos los servidores de la red Entre los servidores y los
clientes hay un intercambio continuo de mensajes.

Algunas limitaciones que afectan a los elementos vistos son los siguientes:

Los mensajes de IRC deben tener una longitud mxima de 512 caracteres, incluidos
el retorno de carro y el avance de lnea. Que deben ir situando al final de cada
mensaje.

Otras limitaciones viene dadas por el nombre o nick del cliente, que ser el
identificador por el cual se le conozca dentro de la red de IRC. Este nombre no
podr sobrepasar los 9 caracteres.

De igual manera los nombres de los canales no podrn sobrepasar los 200
caracteres, siendo obligatorio que comiencen por # o & y no pueden contener
espacios, comas o el carcter ASCII7.

El nmero de parmetros de un comando no podr ser superior a 15.


3.16 RIP (Routing Information Protocol)

El protocolo RIP (Routing Information Protocol) fue diseado para realizar el intercambio
de informacin de encaminamiento entre los routers y hosts de una red. RIP es un protocolo
IGP basado en vectores de distancia. Esto significa que almacena la distancia que separa
unos nodos de otros. A esta distancia se le denomina mtrica, y en la prctica ser un valor
comprendido entre o y 15. Una mtrica de 16 indica una distancia infinita, es decir, que el
destino no es alcanzable por dicha ruta. Aunque teniendo en cuenta las limitaciones de RIP,
tanto en el valor ms alto que puede tomar la mtrica como en su agilidad para propagar los
cambios de la red, es conveniente conservar la filosofa de mantener la mtrica con el
nmero de saltos entre redes.

Si existiesen varias rutas posibles para alcanzar un destino se usar aquellas con la mtrica
ms pequea. Si se tuviesen varias rutas con la misma mtrica, se tomar cualquiera de
73
ellas aleatoriamente. Para obtener el camino ms ptimo se usa el algoritmo de Bellman-
Ford.

El protocolo Rip ofrece un sencillo mecanismo para obtener la tabla de rutas de una red.
Sin embargo, este protocolo consume cantidades elevadas de ancho de la red debido a la
gran cantidad de paquetes que necesita para llevar a cabo el intercambio de informacin
sobre las rutas.

Se puede decir, por lo tanto, que RIP es un protocolo sencillo de implementar y gestionar,
pero que no es eficaz en redes de amplio tamao. Su utilizacin puede ser muy til, sin
embargo, en redes de rea local


3.17 OSPF (Open Shortest Path First).

OSPF est clasificado como un protocolo de tipo IGP (Interior Gateway Protocol) y fue
diseado para aceptar crecimientos en la red y poder difundir la informacin de
encaminamiento de manera rpida. Entre otras, las caractersticas ms importantes son:

Rpida deteccin de cambios en la topologa de la red.

Carga de la red, debido al envo de informacin correspondiente a los cambios
sufridos en las rutas.

Capacidad de toma de decisiones. En los lugares en los que existen mltiples
caminos, OSPF es capaz de hacer balance de decisiones.

Encaminamiento segn el tipo de servicio.

Decremento del tamao de las tablas de rutas debido a la utilizacin de zonas como
espacio de trabajo.

Utilizacin de multienvo dentro de las reas,

Funcionamiento jerrquico.

Autenticacin del intercambio de tablas de rutas

Pero no todo son ventajas, OSPF tambin tiene algunos inconvenientes:

Requiere una carga de proceso intensiva.
Mantiene copias de la informacin de rutas, por lo que la cantidad de memoria
requerida es amplia.
Es un protocolo ms complejo que RIP.


74

3.18 IRDP (IICMP Router Discovery Protocol)

El IRDP (ICMP Router Discovery Protocol) es un mtodo alternativo a los protocolos de
encaminamiento (RIP, OSPF) para que un host de una red descubra qu routers hay
disponibles dentro de su sured. A diferencia de protocolos como OSPF, IRDP nicamente
informar a un host de los routers disponibles en su subred, pero no dispone de los
mecanismos necesarios para informarle acerca de qu router es el ms adecuado para
alcanzar un destino, dicho router informar al host de la direccin del router ms adecuado
a travs de mensajes ICMP Redirect.

IRDP hace uso de dos tipos de mensajes para llevar a cabo su cometido: Los anuncios y las
solicitudes. Peridicamente, cada router, manda un mensaje (Router Advertisement) a
travs de cada uno de sus interfaces de la red, informando de las direcciones IP asociadas a
dicha interfaz. Los hosts conectados a la red a la cual tambin est conectada la interfaz del
router a travs de la cual se envi el anuncio, recibirn este mensaje, y podrn conocer
gracias a l qu routers hay disponibles en su misma red.

Cuando un host entra en la red, enva un mensaje de solicitud a la red (Router Solicitation)
de forma que cualquier router que reciba dicho mensaje tenga que enviar inmediatamente a
la red un mensaje de anuncio.



3.19 VNC Virtual Network Computing (Computacin en Red Virtual).

VNC es un programa de software libre basado en el protocolo RFB (Remote Framebuffer)
[TRIS 2002], RFB es un protocolo simple de acceso a interfaces grficas de usuario. En
una estructura cliente-servidor el cual nos permite tomar el control de la mquina servidor
remotamente a travs de una mquina cliente. Tambin llamado software de escritorio
remoto. VNC permite que el sistema operativo en cada computadora sea distinto: Es
posible compartir la pantalla de una mquina de "cualquier" sistema operativo conectando
desde cualquier otro ordenador o dispositivo que disponga de un cliente VNC portado.

La versin original del VNC se desarroll en Reino Unido, concretamente en los
laboratorios AT&T, en Cambridge. El programa era de cdigo abierto por lo que cualquiera
poda modificarlo y existen hoy en da varios programas para el mismo uso.

En la enseanza VNC sirve para que el profesor comparta su pantalla con los alumnos, por
ejemplo en un laboratorio. Tambin puede usarse para que un tcnico ayude a un usuario
inexperto, el tcnico ve remotamente el problema que reporta el usuario.

El programa servidor suele tener la opcin de funcionar como servidor HTTP para mostrar
la pantalla compartida en un navegador con soporte de Java. En este caso el usuario remoto
(cliente) no tiene que instalar un programa cliente de VNC, ste es descargado por el
navegador automticamente
75

Para utilizar VNC se requiere:

Sistema operativo: Win95/98/98SE/Me/2000/NT/XP/ Linux/Solaris/


Funcionamiento:

El protocolo VNC transmite desde el cliente al servidor las pulsaciones de teclado y los
movimientos del ratn, y desde el servidor al cliente las actualizaciones de pantalla. Esto
tiene ventajas e inconvenientes. Con VNC el servidor puede ver en todo momento lo que
est haciendo el cliente, porque ambos controlan la misma pantalla, pero no pueden trabajar
los dos a la vez en el mismo ordenador. A cambio, es un sistema altamente portable entre
diferentes sistemas operativos, al no depender de ninguna caracterstica de este.

Las actualizaciones de pantalla se hacen enviando las partes de la pantalla que hayan
cambiado, enviando solo pequeos rectngulos con las variaciones. Esto funciona muy bien
cuando los cambios en pantalla son pocos, pero cuando hay grandes variaciones, por
ejemplo, cuando arrastramos una ventana por la pantalla. Para evitar tener que enviar tantos
datos por la red y acelerar la tasa de refresco, el protocolo VNC puede utilizar diferentes
tipos de compresin en las actualizaciones que se envan.

Ventajas:

-Muy fcil de usar, es gratuito
-Permite arreglar problemas
-Simplemente perfecto
-Administracin remota sin complicaciones

Versiones:

Real VNC , Tight VNC y Ultra VNC


3.20 SSH

SSH, o "Secure Shell" es tanto una aplicacin como un protocolo, que permite conectar dos
ordenadores a travs de una red, ejecutar comandos de manera remota y mover ficheros
entre los mismos. Proporciona autentificacin fuerte y comunicaciones seguras sobre
canales no seguros y pretende ser un reemplazo seguro para aplicaciones tradicionales no
seguras, como telnet, rlogin, rsh y rcp. Su versin 2 (SSH2) proporciona tambin sftp, un
reemplazo seguro para FTP.

Adems de esto, SSH permite establecer conexiones seguras a servidores XWindows,
realizar conexiones TCP seguras y realizar acciones como sincronizacin de sistemas de
ficheros (rsync) y copias de seguridad por red, de manera segura.

76
SSH permite, adems, solventar problemas de seguridad que pueden derivarse del hecho de
que usuarios tengan acceso como root a ordenadores de la red, o acceso al cable de
comunicaciones, de modo que podran interceptar contraseas que se transmiten por la red.
Esto no puede ocurrir con SSH, ya que SSH nunca enva texto plano, sino que la
informacin siempre viaja cifrada.

Existen dos versiones de SSH (SSH1 y SSH2) con diferentes funcionalidades e
incompatibles entre s (SSH2 soluciona problemas de seguridad de SSH1). A pesar de estas
mejoras, existen razones a favor del uso de una y otra versin:

SSH1 tiene fallos estructurales que le hacen vulnerable a ciertos tipos de ataques
SSH1 puede sufrir un ataque del tipo "Man In The Middle" (intercepcin de las claves
pblicas en el intercambio de las mismas)
SSH1 est soportado en ms plataformas que SSH2
SSH1 permite autentificacin de tipo .rhosts (propuesta en SSH2)
SSH1 permite mtodos de autentificacin ms diversos (AFS, Kerberos, etc.)
SSH1 tiene mejor rendimiento que SSH2

El uso de SSH est muy extendido, y cuenta con ms de 2 millones de usuarios en ms de
60 pases.

3.20.1 Caractersticas del protocolo

El software se compone de un programa servidor en una mquina servidora, y un programa
cliente en la mquina cliente (junto con algunos programas auxiliares). Las mquinas se
conectan a travs de una red IP no segura.

La conexin siempre se inicia por parte del cliente. El servidor est escuchando un puerto
determinado, esperando la conexin, y puede atender a varios clientes.
Cuando el cliente se conecta al servidor, el servidor acepta la conexin y responde
enviando su identificacin de versin, a lo que el cliente responde enviando la suya. Esta
informacin valida que la conexin se realiz en el puerto correcto, establece la versin del
protocolo utilizada, y la versin del software utilizada por cada uno de ellos. Esta
informacin no se enva cifrada, y es perfectamente legible. Si cualquier lado de la
conexin no acepta o no entiende esta informacin, se cierra la conexin.

Una vez terminado la fase de identificacin, ambos lados comienzan una transmisin
segn un protocolo binario. El servidor enva su clave de equipo (la clave RSA del propio
equipo), la clave del servidor (una clave RSA generada cada hora), y otras informaciones al
cliente. El cliente genera una clave de sesin de 256 bits, la cifra utilizando ambas claves
RSA y enva la clave cifrada, junto con el tipo de cifrado seleccionado al servidor. Ambos
lados comienzan ahora a enviar datos cifrados mediante la clave generada y el algoritmo
seleccionado. El servidor enva un mensaje de confirmacin cifrado al cliente.

Tras eso, el cliente se autentifica utilizando uno de los mtodos de autentificacin
soportados:

77
basada en los ficheros ".rhosts" o "/etc/hosts.equiv", por defecto no permitida
esta misma junto con autentificacin del ordenador cliente basada en RSA
autentificacin RSA
autentificacin por password Tras una correcta autentificacin, el cliente enva una serie
de peticiones para comenzar la sesin, como establecer una sesin de consola remota,
forwarding de X11 o de un puerto TCP/IP, ejecutar un comando, etc.

Al ejecutar una consola o un comando, la sesin entra en modo interactivo. En este modo,
se envan datos en ambos sentidos, pueden abrirse nuevas conexiones, etc. Esta sesin
generalmente termina cuando el servidor enva en cdigo de terminacin del programa
ejecutado al cliente.

El protocolo reserva cierta informacin para permitir extenderlo en el futuro:

Envo de la versin del protocolo
El primer paquete enviado por ambas partes, contiene una serie de flags, que pueden
utilizarse para acordar el uso de extensiones compatibles

En las fases de autentificacin y preparacin de la sesin, el cliente realiza peticiones al
servidor, de modo que si se enva una peticin no permitida por el servidor, ste
simplemente devuelve que la peticin ha fallado. Esto permite aadir nuevos mtodos de
autentificacin y operaciones de preparacin. En cambio, la sesin interactiva, no permite
la negociacin de extensiones. stas deberan negociarse en las fases anteriores.

3.20.2 Puerto TCP/IP y otras opciones

El puerto por defecto para el servidor es el 22.
El cliente puede conectarse desde cualquier puerto, pero si quiere utilizar autentificacin
mediante ".rhosts" o "/etc/hosts.equiv", debe conectarse a travs de un puerto privilegiado
(menor a 1024).

El campo IP "Tipo de Servicio" debera de ser IPTOS_LOWDELAY para conexiones
interactivas, IPTOS_THROUGHPUT para las no interactivas.

Se recomienda as mismo que se utilicen seales para comunicar que la conexin sigue
activa, para detectar si alguno de los lados ha cortado la conexin de modo inusual.

3.20.3 Identificacin de la versin del protocolo

Una vez que se ha abierto el socket, el servidor enva un string con el formato

"SSH-<num_mayor_del_protocolo>.<num_menor_del_protocolo>- <versin>\n".

Los dos primeros campos identifican la versin del protocolo, y el ltimo campo, la versin
del software del servidor.

78
El cliente enva despus su propia informacin. Si el servidor tiene un protocolo menor que
el cliente, y ste puede emularlo, enva la versin menor.

En caso contrario, enva su propia versin. El servidor compara la versin enviada por el
cliente con la suya, y determina si pueden trabajar o no. El servidor decidir desconectarse,
o enviar el primer paquete binario, y ambas partes utilizarn despus la versin del
protocolo acordada.


3.20.3 Intercambio de claves y autentificacin del equipo servidor

El primer mensaje enviado por el servidor enva la clave del equipo, la clave pblica del
servidor, los algoritmos de cifrado soportados, los mtodos de autentificacin soportados y
las extensiones. Tambin contiene un nmero aleatorio de 64 bits (cookie).

Este paquete se enva sin cifrar.

Ambas partes calculan un identificador de sesin del siguiente modo:
session_id = MD5(hostkey || serverkey || cookie)

El cliente responde con un mensaje que contiene el tipo de cifrado elegido, una copia del
cookie, y la clave de sesin de 256 bits cifrada con ambas claves del servidor. Este mensaje
no se cifra.

Una vez que se ha enviado la clave de sesin, el cliente cifrar todos los paquetes salientes
y descifrar todos los paquetes entrantes.

Una vez que el servidor recibe la clave, y activa el cifrado, enva al cliente un mensaje
indicando el xito de la operacin.

La clave de equipo del servidor se recomienda que tenga 1024 bits, y la clave de servidor,
768 bits. La clave mnima no puede ser menor de 512 bits.

3.20.4 El nombre de usuario

El cliente enva al servidor un mensaje indicando el nombre de usuario con el que se quiere
conectar.

El servidor valida que el usuario existe, si se necesita autentificacin y responde con un
mensaje de xito (no se necesita autentificar el usuario) o fallo (se necesita autentificacin,
o el usuario no existe).

Si el usuario no existe, se devolver fallo a todos los mensajes, excepto al mensaje de
desconexin, al mensaje "ignore" y al mensaje "debug", pero seguir escuchando al cliente,
de modo que este no puede saber si el usuario exista o no.

79
3.20.5 Fase de autentificacin

Si no se acepta el login automticamente, el cliente pide al servidor distintos mtodos de
autentificacin de manera aleatoria tantas veces como desee. Si la autentificacin es
correcta se devolver un mensaje de xito, y si falla, un mensaje de fallo.


Autentificacin por RHOSTS
El cliente enva un mensaje con el nombre del usuario cliente. El servidor verifica este
nombre contra los ficheros "/etc/hosts.equiv" y ".rhosts" (sistemas UNIX). La conexin
debe de venir desde un puerto privilegiado.

Este tipo de verificacin no suele activarse puesto que puede sufrir diversos ataques.

Autentificacin por RHOSTS y RSA
El cliente no slo enva el nombre de usuario, sino tambin su clave pblica RSA. El
servidor autentifica al cliente por el mtodo RHOSTS, y si se verifica, comprueba si conoce
su clave pblica, y si la enviada es la misma almacenada en el servidor.

Si cualquiera de estos pasos no se cumple, se devolver un mensaje de fallo.

En caso contrario, se someter al cliente a un desafo RSA con la clave pblica del cliente.
El cliente deber descifrar un mensaje cifrado con su clave pblica, utilizando su clave
privada, y enviar la respuesta al servidor, que verificar si se ha conseguido pasar el
desafo o no.

Autentificacin por RSA
En este caso, el cliente enva su clave pblica, y si el servidor la admite, enva al cliente un
desafo RSA.

En el caso de que el cliente lo supere, se permitir el acceso del mismo.

Autentificacin por password
El cliente enva al servidor el password del usuario, en texto plano (aunque lo normal ser
que viaje cifrado).

Si el password es correcto, se permitir el acceso.

3.20.6 Operaciones de preparacin

Una vez que el servidor ha admitido la conexin por parte del cliente, se negocian las
opciones que van a utilizarse durante el intercambio de datos.





80
3.20.7 Sesin interactiva e intercambio de datos

Durante una sesin interactiva, los datos de salida el proceso en ejecucin en el servidor se
redireccionan a "stdin" o "stderr" en el cliente, y cualquier entrada disponible en "stdin" en
el cliente se enva al programa en el servidor.

El envo de datos es asncrono, y tanto el cliente como el servidor pueden enviar datos al
mismo tiempo.

Cuando la aplicacin termine de ejecutarse en el servidor, se enviar un mensaje con el
estado de finalizacin del programa, y se cerrar la conexin.

3.21 SSH2

SSH2 es un protocolo que permite servicios de red y conexiones seguras sobre una red
insegura. Consta de tres componentes:

Capa de protocolo de transporte: proporciona autentificacin del servidor,
confidencialidad e integridad y, opcionalmente, compresin. Generalmente se ejecutar
sobre una conexin TCP/IP.
Capa de protocolo de autentificacin: autentifica al cliente contra el servidor. Se ejecuta
sobre la capa del protocolo de transporte.
Capa del protocolo de conexin: multiplexa el canal cifrado en mltiples canales lgicos.
Se ejecuta sobre la capa de autentificacin.

El cliente enva una peticin de servicio una vez que se ha establecido una conexin segura
en la capa de transporte, y una segunda peticin tras la autentificacin del usuario. Esto
permitira definir nuevos protocolos que coexistieran con los anteriormente definidos.

El protocolo de conexin proporciona canales que pueden utilizarse para diferentes
propsitos, como abrir sesiones interactivas, redireccionar puertos TCP/IP (tunneling) y
conexiones X11.

3.21.1 Arquitectura

Claves de equipo
Cada servidor debera de tener una clave de equipo. Es posible tener varias, con distintos
algoritmos, e incluso varios equipos pueden compartir la misma clave. Si un equipo tiene
claves, al menos debe de tener una clave utilizando el algoritmo obligatorio (DSS).

La clave se utiliza para verificar que el cliente est conectado al servidor correcto, para lo
que el cliente debe conocer de antemano la clave pblica del servidor.

Pueden utilizarse dos modelos:

El cliente tiene una base de datos que asocia servidores con sus correspondientes claves
pblicas.
81
Las asociaciones vienen dadas por una autoridad de certificacin.
El protocolo permite que, la primera vez que el cliente se conecte con un servidor, no se
compruebe su clave pblica, con lo que esta primera vez no sera necesaria, pero esto hace
que la conexin sea vulnerable, por lo que no se recomienda, aunque a veces es necesaria
esta opcin.

Todas las implementaciones del protocolo deberan hacer todo lo posible por comprobar
siempre esta clave.



Extensibilidad
El protocolo est diseado de manera que pueda resultar fcilmente extensible, aadiendo
nuevos algoritmos, protocolos, tipos de datos, etc.

Negociacin
El protocolo permite negociar el cifrado, la integridad, el intercambio de claves, la
compresin, y los algoritmos y formatos de las claves pblicas. Los algoritmos de cifrado,
integridad, clave pblica y compresin pueden ser diferentes en cada sentido de la
conexin.

Propiedades de seguridad
Los algoritmos de integridad, cifrado y clave pblica utilizados son conocidos y
ampliamente probados.
Los algoritmos utilizan claves lo suficientemente largas como para resistir durante
dcadas los ms fuertes ataques de criptoanlisis.
Como los algoritmos se negocian, si uno se ve comprometido es posible negociar el
uso de otro sin cambiar el protocolo.

Consideraciones de seguridad
El protocolo de transporte proporciona un canal confidencial sobre una red no segura.

Efecta la autentificacin del servidor, el intercambio de claves, el cifrado y la proteccin
de la integridad. Tambin proporciona un identificador de sesin nico que ser utilizado
por los protocolos superiores.

El protocolo de autentificacin proporciona mecanismos para autentificar al cliente contra
el servidor.

El protocolo de conexin especifica un mecanismo para multiplexar diferentes flujos de
datos (canales) sobre un canal de transporte confidencial y autentificado. Tambin
especifica canales para acceder a consolas interactivas, redireccionar protocolos al canal de
transporte seguro, y acceder a subsistemas seguros en el servidor.

Los protocolos de la familia SSH, y sobre todo la segunda versin del mismo, permiten
grandes posibilidades a la hora de conseguir conexiones seguras con ordenadores remotos,
a travs de redes no seguras.
82

El uso por parte de los usuarios no exige grandes conocimientos, y no dificulta la
utilizacin de recursos remotos, ya que puede realizarse de manera totalmente transparente,
por lo que el uso de los mismos debera extenderse, a nivel tanto de intranets como de
extranets.

3.22 Rdesktop

Rdesktop es un cliente de software libre, creado originalmente por Matthew Chapman,
capaz de utilizar el protocolo RDP (Remote Desktop Protocol) para conectarse de forma
nativa mquinas con Windows NT Terminal Server, Windows 2000 y Windows 2003, y
presentar en la mquina local un escritorio remoto; cuenta adems con la ventaja de no
necesitar software ajeno alguno.

Esta maravilla de programa, funciona en la mayora de sistemas operativos Unix con el
sistema X Window, y por supuesto, lo hace en nuestro GNU/Linux (aunque no sea
oficialmente un Unix) con las XFree86.



3.22 -WINDOW: Interfaces Grficas de Usuario para UNIX

Los ambientes grficos de ventanas o Interfaces Grficas de Usuario (GUI) existentes para
UNIX se basan en el Sistema grfico X (X-WINDOW) desarrollado en el MIT.

El Sistema X bsico contiene una Biblioteca de definiciones de Tipos de Datos, Constantes,
Variables y Funciones (xlib) para presentar en pantalla (display) en forma grfica y un
protocolo de presentacin bajo esquema de funcionamiento en modo Cliente/Servidor. Para
el Sistema X un Cliente es una sesin de trabajo de un usuario registrado en una mquina
donde se ejecuta una aplicacin X -una que utiliza el Sistema X de presentacin- y un
Servidor es una mquina donde est instalado y activo el servicio de presentacin del
Protocolo X. Desde un terminal X -que puede ser: una ventana, un emulador de X en un
equipo sin UNIX o un terminal real tipo X- se ordena la ejecucin de la aplicacin X en el
Cliente pero el despliegue o presentacin grfica se realiza en la pantalla del Servidor local.
La generalidad en el diseo del Sistema X permite el caso particular de que el Cliente y el
Servidor sean una sola mquina -en cuyo caso la aplicacin X se ejecuta en la mquina y la
presentacin se efecta en una pantalla de la misma mquina. Para que el Cliente y el
Servidor puedan ser mquinas diferentes y distantes, es necesario que ambas estn
integradas en Red para que puedan comunicarse: el servidor le enva al Cliente la
codificacin de las acciones del usuario y el Cliente responde enviando la informacin a
desplegar. Por ejemplo, el sistema de aplicaciones estadsticas SAS que est instalado en el
Servidor IBM SP2 en CecalcULA, puede ordenarse que se corra desde uno de los equipos
PC del operando bajo LINUX. El SAS procesa en la SP2 pero muestra sus ventanas en el
equipo PC. Bajo WINDOWS tambin se puede hacer lo mismo si se tiene instalado un
sistema de Emulacin de X como el SolarNET PC-X de Sun Microsystems -la ULA posee
licencia- o el eXceed.

83
Existen diferentes sistemas para programar aplicaciones que respondan a acciones del
usuario desde un terminal -uso de teclado, ratn- basadas en la utilizacin y extensin de
los recursos de X, como son Xview o Motif. Estos sistemas agregan Bibliotecas ms
especializadas al Sistema X y a su vez ellas se usan para desarrollar ambientes GUI para
Servidores de X.

Como en UNIX muchos comandos son en realidad llamadas a programas, el Sistema X
contiene tambin un conjunto de programas utilitarios para realizar tareas necesarias de
configuracin y servicios especiales, los cuales se agregan al repertorio de comandos
disponible en UNIX cuando las Bibliotecas de X estn instaladas.

Ejecucin Remota de Aplicaciones X

El Protocolo X requiere que cada Servidor X sepa en cules mquinas pueden abrirse
sesiones Clientes y a su vez cada Cliente X -sesin de trabajo de un usuario registrado-
requiere saber hacia cual Servidor X enviar sus presentaciones. Esto est predefinido
cuando el Cliente y el Servidor son la misma mquina.

Para que un usuario pueda ordenar la ejecucin de una aplicacin X desde un Servidor X
tiene que primero informarle en cual mquina remota se va abrir la sesin Cliente, que ser
la mquina Cliente. Esto se hace con el comando:

xhost <nombre Internet o direccin IP de la mquina Cliente>

Despus debe abrir una sesin de trabajo en la mquina Cliente. Esto se hace con el
comando:

telnet <nombre Internet o direccin IP de la mquina Cliente>

o con el comando:

rlogin -l <nombre cuenta en mquina Cliente> <nombre Internet o direccin IP de la
mquina Cliente>

Mejor usar rlogin en las mquinas con LINUX y ambiente Fvwm95.

Una vez completado el Proceso de Login en la mquina a la que se ha conectado,
informarle a la sesin abierta cual va a ser su Servidor X. Esto se hace con el comando de
configuracin de ambiente de UNIX:

setenv DISPLAY <nombre Internet o direccin IP de la mquina Servidor>:0.0

Desde el terminal abierto con la sesin en la mquina Cliente se pueden mandar a ejecutar
aplicaciones X cuyas ventanas aparecern en la mquina en la que se trabaja, o sea, el
Servidor de X.

84
Por supuesto, si el Cliente y el Servidor son la misma mquina no hay que hace nada de
esto, slo escribir el comando con el nombre de la aplicacin X local. Conviene si no se
quiere que la ventana se quede inactiva hasta que termine la aplicacin X, colocar despus
del comando el smbolo &, A MENOS, que la aplicacin reciba algn tipo de dato por
teclado en modo carcter.

85
Captulo 4
Construccin de un prototipo de Cliente Ligero.

4.1 Qu es un cliente Ligero.

Popularmente conocidas como terminales tontas, terminales sin disco, clientes
ligeros, clientes delgados, etc. Se trata, en su mayora, de equipos obsoletos que pueden o
no tener un sistema operativo instalado, pero que son utilizados para conectarse a un
servidor de terminales mediante los recursos del servidor ejecutar aplicaciones localmente.
El sistema operativo es exclusivamente GNU/Linux, y puede conectarse a un servidor de
terminales GNU/Linux o Microsoft.

Actualmente se puede definir un cliente ligero como una computadora con baja
capacidad de proceso, generalmente sin unidad de almacenamiento, de reducido tamao, y
con un costo reducido, siendo la evolucin de las terminales en modo texto, que se
utilizaban en instalaciones centralizadas.


4.1.1 Propiedades de un Cliente Ligero.

Los Clientes Ligeros son claramente diferentes a las computadoras de escritorio
comunes no solo por su forma peso y tamao. Un cliente Ligero es una pequea
computadora de escritorio que posee las siguientes propiedades:

Usualmente los clientes ligeros no poseen dispositivos de almacenamiento.
Puede contar con un BOOT de red, USB, disco duro y CD-ROM.
El poder de procesamiento es mnimo.
Ausencia de ruido, son totalmente silencioso.
Su procesador y sus componentes son de bajo consumo energtico.
No requiere ventiladores, la disipacin de calor es mnima.
Son de tamao reducido.
Son ligeras, su peso es reducido.

Adicionalmente la eliminacin de componentes mecnicos y mviles como el disco duro,
unidad de disco flexible, CD-ROM y ventiladores apunta al mejoramiento del ambiente de
trabajo no generando ruido, consumiendo menor energa elctrica y disipando menor calor.


4.1.2 Historia de los clientes Ligeros.

En la dcada de 1980, la computadora personal (PC) lleg. Y con ella una nueva forma de
manejar la informacin. El rgido control de informacin fue rpidamente sustituido por el
procesamiento distribuido. En el mundo de las computadoras de escritorio, los programas y
86
los datos residan en las computadoras locales, que adems de ser ms rpido, ms
pequeos y ms baratos y ofrecen una esperanza para la flexibilidad.
Los usuarios de computadoras de escritorio podran instalar sus propias aplicaciones, y los
departamentos son libres de desarrollar sus propios programas, segn sea necesario.



Nuevos retos para los administradores. El control de la prdida de informacin, ya sea
debido a error de hardware o robo, fue ms difcil y los usuarios agregar o quitar programas
a voluntad, el mantenimiento de estas configuraciones de escritorio nico se convirti en
una tarea gigantesca, se requera una solucin mejor.

Una alternativa tan pregonada durante finales del decenio de 1980 fue cliente-servidor. Con
cliente-servidor. Las computadoras se les asigna las tarea que estn mejor equipados para
manejar. Por lo general, se trata de un potente servidor de servicios y computadoras
clientes.

Citrix 1999.

Citrix en cooperacin con Microsoft lanzo en ese ao Winframe que luego evoluciona hasta
el actual Metaframe/XP.
Esta fue una solucin verdaderamente basada en servidores y donde el trfico de red es
compuesto por el protocolo ICA
4
que transfera solamente pantalla y eventos de teclado y
ratn.


Wyse y el Winterm a finales 1995.

Wyse
5
era un lder en la fabricacin de terminales de caracteres. Pronosticando un cambio
en el mercado, tienen la iniciativa de adoptar el concepto de cliente ligero tempranamente,
quizs aun antes de que la gente comprendiera el concepto debidamente. Su principal idea
era soportar la iniciativa de Citrix y esta manera recuperar parte del mercado que haba
estado perdiendo desde la aparicin de la PC, desde 1985.


Larry Ellison y Oracle Corporation en 1996.

Larry Ellison, mejor conocido por Oracle Corporation, prometi un cambio en el escritorio
corporativo y hogareo, remplazando la PC con la Network Computer
6
, que una
computadora con mnima memoria, sin disco duro y con un procesador de gama baja
diseado para conectarse a una red, sus creadores se apoyan en la idea de que muchos

4
El Protocolo ICA se ha diseado especialmente para transmitir datos de pantalla grfica de Windows y
entradas de teclado y ratn a travs de una conexin de red
5
Wyse actualmente vende sus modelos Wyse S10 y Wyse V10L de cliente ligero.
6
Los datos con los que se trabaja se almacenan en el servidor central, ya que estos terminales no tienen disco
duro, en ese servidor se encuentra tambin las aplicaciones con las que opera.
87
usuarios no necesitan una mquina especialmente potente y pueden tomar los recursos de
un servidor. Esto reduce costos y facilita la administracin de las terminales desde un
servidor central, sobre todo en el caso de las empresas.

El cliente ligero valuada bajo la lnea de USD $ 500 y usando la Internet como un vasto
repositorio de aplicaciones y datos. Para imponer el concepto, sin embargo, Larry Ellison
prometi ms de lo que la Network Computer era capaz de lograr, dejando un conjunto
bastante grande de gente desilusionada atrs. A pesar de que el producto no fue un xito
como se esperaba, la NC tuvo un gran impacto y cambio para siempre la industria y la
forma en la que compramos PC. Temerosos de la amenaza que representaba la Network
Computer, los vendedores de PC por primera vez bajaron la barrera de los USD $1000 en el
precio de las computadoras de escritorio.
La Network Computer no tuvo ningn xito. En gran parte porque el uso de Internet no
estaba tan extendido como ahora, y en su defecto era necesario contar con un buen servidor
con aplicaciones algo nada barato.
Luego la compaa tras la Network Computer trato de reinventarse a si misma como la
New Internet Computer (NIC) pero fracaso nuevamente.


Microsoft e Intel 1996.

Tras Oracle fueron Microsoft e Intel los que anunciaron a bombo y platillo los Net PC a
finales de 1996. El Net PC era una nueva plataforma de hardware ms barata que un PC
(1.000 dlares) pero menos potente y con menos capacidades de ampliacin. Este tipo de
Network Computer pensado especialmente para Internet era en realidad un PC venido a
menos capaz de ejecutar aplicaciones Windows localmente y tambin de ser administrado
remotamente. El Net PC no tena unidad de disco flexible, lector de CD-ROM, disco duro y
tampoco tuvieron xito.

Sun Javastation entre 1997 y 2000.

Sun Microsystems lanz una Terminal cliente llamado Java Station que slo comparta en
parte los fundamentos de Network Computer porque, aunque tambin era una terminal
cliente era dependiente de un servidor, era ms caro y se supona que era una solucin de
calidad para las empresas. Por supuesto tampoco prosper, no compensaba desembolsar
tanto dinero por terminales clientes y el servidor.

Durante su vida, la Sun Javastation, fue desde una terminal a un dispositivo de una sola
aplicacin, pasando por un escritorio basado en browser hasta extinguirse finalmente. Esta
evolucin claramente prueba que Sun estaba mucho mas interesado en Java que en
conquistar el escritorio con clientes Ligeros.
Actualmente Sun esta vendiendo su SunRay con sus modelos 2, 2FS.





88
La PC TV.

Otro experimento fallido que tampoco es exactamente un Network PC, fue el PC TV, unas
cajas (Set Top Boxes) que conectadas al televisor permitan navegar por Internet, jugar, e
incluso ver la televisin. No fructificaron porque costaban entre 3.000 y 5.000 dlares sin
contar el televisor. El PC TV ha resucitado de la mano de las casas fabricantes de consolas;
la Playstation de Sony, Nientendo y Xbox de Microsoft incluye todo esto y adems lector
de DVD por unos 200 dlares.


4.2 Progresos tecnolgicos en computadoras.

Los fabricantes de computadora se empean en innovar, algo va ser completamente
diferente en trminos del diseo de los componentes, la distribucin del calor, los chips
principales, las funciones del BIOS, los requisitos de energa, la compatibilidad de
memoria, la velocidad y tecnologa del procesador, las funciones perifricas, el montaje
mecnico, y los requisitos de los conectores y del cableado. La industria del PC evoluciona
rpidamente.
Los fabricantes tienen que iniciar un rediseo completo para poder ahorrar slo algunos
cntimos por equipo, Las computadoras estarn sometidas a un cambio y a una evolucin
constante, completamente ajenos al control del usuario.


4.3 Depreciacin de Computadoras en Mxico.

Una de las caractersticas del sistema impositivo mexicano es que se modifica con mucha
frecuencia. Estas modificaciones afectan tambin al clculo de la depreciacin de los
activos fijos. Por ejemplo en un periodo de diez aos comprendido entre 1996 a 2006, la
forma en la que se calcula la depreciacin ha cambiado por lo menos en cuatro ocasiones y
la tasa de impuestos sobre ingresos conocida como Impuesto Sobre la Renta (ISR) ha
cambiado tambin en cinco ocasiones en ese mismo periodo.
Por estas razones en solo se permite el clculo de la depreciacin en lnea recta. Un mtodo
de lnea recta es aquel en el que activos se deprecia en una misma cantidad a lo largo de su
vida fiscal.

VR = Valor Residual
C = Costo
VU = Vida til
DA = Depreciacin Anual

DA= (C-VR)/VU


Calculo de la depreciacin de una computadora:

Si el precio de una computadora es de 16000 pesos y la vida til es de 4 aos,

89
C = 16000

VU = 4

Si consideramos que el valor de la computadora despus de su vida til es del 0% de su
costo

VR = (16000 0)/4
VR= 4000

Una computadora que se compra en 16000 pesos, cada ao pierde 4000 pesos de su valor
inicial de compra.
Figura. 4.1. Calculo de la depreciacin sobre algunos activos personales.


4.4 Construccin de un cliente ligero.

Como un primer elemento a considerar es la seleccin del procesador, es el elemento
principal del cliente ligero, determinar la capacidad de la fuente de voltaje por el consumo
de energa y el tipo disipador de calor como los ventiladores a utilizar.

Seleccionamos el procesador Atom Intel de 1.6 GHz por lo siguiente:



Activo
Valor del
bien nuevo
Vida til
estimada
Valor de
rescate
estimado
Depreciacin
anual
Depreciacin
mensual
Composicin
de la
depreciacin
Automvil 1 200,000 5 68,000 26,400 2.200 31.5%
Automvil 2 2000,000 5 68,000 26,400 2,200 31.5%
Lavadora de
ropa
6,000 10 0 600 50 0.7%
Secadora de
ropa
6,000 10 0 600 50 0.7%
Refrigerador 12,000 15 0 800 67 1.0%
Sala 40,000 10 0 4,000 333 4.8%
Comedor 40,000 20 0 2,000 167 2.4%
Televisin 4,000 10 0 400 33 0.5%
Video 3,000 5 0 600 50 0.7%
Computadora 16,000 4 0 4,000 333 4.8%
Muebles
Recmara 1
40,000 10 0 4,000 333 4.8%
Muebles
recmara 2
30,000 10 0 3,000 250 3.6%
Muebles
recmara 3
30,000 10 0 3,000 250 3.6%
Otros muebles 40,000 10 0 4,000 333 4.8%
Vajilla y
utensilio de
cocina
20,000 5 0 4,000 333 4.8%
90
Es el procesador ms pequeo de Intel, mide 25mm
2
, diseado con los transistores
ms pequeos del mundo y fabricado con la tecnologa de compuerta de metal Hi-k
de 45 nm. El procesador Intel Atom se ha diseado especficamente para equipos
netbook y nettop
7
sencillos y econmicos
No genera calor, ocupando un disipador muy pequeo sin ventilador.
El procesador Intel Atom est basado en micro arquitectura completamente nueva
que fue diseada especficamente para dispositivos pequeos y para ofrecer un bajo
consumo de energa.
Es el procesador ms pequeo y de ms bajo consumo de energa que Intel fabrica.
Tienen un consumo de energa promedio de 0.6 2.5 Watts cuando el promedio del
procesador Core 2 Duo es de 35 Watts.
Es un procesador de bajo costo.
Es ideal para la fabricacin de clientes Ligeros.
La tarjeta madre (desktop Boards) es pequea (18 x 18) cm.


4.4.1 Construccin del gabinete del cliente Ligero.

Para la construccin del gabinete del cliente ligero se puede utilizar material de desecho
como lmina, plstico y antiguos gabinete de aparatos electrnicos.


Figura.4.2. Lamina metlica y aparatos electrnicos descompuestos


Seleccin de la carcasa de una antigua lectora de video VHS y una tira de lamina, para
fabricar el gabinete que contendr el cliente ligero que esta compuesto por tarjeta
madre(Desktop Boards), procesador, disco duro, lector de CD-ROM y fuente de voltaje.



7
Computadoras de escritorio, de bajo costo, est pensado para tareas sencillas y que no requieren de espacio
en disco ni grandes dotes de proceso de datos.
91



Figura 4.3. Construccin del gabinete utilizando material de desecho.




Figura 4.4. Montaje de la fuente de voltaje y tarjeta madre (desktop Boards).




Figura 4.5. Montaje de CD-ROM, disco duro y conexiones en general.

Una vez armado el prototipo de cliente ligero se realizan las pruebas necesarias para
comprobar que esta funcionando correctamente entre las pruebas realizadas son las
siguientes:

92
Comprobar que tienen tierra comn, la fuente de voltaje, tarjeta madre, CD-
ROM y disco duro.
Entrar al SETUP del cliente ligero para comprobar que reconoce el disco duro,
CDROM y memoria Flash y que puede realizar un BOOT en cualquiera de
ellos.
Comprobar si hay calentamiento en la fuente e voltaje despus de un tiempo de
trabajo mayor a dos horas, debido al poco consumo elctrico de la tarjeta madre
y del procesador Atom. El ventilador de la fuente de voltaje se quita para que la
operacin del cliente ligero sea ms silenciosa y adems se considera un
elemento innecesario.
Verificamos que la tarjeta madre (desktop Boards), se encuentra libre de
contacto de los otros elementos como son: Fuente de voltaje, CD-ROM, disco
duro, y la cubierta metlica del gabinete.

Nuestro prototipo esta listo para utilizarse como cliente ligero.


4.5 Diseo de un sistema para clientes ligeros en GNU/LINUX.


4.5.1 Porque programar en Linux.

Por qu programa la gente en y para Linux? El nmero de respuestas a esta pregunta es
probablemente tan alto como el nmero de personas que programan en y para Linux. Sin
embargo, creemos que la mayora de ellas son variaciones de alguna respuesta ms general.
Primero, es divertido, por eso lo hago yo. Segundo, es gratuito. Tercero, es abierto. No hay
interfaces escondidas ni funciones o aplicaciones sin documentar interfaces de
programacin (API)-ninguna persona u organizacin tiene ventaja en lo que respecta al
conocimiento de lo que puede hacer el sistema operativo.

Cuarto, si no nos gusta la forma de funcionar de algo, tenemos acceso al cdigo fuente para
arreglarlo, lo que significa que nuestro negocio o trabajo no son cautivos del plan de
negocio de otros. Las aplicaciones populares, como el servidor WEB Apache, se
desarrollan y mantienen de forma activa, de forma que es posible que el equipo de
desarrollo central de un producto proporcione actualizaciones y mejoras necesarias cuando
sean solicitadas. El tema es sencillamente que con software gratuito tenemos acceso al
cdigo fuente si lo queremos.
Para terminar, y consideramos sta como la razn ms importante, los programadores de
Linux son parte de una comunidad especial.


4.5.2 Kernel.

Al igual que los humanos necesitamos un corazn y un cerebro para gobernar nuestro
cuerpo, los sistemas operativos necesitan un kernel (ncleo) que facilite las operaciones
bsicas necesarias para el correcto funcionamiento del sistema. Entre estas funciones se
93
encuentran la gestin de la memoria y la ejecucin de procesos, proporciona un interfaz de
comunicacin entre los programas y los dispositivos, y toda una serie de operaciones
imprescindibles para conseguir hacer funcionar todos los mecanismos propios de un
sistema operativo como plataforma bsica para la ejecucin de programas.

Cuando se instala una distribucin de Linux automticamente se copia un kernel en el
directorio/BOOT. Este kernel ser el utilizado en el arranque del sistema por defecto.
Inicialmente se puede usar el kernel copiado automticamente por la instalacin. Sin
embargo, puede ser necesaria una recopilacin del ncleo por diversas razones:


Aadir al ncleo soporte para cierto hardware instalado en nuestra mquina y para
el cual no hay soporte por defecto en el ncleo instalado.

Eliminar las partes redundantes del ncleo. Es decir, eliminar el cdigo para todas
las funcionalidades que son soportadas por el ncleo y que, sin embargo, en nuestra
mquina no ser utilizadas. Por ejemplo, eliminar el soporte para las diferentes
tarjetas de modem en caso de que nuestra mquina no la utilice.

Actualizar el ncleo del sistema a una nueva versin. Esto permitir que el kernel
sea capaz de entenderse con un mayor nmero de dispositivos o que pueda ejecutarse
ms rpidamente que versiones anteriores. Pero normalmente se actualiza el kernel para
obtener soporte para un nuevo hardware y corregir pequeos fallos.






Figura 4.6. Estructura de Linux.



Hardware
Kernel (Ncleo)
Programas y comandos
Shell
94


4.5.3 Los mdulos cargables del kernel

Significa que todas las funcionalidades del ncleo son enlazadas en un solo archivo
ejecutable al ser copilado el kernel. Esto daba lugar a tener cargado el soporte para
dispositivos que slo se usaban de muy tarde en tarde, pero que sin embargo ocupaban
memoria. Adems, e incluso ms grave, eran la necesidad de recopilar y reiniciar el sistema
para aadir el controlador para un nuevo dispositivo.

Esto fue remediado en versiones posteriores, y actualmente existen muchos controladores y
funcionalidades que pueden ser enlazadas con el archivo principal del ncleo o cargadas en
tiempo de ejecucin. En la creacin puede seleccionarse el modo que se prefiera, como
parte del kernel o como mdulo.

Los mdulos son guardados en el directorio /lib/modules/<version>, donde versin
corresponde a la versin actual del kernel.


4.5.4 Distribuciones Live - CD.

Las distribuciones Live-CD no necesitan instalacin en el disco y pueden funcionar
directamente desde un lector de CD, un lector de DVD, una memoria USB flash drive etc.
Para poder funcionar sin necesidad de tocar el disco duro, utilizan una porcin de la
memoria RAM como si fuera un disco virtual, en donde copia los archivos necesarios para
correr. La mayora de las distribuciones del tipo Live utiliza un sistema de
descompresin que es transparente al usuario y que permite cargar en memoria slo los
archivos necesarios que sean requeridos por el sistema.

Con este mtodo se logra un mejor rendimiento y permite colocar ms aplicaciones en el
CD. Hay distribuciones Live-CD de menor tamao que incluso se cargan completamente en
la memoria RAM logrando un mejor rendimiento.

El primer Live.CD fue Demolinux 1.0, que se dio a conocer en febrero de 2000 en la
Linux Expo que se celebr en Pars. Estaba basada en Mandrake 5.3 pero no as la
versin Demolinux 2.0, que fue la Pre-release de la distribucin Debian Potato

Demolinux fue desarrollada por tres estudiantes de la Universidad de Paris en Francia,
Roberto Di Cosmo, Vicent Blat y Jean Vicent Loddo. Al darse a conocer se apuntaron al
proyecto varios desarrolladores americanos y Demolinux consigui un auge importante,
publicando versiones en ingls, francs y espaol. Actualmente se encuentra descontinuada
y la ltima versin que se conoce data del 28 de enero del 2002.

El Live-CD que ms auge ha tenido aprovechando el xito de Demolinux fue Knoppix all
por el ao 2003, desarrollado por Klaus Knopper Live-CD de origen alemn y basado en
Debian.
95
Tiene un excelente nivel de deteccin de hardware y un buen surtido de aplicaciones. Es
preferido por muchos.
Knoppix pas a ser el referente de los Live- CD y de hecho actualmente se hacen Live-CD
de todo tipo y gusto basados en Knoppix.


Al utilizar este tipo de sistemas se debe tener presente dos cosas:

La velocidad de ejecucin es menor debido a que corren desde un lector de CD, y la
velocidad de este dispositivo es considerablemente menor a la de un disco duro un
lector de CD su velocidad es 400 1000 RPM, y un disco duro es de 5400 7200
RPM.

Los archivos se deben guardar en disco, una memoria flash, una unidad de red, o un
CD-R, de lo contrario se perder todo el trabajo.

Tiene un conjunto de aplicaciones limitadas.


Para que crear nuestra propia distribucin de Linux para clientes ligeros.

Se crea con el propsito de que se ajuste a nuestras preferencias y que tenga todas las
caractersticas que se necesitan y quitar las que no se requieren.
Otro factor importante, una distribucin de GNU/Linux pequea de 400 a 600 MB las
computadoras obsoletas, pueden ejecutar este sistema operativo GNU/Linux desde un CD-
ROM.




La organizacin de archivos en un cd de Knoppix es de la siguiente forma.

/boot
Isolinux/
Boot.cat
Boot.msg (mensaje de arranque de la distro)
f2
f3 (ambos mensajes que aparecen al mostrar la tecla correspondiente)
german.kbd (configuracin del teclado para el boot)
isolinux.bin (Programa que se encarga del arranque del CD)
isolinux.cfg (configuracin del mismo)
linux24 (kernel)
logo.16 (splash de arranque)
minirt24.gz (mini sistema de arranque)
/KNOPPIX
KNOPPIX (imagen comprimida del sistema de archivos)
96

En todos estos archivos se hallan en un archivo llamado boot.img el cual se encuentra
dentro de la carpeta/KNOPPIX. Tambin todas las Knoppix el archivo linux24 se llama
vmlinuz y el archivo minirt24.gz se llama minirt.gz.



4.5.5 Qu es Syslinux.

Syslinux es un cargador de arranque para el sistema operativo Linux que opera fuera de un
sistema de archivo FAT MS-DOS/Windows. Est propuesto para simplificar la instalacin
por primera vez de Linux, y para la creacin de disco de arranque de rescate y con fines
especiales.

Syslinux se puede utilizar, apropiadamente configurando, para eliminar por completo la
necesidad de distribucin de imgenes raw de disco para arranque. Un disco Syslinux se
puede manipular utilizando herramientas MS-DOS estndar (o de cualquier otro sistema
operativo que pueda acceder a un sistema de archivos MS-DOS) una ves que se haya
creado.


4.5.6 Que no es Syslinux

Syslinux probablemente no sea apropiado como un cargador de arranque de propsito
general. Slo puede arrancar Linux desde un sistema de archivos FAT y no, por ejemplo
ext2. Ya que una implementacin Linux nativa utilizar normalmente ext2, probablemente
ser ms conveniente otro cargador de arranque (por ejemplo LILO
8
). En un sistema que
contenga actualmente Dos o Windows, LOADLIN puede ser lo ms sencillo de utilizar. Sin
embargo, Syslinux ha demostrado por s mismo ser bastante til en distintas aplicaciones de
propsito especial.


4.5.7 Arranque desde Kanoppix live - CD.

El arranque se produce de la siguiente forma., primero se monta el archivo boot.img y
ejecuta el programa isolinux, bin el cual muestra el splash de inicio y queda el tpico
BOOT, ah se introducen los comandos de arranque en caso que fuese necesario y si no
arranca con las opciones por defecto, carga el kernel y minirt.gz que se encarga de revisar
la RAM disponible y de buscar el archivo KNOPPIK. Si lo encuentra, lo monta y arranca
desde ah; sino, deja una shell muy limitada como busybox.
Posteriormente cuando se monta el archivo Knoppix se produce el verdadero arranque de la
distribucin ya que detecta el hardware y arranca los programas necesarios adems de crear
un RAM disk para guardar los datos del usuario que se encuentra en /etc/skel. Por eso es

8
LILO es el sistema de arranque de Linux que, adems, permite seleccionar en el arranque de la computadora
el sistema de operativo que se desea arrancar. Es imprescindible en Linux pues es el encargado de cargar el
kernel en memoria y arrancar as el sistema.
97
necesario crear el RAM disk para poder mover los archivos de usuario de /etc/skel a
/home/<nombre_usuario> y as poder escribir en ellos.


4.6 Creacin de nuestra distribucin para Clientes ligeros

1. Intalamos cloop-utils que sirve para generar imagen comprimidas.

# apt get install cloop utils

Esto genera un archivo en el directorio /usr/src/lamado cloop-tar.gz


2. Creamos un archivo llamado ND (Nueva Distribucin).

Con la instruccin mkdir que es un comando para la creacin de directorios

mkdir[opciones] directorio

$ mkdir ND.


3. Copiamos el contenido del CD-ROM donde esta la distribucin LiveCD en un
directorio que llamaremos RF (Recreacin Final).

Con la instruccin cp a que realiza la copia de un archivo a otro archivo
cambiando el nombre.

$ cp a /cdrom/ ND/RF


4. Una ves que tenemos instalado cloop-utils y copiado el CD de Kanoppix RF
procedemos a descomprimirlo.

Con la instruccin extract_compresed_fs que es un comando para descomprimir
archivos.

$ extract_compresed_fs ND/RF/KNOPPIX/KNOPPIX>Knoppix.iso


5. Creamos un Nuevo archive DMK (Directorio de montaje de Kanoppix) con la
instruccin mkdir.

mkdir[opciones] directorio

$ mkdir /tmp/DMK

98

6. Montamos la ISO 09600 con la introduccin mount t que especifica donde
esta el dispositivo y en donde montarlo.

# mount t iso9660 /home/cidetec/knoppix.iso /tmp/DMK -o loop


7. Cambiamos la raz del sistema con la instruccin chroot que cambia la raz del
archivo.

Chroot <nombre-directorio>

El nombre del directorio que va a ser en raz para el nuevo proceso lanzado.

Chroot/home/cidetec/ND/SA


8. Se va a necesitar Internet hay que montar el sistema de archivos proa en el nuevo
entorno de raz.

Mount t proa /proa proa

El directorio /proc/- tambin llamado el sistema de archivos proc contiene una
jerarqua especiales que representan el estado actual del kernel, permitiendo a las
aplicaciones y usuarios mirar detenidamente en la vista del kernel del sistema.


9. Es necesario configurar correctamente el archivo /etc/resolv.conf para resolver los
nombres de los servidores en Internet.

Vim /etc/resol.conf

10. hacer una prueba de conexin por ejemplo:

ping google.com


11. realizamos una actualizacin de la base de datos de los paquetes. Esta base de datos
suele no estar completa en la versin del disco de Knoppix con el objeto de ahorrar
espacio en el CD.

$ apt-get update


12. Podemos ver la lista de paquetes Instalados.

Dpkg-query l
99


13. Desinstalamos los paquetes que no sean necesarios.

Apt-get remove -nombre_del_paquete


14. Para borrar la cach despus de apt-get install.

Apt-get clean


15. Creacin del archivo Knoppix que ser la imagen ISO con sistema se archivo ISO
9660 comprimido.

Mkisofs -input charset ISO-8859-15 -no-split-symlink-componentes -no-
Split-symlink-fields -R l _U -V KNOPPIX.net filessystem -P KNOPPIX
www.knoppix.net -hide-rr-moved cache-inodes pad
/mnt/hda10/knx/sourse/KNOPPIX | create_compressed_fs - 65536 >
/mnt/hda10/knx/master/KNOPPIX/KNOPPIX

Puede aparece un error indicando que no cumple los estndares ISO, pero se puede
ignorar).

16. Creacin de la ISO.

Mkisofs -pad -l -r -J -v -V kNOPPIX -no-emul-boot boot-load-size 4
-boot-info-table -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat
-hide-rr-moved -o /mnt/hda10/knx/knoppix.iso /home/ND/RF/master.

17. Se prurba la funcionalidad de la ISO sin tener que grabarlo en un CD con el
comando qumu que es utilizado para emular otros sistemas.

gemu full-screen -cdrom knoppix.iso

18. Para comprobar la imagen generada sin necesidad de quemar un CD.

qemu fuul-screen -cdrom knoppix.iso


19. Para cambiar la imagen de fondo.

La imagen de fondo de KDE se encuentra en dos directorios

/home/ND/SA/KNOPPIX/usr/local/lib/knoppix.jpg

/home/ND/RF/KNOPPIX/background.jpg
100


20. La pantalla informativa del arranque de KDE se encuentra en:

/home/SA/ KNOPPIX/ usr/share/apps/ksplash/themes/Default/


21. Se modifica el siguiente archivo con la imagen de nuestra preferencia.

/home/SA/KNOPPIXX/etc/skel/.Kde/share/config/Ksplshrc



Si Llegamos al paso 21 la distribucin para clientes ligeros esta hecha, es conveniente
empezar todo de nuevo en caso de que se reciban mensajes de error.


4.7 Protocolos de conexin en la interfaz de Gambas

4.7.1 SSH (Secure Shell)

SSH, abreviatura de Secure Shell, surgi con la intencin de aadir seguridad a las
comunicaciones entre mquinas remotas a travs de los comandos rcp, rsh, rlogin y telnet.
Sin embargo, ha llegado a ser un programa de uso ms que recomendable para
administradores de sistemas y personas que utilizan sus computadoras de forma remota, en
un entorno de red inseguro, como puede ser Internet. Esto llevo al equipo de SSH a aadir
funcionalidades a la aplicacin, como la posibilidad de usar sesiones de X (X Windows
permite el uso de clientes grficos remotos) y en su ltima versin, incluye tambin un
servicio FTP seguro.

Antes de introducirnos en la explicacin de su funcionamiento e instalacin, les he de
avisar que SSH cuenta con un historial, que aunque no es grande debe tenerse en cuenta, de
errores de seguridad, debido a la difusin que ha tenido esta aplicacin. Por ello, pensamos
que es muy recomendable intentar utilizar siempre la ltima versin. Existen dos versiones
de SSH, la primera SSH1, y numerada ssh 1.x.x y la segunda SSH2 y numerada ssh 2.x.x.
La ltima que se encuentra disponible ahora mismo es ssh 2.2.0.

Las diferencias entre SSH1 y SSH2 son grandes, tanto que se rescribieron los protocolos,
por lo que no son compatibles entre s. Con el nuevo protocolo de gan en velocidad y
fiabilidad. Nosotros explicaremos principalmente SSH2, sin embargo, cuando veamos
informacin que sea relevante referente a la primera versin, se har hincapi en ella.

Debido a la incompatibilidad existe entre ambas es incluso recomendable obtener e instalar
las dos versiones sobre todo si tiene intencin de acceder a computadoras mediante el
cliente de SSH2. Un poco ms avanzado el captulo veremos una configuracin mixta para
el uso de ambos servidores y clientes sin preocuparnos del tipo de servidor del destino
(SSH1 o SSH2)
101


Introduccin a SSH

Muy a tener en cuenta, son las posibilidades de encriptacin y autentificacin que nos
brinda SSH. Por ello, explico cada una de ellas, as en el apartado de configuracin usted
podr elegir la que mejor se adapte a sus necesidades. Antes todo ha de comprenderse que
SSH no es slo un servidor, sino que posee sus propios clientes, lo que significa que no
encripta todo lo que pasa por nuestro computadora, sino lo que utilizamos desde sus
clientes hacia el servidores.

SSH utiliza distintos algoritmos de encriptacin para ofrecer una mxima seguridad en las
trasmisiones, para la encriptacin de los datos transmitidos.

Cifrado SSH1 SSH2
DES

3DES

IDEA

BlowFish

TwoFish

ArcFour

Cast128-cbc
S

S

S

S

S

S

S
No

S

No

S

S

S

S

Figura 4.7. Protocolos de Cifrado en SSH.

Como se puede observar, algunos de los algoritmos son muy genricos, como el DES,
utilizado para cifrar la claves en la mayora de sistemas Unix, o como el IDEA.
Para autentificarnos, nos fijamos en la tabla de protocolos de de Autentificacin, y
observamos que los protocolos utilizados han cambiado. Esto es debido a que en la
implementacin de SSH1 se utilizaba un algoritmo, el RSA, que posee una patente de la
empresa del mismo nombre, por lo que su uso, hay que pagarlo Sin embargo, en la segunda
versin han optado por otro algoritmo de llave pblica, el DSA.


Cifrado SSH1 SSH2
RSA

DSA
S

No
No

S

Figura 4.8. Protocolos de Autentificacin.
102


Instalacin de SSH

SSH en la actualidad se ha convertido en una aplicacin muy utilizada y portada a varios
sistemas operativos, por lo que su instalacin se ha mejorado bastante, que actualmente se
lleva a cabo en cuatro pasos, que son:

1. Conseguido el paquete de distribucin en ftp.ssh.com/pub/ssh procedemos a la
descompresin y desempaquetacin.

Bash gzig dc ssh-2.2.0.tar.gz | tar - xvf -

2. Ahora ejecutamos el programa Configure que detectara si tenemos los componentes
necesarios en la mquina para la compilacin del programa.
Bash# cd ssh -2.2.0
Bash# ./configure
3. Si no hemos obtenido ningn error procedemos al compilado.

Bash# make

4. Finalmente ejecutamos el comando que finalizar la instalacin.

Bash# make install

Una vez realizado estos pasos ya tenemos SSH instalado en nuestra mquina Linux. En
caso de haber optado por una instalacin partiendo de paquetes RPM de RedHat, que son
los que poseen la mayora de las distribuciones actuales de Linux, la instalacin sera an
ms simple, deberamos hacernos con un paquete precompilado correspondiente al
procesador que utilice en su mquina Linux de la direccin siguiente:
ftp.ssh.com/pub/ssh/rpms o de cualquier otra que contenga los paquetes de SSH y
posteriormente realizar la instalacin mediante el comando:

Bash# rpm ivh ssh-X.X.X.rpm

Y esta vez la operacin es mucho ms fcil y cmoda aunque eso s. Slo en distribuciones
de Linux que usen RPM como sus paquetes de instalacin y siempre y cuando encontremos
una versin precompilada compatible con nuestro sistema.

Configuracin de SSH

Antes de iniciar la explicacin de los pasos necesarios para configurar SSH, hemos de
recordar que SSH, es una aplicacin cliente-servidor, por ello es muy conveniente que est
familiarizado con este tipo de aplicaciones. Pues en el caso de SSH, tanto el programa
cliente y el servidor se encuentra en el mismo paquete (algo no muy habitual), por lo que
aunque slo desee utilizar una computadora como cliente y otro como servidor deber
103
instalar ambas partes en las dos computadoras, a no ser que realice la instalacin
manualmente.
Cada una de estas aplicaciones se debe configurar por separado, por ello primero se
configura el servidor y seguidamente el cliente.

Configuracin del servidor SSHD

Tipos de Autorizacin

Para iniciar la configuracin de SSH, es importante, que sepa cules son las distintas
formas de autorizacin que desea utilizar para identificar una sesin de SSH, por ello.
Antes de comenzar con la configuracin del demonio de SSH, mostraremos brevemente
cules son estos tipos y su funcionamiento.

Los tres tipos de autorizacin que soporta el protocolo SSH, son tradicionalmente a travs
de la clave, el sistema de autorizacin por host y a travs del sistema de claves pblicas y
privada. El primero es ms habitual y consiste en que el cliente se conecta con el servidor y
nos solicita la contrasea de ese usuario.

La autorizacin mediante host consiste en instalar la clave pblica del host (hoskey.pub) en
el servidor al que deseamos conectarnos, y si el host y usuario desde el que accedemos se
encuentra autorizado en alguno de los siguientes archivos: hosts.equiv, shorts.equiv. .rhosts,
.shosts. Y siempre que la configuracin del demonio sea la adecuada permitiendo el uso o
no de estos archivos, entonces se conseguir el acceso a la cuenta que estemos accediendo

La autorizacin mediante el sistema de claves pblicas y privadas, consiste en crear las dos
claves y situar la pblica en la computadora remota. Y la privada se mantiene en el host
desde el que queremos acceder. Cuando nos conectamos se comprobarn las claves de
ambas computadoras con la contrasea que nos solicitar en el caso de haber puesto una a
estas claves. En caso de que la comprobacin resulte correcta s nos permitir el acceso.


Parmetros de Configuracin

Para configurar el demonio deber editar el archivo /etc/ssh2/sshd2_config y agregar tantas
secciones de configuracin como desee, estas secciones se usan para poder mantener
diferentes tipos de configuracin segn la direccin que acceda al servidor de SSH. Si lo
desea es ms sencillo mantener una nica seccin para todos los hosts, para declarar estas
seccin use *: y a partir de ah, esta configuracin se utilizar para todos los hosts a no se
que declare otras secciones.
Empecemos a ver cules son las opciones ms interesantes a la hora de configurar el
demonio SSHD:

AllowedAuthentications: Con esta opcin especificamos cules de los mtodos de
autorizacin anterirmente explicados, permitimos para conceder la entrada. La
104
opcin por defecto es publicchey, password, las posibles opciones son las
siguientes: publichey, password y hostbased.

Allow Gruups: Permite especificar qu grupo son los que tienen acceso mediante
SSH, se pueden usar comodines, por defecto se les permite el acceso a los usuarios
pertenecientes a cualquier grupo. (se pueden usar patrones para especificar los
grupos).

AllowHosts: Similar al anterior pero para especificar desde qu hosts se les permite
el acceso mediante SSH.

AllowUsers: Permite especificar a qu usuario se les permite el acceso, por defecto
se permite a cualquier usuario.
Authorization File: Especifica cul es el fichero de autorizacin para cada usuario.
Por defeto es ~/.ssh2/authorization.
ChechMail: Si se activa esta opcin cuando elusuario acceda al sistema, en caso de
que tenga correo se lo har saber. Por defecto esta opcin activada. Opciones yes
ono.
ChRootGroups: Especifica a qu grupo se les aplicar chroot a su directorio home.
ChRootUsers: Similar al anterior pero se especifican patrones de usuarios, en vez
de grupos de usuarios.
DenyGroups: Similar a AllowGroups pero para denegarles el acceso.
DenyHosts: Similar a AllowHost pero para denegarles el acceso.
DnyUser: Similar a AllowUssers pero para denegarles el acceso.
HostkeyFile: Especifica cul es el archivo que contiene la clave privada de esa
computadora. Por defecto es: /etc/ssh2/hostkey.
IdentityFile: Especifica cul es el archivo que contiene la clave pblica del usuario.
Po defecto identificacin.
IgnoreRhosts: Especifica si ignorar o no el contenido de los archivos .shosts,
.rhosts. Opciones yes o no. Por defecto no.
LoginGraceTime: Tiempo (en segundos) antes del cual si no se ha autorizado un
usuario se proceder a cerrar esa conexin. Por defecto 600. Si usa 0 no habr
lmite de tiempo.
MaxConnectons: Especifica el nmero mximo de conexiones simultaneas
permitidas. Si usan 0 no habr lmite.
PermitEmptyPasswords: Especifica si se permite el acceso a cuentas que no
posean clave. Opciones yes o no. Es una buena idea desactivar esta opcin
puede numerosos agujeros de seguridad se dedican a crear una cuenta con un 0 pero
sin clave. De esta manera evitaremos este tipo de ataques.
PermitRootLogin: Especifica si se permite el acceso a la cuenta root del host en el
que estemos configurando el demonio de SSH. Opcines yes, nopwd o no,
donde nopwd slo permite el acceso a la cuenta del root, mediante cualquier mtodo
que no sea especificando la clave, es decir slo mediante hostbased o publickey.
Port: Especifica el puerto en el que escucha las conexiones de demonio de SSH.
105
PublicHostKeyFile: Especifica cules de las autorizaciones permitidas son
obligatorias para permitir el acceso a una cuenta.
Ssh1Compatibility: Especifica si desea o no compatibilidad con la anterior versin
se SSH. Opciones yes o no.
Sshd1Path: Especifica la localizacin del demonio de SSH, para la versin anterior.
UserConfigDirectory: Especifica cul es el directorio donde se almacena las
configuraciones y opciones especficas para cada usuario. Por defecto ~/.ssh2/
UserKnownHosts: Especifica si los archivos de $Home/.ssh2/knownhosts/pueden
usarse para las autorizaciones del tipo hostbased. Opciones yes o no.

Una vez vistas las opciones ms interesantes para la configuracin del demonio de SSH, ya
puede editar el archivo de configuracin y asignar los valores que desee a estos parmetros,
recuerde que stos son los parmetros ms interesantes.


Un primer ejemplo de configuracin de SSHD

Veamos a continuacin un ejemplo de configuracin bastante sencillo, tan slo usaremos
una sola seccin de configuracin e intentaremos no restringir a ningn usuario, host.

# Archivo de configuracin para SSHD 2.0
# /etc/ssh2/sshd2_config

# Seccin de configuracin para todos los hosts.

Port 22
LoginGrceTime 600
MaxConnections 0
Ciprs AnyCipher
PrintMotd yes
CheckMail yes
UserConfigDirectory ~/.ssh2
UserKnownHost yes

# Localizacin de los archivos.

HostkeyFile hostkey
PublicHostKeyFile hostkey.pub
RandomSeedFile random_seed
IdentityFile identification
AuthorizationFile authorization

# Permitimos autorizaciones de los tres tipos.

AllowedAuthentications publickey, password,hostbased

106
#N obligamos a que se produzca ninguna o ninguno inconcreto.

# RequiredAuthentications publickey,password

# Restricciones desctivadas

AllowGroups
AllowUsers
AllowHosts

# DenyGroup noshell
# DenyUsers web,ftp
# DenyHosts evil.com
# PermitRootLogin yes
# IgnoreRhosts no
# PermitEmptyPasswords yes

# Subsistema del SSH

#Carga el subsistema de FTP.

Subsystem-sftp sftp-server


Segundo ejemplo de configuracin de SSHD

Para dar este segundo ejemplo, bsicamente utilizaremos el ejemplo anterior y lo iremos
restringiendo haciendo SSH an ms seguro. Para ello comentaremos algunos ejemplos de
normas habituales para restringir el acceso.
Supongamos que el administrador le comenta que ese demonio slo debe ser accedido
desde su propia red y no desde el exterior, para ello podra usar las siguientes opciones:

AllowHosts midominio.org
DenyHosts *

Ahora que le dicen que los usuarios del grupo shellres, utilizan un shell especial, pudiendo
tan slo acceder a los archivos de su directorio $HOME, y que para ellos ya se han
compilado estticamente los archivos necesarios para estos usuarios. ste es un ejemplo
tpico de cuentas especiales que no deben poder acceder al sistema. Para conseguir estos es
necesario realizar un chroot a su directorio $HOME. En el caso de SSH, basta con aadir la
siguiente opcin para que el demonio lo haga automticamente.

ChRootGroups shellres

Ahora le comentan que la cuenta de root no debe ser accesible mediante SSH, por ejemplo
publickey, password. Para ello aada la siguiente lnea:
107

RequiredAuthentications publickey,password

stos son slo algunos ejemplos tpicos, es por ello muy conveniente que ajuste la
configuracin a sus condiciones y que no se limite a dejar la configuracin por defecto. La
mayor parte de los problemas de seguridad, se podran solucionar con correctas y
restringidas configuraciones, por ello le animamos a que dedique tiempo.


Configuracin del cliente de SSH

Para configurar el cliente de SSH, deber editar el archivo /etc/ssh2/ssh2_config que es el
archivo que contiene la configuracin general para todos los usuarios que usen el cliente de
SSH, aunque si lo que prefiere es personalizar sus opciones para el uso de SSH, deber
crear un archivo en ~/.ssh2/ con el mismo nombre y estructura que anterior. Recuerde que
es posible cambiar la localizacin de este directorio, pero sa es el directorio por defecto.

En el caso del cliente de SSH no nombraremos las opciones que ste permite, pues
prcticamente las opciones por defecto son suficientes para el uso de SSH.
La configuracin del cliente de SSH, se suele hacer ms bien para facilitarle la tarea al
usuario de este cliente como, por ejemplo, personalizado el mensaje que solicita la
contrasea al equipo remoto, o crear configuraciones que a travs de una sencilla palabra
realicen una conexin con un host y usuario predeterminado, por ejemplo, ssh mihost
podra hacer que se conectar con la computadora cuya direccin sea host1.red.externa.com
y con el usuario user1, sin necesidad de que especifiquemos ninguna de esas opciones a la
hora de realizar la conexin.


Configuracin mixta

Veamos ahora un ejemplo de configuracin que es muy habitual para soportar ambas
versiones de SSH, con la configuracin que mostraremos a continuacin, tanto si el cliente
que accede a su servidor de SSH es de la versin SSH1 o de SSH2 podr realizar la
conexin sin preocuparse del servidor. Para realizar estos deber aadir los siguientes para
metros de configuracin al archivo de configuracin:

# Compatibilidad con SSH1

Ssh1Compatibilidty yes
sshdiPath /user/local/sbin/sshd1


Recuerde que la localizacin del demonio SSH1 depende del sistema, aunque sea la
localizacin habitual. De esta forma si se conecta a nuestro servidor de SSH un cliente que
slo soporta la versin SSH1, entonces se lanzar el otro demonio para que se pueda
realizar la conexin,
108
Tenga en cuenta que esto le obliga tambin a configura el demonio SSH1, pues de nada le
servir proteger SSH2 si activa esta opcin y no tiene una correcta configuracin en SSH1,
por ejemplo, si restringe al usuario ROOT en el archivo de configuracin de SSH2, pero no
lo hace en el de SSH1, es posible que alguien consiga entrar en esta cuenta.

Al igual que hemos hecho con el servidor, podemos hacerlo con clientes, de tal manera que
si el servidor remoto de SSH slo soporta la versin SSH1 se usar el cliente de SSH1 con
los mismos parmetros con los que lanz la peticin al servidor. Para lograr esto ha de
aadir las siguientes lneas al archivo de configuracin del cliente de SSH2.


# Compatibilidad con SSH1

Ssh1Compatibility yes
Ssh1Path /usr/local/bin/ssh1

Recuerde, que para que esto funcione, ha de tener correctamente instalados tanto la versin
SSH1 como la SSH2, y a ser posible en sus ltimas versiones respectivamente.

Ejemplos con cada tipo de autorizacin

Autorizacin mediante clave

sta es la forma ms habitual de acceso mediante SSH, veamos un ejemplo de una
conexin utilizando este mtodo de autorizacin:


User$ ssh root@host1.ejemplo.ssh.org
Introduzca la clave del usuario root:
Authentication successful.
Last login: Mon Sep 11 2000 18:41:15 +0200 fron remoto.host.org
No mail.
root# exit
logout
connection to localhost closed


Recuerde que para que sea posible la autorizacin mediante clave, debe tener la palabra
password en la opcin allowedAuthentications. Observe que en este caso la
configuracin s permita el acceso a la cuenta de root.


Autorizacin por host

Primeramente, dejaremos claro los nombres que se usarn en los ejemplos. Tenemos dos
mquinas HostA, la mquina desde la que nos intentaremos conectar, y HostB, la mquina
109
a la que nos conectaremos. Tambin tenemos dos usuarios en esas mquinas, UsuarioHostA
y Usuario HostB.
Para conseguir autorizarnos mediante este mtodo lo primero que deber realizar es crear
las claves en la computadora desde el cual desea realizar la conexin. HostA en nuestro
caso. Para ello teclee el siguiente comando:

Bash#ssh-keygen2 P /etc/ssh2/hostkey

Con esto hemos conseguido crear nuestra llave de autentificacin, crearemos 2 llaves la
privada y la pblica, esta ltima es la que nos interesa a nosotros. La tomaremos, debera
llamarse /etc/ssh2/hostkey.pub y la copiaremos a la mquina HostB en la ruta
/etc/ssh2/knownhosts/HostA.nombre_del_dominio_.ssh-dss.pub. Tambin puede guardarla
en el directorio ~/.ssh/knownhosts/ del usuario remoto al que desee acceder y si ha
permitido estos en la configuracin del demonio.

Se sugiere establecer en el campo nombre_del_demonio para que contenga el dominio de la
mquina, y que HostA pueda conocer en todo momento este mismo. Porello, si las dos
mquinas pertenecen al mismo dominio, deberia aadir al archivo /etc/ssh2_confg la lnea:

DefaultDomain nombre_de_dominio

Pues as no cabe posibilidad de error, si queremos, nos podemos ahorrar este campo al
nobrar las llaves. De todas, formas si no poseemos un servidor de DNS, deberemos aadir
la lnea siguiente en el archivo /etc/hosts del la computadora remota

HostA.nombre_del_dominio HostA

Posteriormente, en la mquina HostB crearemos dentro del directorio del Usuario-HostB,
un archivo llamado. Shsts en el que deberemos incluir el nombre de la mquina que
queremos que acceda, en nuestro caso HostA.nombre_del_dominio, y el usuario que
acceder UsuarioHostA. De forma que al mostrar el archivo obtengamos lo siguiente.

Bash# cat .shosts
HostA.nombre_del_domiio UsuarioHostA
Hay que tener en cuenta que este archivo tiene que tener slo permiso del dueo de la
cuenta, es decir, que el propietario ha de ser UsuarioHostB y con una mscara 0400, es
decir, slo lectura por el dueo del archivo.
Ahora hay que activar la autentificacin basada en hosts, por defecto esta activada, pero no
est de ms comprobarlo. En la mquina HostB buscaremos un archivo llamado
/etc/ssh2/sshd2_config. Una vez encontrado deberemos buscar una lnea que comience por
la palabra AllwedAuthentications y comprobar que es ms o menos tal que as

AllwedAuthentications hostbased, passwd

La palabra hostbased es la que nos interesa, si est incluida ya tenemos el trabajo hecho
pero si no es as, deberemos incluirla y posteriormente mandarle una seal HUP al proceso
de sshd2 con el comando:
110

Bash# Hill HUP cat /var/run/sshd2_22.pid`

Y ya hemos conseguido que nuestro demonio de SSH relea el archive de configuracin.
En la maquina Host A buscaremos la misma lnea, pero esta vez en el archivo
/etc/ssh2/ssh2_config y aun en el caso en el que debamos cambiar algo del mismo, aqu nos
es necesario relanzar el demonio.
Finalmente, entramos en la mquina HostA como el UsuarioHostA y probaremos el
siguiente comando:

Bash# ssh UsuarioHostB@hostB uptime

Esto mostrar el resultado del comando uptime, ejecutado en el servidor remotp. Un detalle
es que la primera vez que se conecta preguntar si se desea conectar, a lo que se responde
que s. Esto es as porque todava no se tiene la llave pblica del servidor.


Autorizacin por medio de llaves

Para conseguir que el mtodo de autentificacin venga dado por la llave del usuario,
deberemos primeramente crearnos un juego de llaves, si no lo tenemos ya, usando el
comando ssh-keygen2. Veamos un ejemplo de creacin de estas llaves:

User$ ssh-keygen2
Generating 1024-bit dsa key pair
1 o0o.o0o.o0o
Key generated.
Passphrase:
Again:
1024-bit dsa, user@host1.ssh.org, Fri Sep 8 2000 21:01:00 +200
Pivate key save to /home/user/ .ssh27id-dsa-1024-b
Public key saved to /home/user/.ssh2/id_dsa_1024_b.pub


Una vez tengamos las llaves mandaremos la llave pblica a la mquina a la que nos
queremos conectar y la copiaremos en el directorio ~/.ssh2/y en el archivo ~/.ssh2/aut-
horization deberemos incluir la lnea:


Key nombre_de_su_ llave.pub

Y en nuestra mquina, en un archivo llamado ~/.ssh2/identification incluiremos la lnea:

Idkey nombre_de su_llave

Recuerde que en la configuracin del demonio de SSH, se establecen los nombres y las
localizaciones de estos archivos, porque si ha modificado estas opciones entonces deber
111
editar los correspondientes archivos de configuracin. Veamos un ejemplo de una
autorizacin mediante llave:

User$ ssh user@host1.ssh.org
Passphrase for key /home/user/.ssh2/id_dsa_1024_a with comment 1024-bit
Dsa, user@host1.ssh.org Fri Sep 8 2000 20:59:45 +0200:
Authentication successful.
Last login: Fri Sep 8 2000 21:04:00 +0200 from host1.ssh.org
No mail.
User$ logout
Connection to host1.ssh.org closed.


Otras utilidades de SSH.

Entre otras muchas posibilidades SSH permite el redirigir puertos de forma segura para
encriptar las trasmisiones. En la versin SSH1 esto se utilizaba para no enviar las claves de
FTP en texto. En la versin SSH2 se ha aadido un mdulo al servidor de SSH y un cliente
de (FTP) para realizar conexiones seguras de transferencia de archivos, pero este mdulo
no utiliza el protocolo FTP, sino que utiliza el propio protocolo SSH.

Para que su servidor de SSH soporte las transferencias de archivos seguras deber aadir el
mdulo de FTP seguro a la configuracin del demonio de SSH, para ello, edite el archivo
/etc/ssh2/sshd2_config e incluya en l la siguiente lnea:

subsystem-sftp sftp-server

Una vez aadida esta lnea deber reiniciar el servidor d SSH, para ello ejecute el siguiente
comando:


Bash# kill- HUP `cat /var/run/sshd2_22.pid

A continuacin se muestra un ejemplo de transferencia de archivos mediante el cliente sftp:

User$ sftp host1.ejemplo.ssh.org
Sftp> cd /tmp/ejemplos
sftp> get test
test 0 kb/s 0.0 kB/s TOC:: 00:00:01 100%
sftp> quit

Como puede observar en este ejemplo, no ha sido necesario especificar una contrasea,
pues el host desde el que hemos accedido estaba autorizado en el archive. hosts del usuario
remoto. Tenga especial cuidado con estos archivos pues una entrada incorrecta, puede hacer
que se puedan transferir archivos a su computadora.
112
El manejo del cliente SFTP es muy similar al de cualquier cliente de texto de FTP, por lo
que si est habituado a la transferencia de archivos mediante FTP, no le ser necesario
ningn esfuerzo a la hora de usar SFTP. Resaltar que el cliente SFTP, posee comandos para
movernos tanto localmente (algo no muy habitual), como remotamente, por ejemplo, para
visualizar los archivos localmente deber usar el comando lls.


4.7.2 VNC. (Virtual Network Computing)

Con el nombre de escritorio remoto se hace referencia a la posibilidad de acceder al
escritorio personal de un usuario sobre una computadora, desde otra computadora a
distancia, por medio de una conexin de red.
Este tipo de uso de computadora (usar una desde otra) tambin suele llamarse Acceso de
Terminal Remoto. Existe innumerable software para permitir este tipo de acceso. Entre los
ms destacables se encuentra el sistema VNC, un software libre de acceso a escritorio
remoto, con cdigo fuente abierto, que funciona sobre todo tipo de sistemas operativos,
tales como Windows, Linux, etc.

Tener acceso remoto a nuestro equipo puede ser muy til. Con un servidor VNC podemos
administrar remotamente servidores WEB o FTP, controlar el estado de descargas o tareas
que requieren mucho tiempo como compilaciones o simplemente acceder desde cualquier
lugar a toda la informacin que tenemos en el disco duro.

VNC son las siglas de Virtual Network Compuing, Computacin en Red Virtual y es un
programa de software libre para permitir el acceso remoto a terminales grficos. El
servidor tiene tanto clientes como servidores para todo tipo de sistemas operativos
(Windows, Unix, Linux, etc) lo que le hace muy verstil. Por el contrario la enorme
carga de red que conlleva (incluso en sus versiones ligeras y que no puede abrir una sesin
sino que tiene que compartir una abierta son sus mayores inconvenientes.

VNC fue desarrollado en los laboratorios de AT&T en Cambridge y actualmente
distribuido por RealVNC, una compaa fundada en 2002 para desarrollar, mejorar y
promocionar comercializar el VNC. El VNC est basado en el protocolo RFB (Remote
Buffer Protocol) [TRIS 2002].desarrollado en los laboratorios de Olivetty y Oracle (ORL
Olivetty and Oracle Research Laboratorio). RFB es un protocolo simple de acceso a
interfaces grficas de usuario. Debido a que trabaja a nivel de frame buffer es aplicable a
todos los sistemas de ventanas y aplicaciones incluyendo X11, Windows 3.1/95/98/NT/XP
y Macintosh.

Actualmente, el protocolo est siendo modificado por terceros para introducir
caractersticas adicionales como transferencia de archivo, mensajera, impresin remota y
reproduccin de audio.

VNC es una aplicacin cliente-servidor que nos permite la conexin remota entre equipos
conectados en Red. Cuando se habla de una aplicacin cliente-servidor, tenemos que contar
con una conexin mnima de dos computadoras conectadas mediante una infraestructura de
red. En el caso de VNC, la aplicacin cliente-servidor, nos permite manejar desde una de
113
las computadoras (cliente) las aplicaciones y recursos de otra computadora (servidor), para
ello, es preciso instalar dos programas: un servidor VNC, en la maquina a la que queremos
acceder, y un visualizador VNC en la maquina cliente. De esta manera podemos ejecutar un
sistema Windows desde un Macintosh, plataforma Linux o cualquier sistema operativo,
como puede ser, Unix, Novel, etc.

VNC fue creado para posibilitar la administracin en equipos remotos. Tan slo debemos
instalar la aplicacin VNC Server en el equipo que deseamos visualizar y la aplicacin
VNC cliente en la maquina desde la que queremos tener acceso. La aplicacin no slo nos
permite la conexin entre dos equipos, si no que nos posibilita adems crear una
infraestructura compartiendo los recursos de nuestro servidor desde varios equipos
clientes.


VNC ofrece mltiples combinaciones. Visualizar una aplicacin ejecutada en nuestra
computadora VNC Server y ser visualizada por todas las computadoras VNC clientes, Si
nos situamos en una actividad de aula, todo el alumnado podra visualizar la pantalla del
profesor mientras se desarrolla la leccin, En condiciones ideales, VNC puede ser utilizado
para que muchas computadoras de baja potencia puedan acceder a un servidor de
aplicaciones con altas prestaciones, De esta manera en un sistema multiusuario, como
Linux, cada persona puede visualizar simultneamente un perfil nico de trabajo (pantalla,
programas, espacio en disco, seguridad). Instalacin para hacer una prueba de la
herramienta, necesitamos realizar una descarga de la aplicacin desde la pgina WEB,
Recordemos que VNC es un programa de cdigo abierto bajo licencia GPL.

Una vez accedemos a la pgina de descarga, seleccionamos la opcin Free Edition.
Rellenamos el formulario. Seleccionamos la versin completa de VNC Server y Viwwer
para nuestro sistema operativo. Para las plataformas Windows encontramos un paquete
ejecutable y una versin comprimida en zip. Seleccionamos la ejecutable y accedemos a
una primera pantalla. Pulsamos next, aceptamos la licencia y accedemos a una pantalla que
nos indicar la carpeta para alojar nuestra aplicacin, en nuestro caso por defecto. Una vez
seleccionada la carpeta, nos muestra una pantalla donde elegimos entre las dos opciones
que nos permite la aplicacin, como servidor o como cliente.

Una red con velocidad de 1000Kb puede presentar un bajo rendimiento en la respuesta de
las aplicaciones debido a su lentitud, es conveniente no ejecutar demasiadas aplicaciones al
mismo tiempo e intentar economizar la conectividad remota, Uno de los problemas que nos
podemos encontrar es la perdida de conexin entre los equipos, que se soluciona
reiniciando la sesin. Accesibilidad, no siempre se presenta la informacin de la misma
manera, si bien es cierto que el servidor siempre habilita un puerto y un numero IP. Que
permite el acceso al cliente, las prestaciones y la calidad de resolucin dependen
exclusivamente de la infraestructura de la computadora que las visualiza o de la propia
aplicacin que este siendo ejecutada en el servidor.

Los permisos de seguridad para clientes, en una plataforma Windows (no as en otras
plataformas como Linux), sern los establecidos por el servidor para cada uno de los
perfiles de seguridad configurados por el propietario o administrador de la maquina a la que
114
tengamos acceso, De esta forma si la aplicacin Viewer ha sido instalada en un perfil de
usuario determinado, heredaremos todos sus perfiles de trabajo. Conectividad, La
conectividad se realiza a travs de un puerto y un protocolo determinado, en nuestro caso el
protocolo usado es el TCP/IP.

El VNC Server, en cualquier de los casos, asigna un numero IP dinmico,
automticamente, mediante la funcin DHCO, en una red interna, conectada a travs de un
router proporcionado por un proveedor de mercado, normalmente, no es asignada una IP
fija, indispensable para podernos conectar desde un fuera de nuestra red interna, ya sea una
oficina, casa, etc. Si dispusiramos de una IP fija para poder salir de nuestra red interna al
exterior y poder acceder a nuestro servidor, VNC nos permitira introducir el nmero IP fijo
que tenga asignado el servidor, siempre y cuando est habilitado el puerto de comunicacin
utilizado por nuestra aplicacin.



La conectividad depender de la infraestructura a la que pertenezca el ordenador que
pretenda ser visualizado, tenemos la posibilidad de acceder a travs de http, teniendo
instalado un visor de JAVA, introduciendo el nombre del servidor, dos puntos y, a
continuacin, indicar el puerto utilizado. En otras plataformas, en distribuciones Linux
encontramos cuatro programas:

VNC SERVER. Script en Perl que arranca el servidor X VNC, en la primera llamada
ejecuta, por usuario y maquina, VNC passwd para establecer una clave de acceso para los
distintos escritorios.

VNC VIEWER. Cliente de VNC con el que visualizamos los escritorios para poder
manejarlos.

VNC PASSWD. Programa que nos permite cambiar la clave de acceso dde los distintos
escritorios remotos.

XVNC. Servidor X VNC. La llamada ha este programa se realice a travs del script VNC
Server. La instalacin se har a partir de un paquete *.tar.gz. Para ello habr que
descomprimirlo y desempaquetarlo. Todos los ejecutables estn ya listos para ser utilizado.
Hay que saber que algunas distribuciones de Linux, disponen de aplicaciones VNC
integradas en el propio escritorio.


VNC Caractersticas.

El protocolo VNC transmite desde el cliente al servidor las pulsaciones de teclado y los
movimientos del ratn, y desde el servidor al cliente las actualizaciones de pantalla. Esto
tiene ventajas e inconvenientes. Con VNC el servidor puede ver en todo momento lo que
est haciendo el cliente, porque ambos controlan la misma pantalla, pero no pueden trabajar
115
los dos a la vez en la misma computadora. A cambio, es un sistema altamente portable entre
diferentes sistemas operativos, al no depender de ninguna caracterstica de este.

Las actualizaciones de pantalla se hacen enviando las partes de la pantalla que hayan
cambiado, enviando solo pequeos rectngulos con las variaciones. Esto funciona muy bien
cuando los cambios en pantalla son pocos, pero cuando hay grandes variaciones, por
ejemplo, cuando arrastramos una ventana por la pantalla. Para evitar tener que enviar tantos
datos por la red y acelerar la tasa de refresco, el protocolo VNC puede utilizar diferentes
tipos de compresin en las actualizaciones que se envan.

El rendimiento del programa no depende de la velocidad de procesamiento o alta prestacin
de nuestro equipo sino de la conexin de red. Una red con una velocidad de 1000Kb
presentar un bajo rendimiento en la respuesta de las aplicaciones debido a su lentitud. Es
conveniente no ejecutar demasiadas aplicaciones al mismo tiempo e intentar economizar la
conectividad remota, uno de los problemas que nos podemos encontrar es la perdida de
conexin entre los equipos, que se soluciona reiniciando la sesin.

No siempre se presenta la informacin de la misma manera, si bien es cierto que el servidor
siempre habilita un puerto y un IP, que permite el acceso al cliente, las prestaciones y la
calidad de resolucin dependen exclusivamente de la infraestructura de la computadora que
las visualiza o de la propia aplicacin que este siendo ejecutada en el servidor.

Los permisos de seguridad para el cliente, en una plataforma Windows (no as en otra
plataformas como Linux), sern los establecidos por el servidor para cada uno de los
perfiles de seguridad configurado por el propietario o administrador de la maquina a la que
tengamos acceso. De esta forma si la aplicacin Viewer ha sido instalada en un perfil de
usuario determinado, heredaremos todo sus perfiles de trabajo.

La conectividad se realiza a travs de un puerto y un protocolo determinados, en nuestro
caso el protocolo usado es el TCP IP. El VNC Server, en cualquiera de los casos, asigna un
numero IP dinmico, automticamente, mediante la funcin DHCP. En una red interna,
conectada a travs de un router proporcionado por un proveedor de mercado, normalmente,
no es asignada una IP fija, indispensable para podernos conectar desde un lugar fuera de
nuestra red interna, ya sea una oficina, casa, etc.

Si dispusiramos de una IP fija para poder salir de nuestra red interna al exterior y poder
acceder a nuestro servidor, VN nos permitira introducir el nmero IP fijo que tenga
asignado el servidor, siempre y cuando est habilitado el puerto de comunicacin utilizando
por nuestra aplicacin.


4.7.3 RDESKTOP. (Remote Desktop Protocol).

Es un cliente de cdigo abierto que permite conectarse por red a cualquier mquina que
ejecute el protocolo RDP (Remote Desktop Protocol).
Microsoft Terminal Server (RDP), con l es posible ejecutar aplicaciones en un equipo
remoto que utilice Windows XP Professional desde cualquier otro cliente que utilice un
116
sistema operativo Microsoft Windows XP Professional y slo las entradas de teclado, las
entradas del ratn y los resultados de la pantalla se transmiten a la ubicacin remota a
travs de la red. Todo ello gracias al nuevo protocolo RDP que funciona sobre TCP/IP. Es
software propietario.

El protocolo de escritorio remoto es una extensin de, la familia de T-120 de estndares
del protocolo. Un protocolo capaz multicanal permite independientes canales virtuales para
presentacin de datos de presentacin, comunicacin de dispositivos serie, informacin de
licencias, datos cifrados de la conectividad del teclado y ratn, otra funcin es conservar
como parte de RDP, como las caractersticas de arquitectura necesaria para admitir
mltiples puntos es decir sesiones para varios equipos y envo de datos multipunto permite
los datos de una aplicacin sern entregados en tiempo real a varias partes sin tener que
enviar los mismos datos a cada sesin de forma individual

Una razn que Microsoft decidi implementar RDP para fines de conectividad de Windows
NT Terminal Server es que proporciona una base muy extensible desde el que se generan
otras muchas funciones.

RDP est diseado para admitir varios tipos diferentes de topologas de red (como ISDN
(RDSI), servicio de telefona Convencional y muchos protocolos de LAN, como IPX,
NetBIOS, Tcp/IP). La versin actual de RDP slo se ejecuta a travs de TCP/IP pero, con
los comentarios del cliente, otra compatibilidad con otros protocolos pueden agregarse en
versiones futuras.

RDP se basa en la familia de protocolos ITU t.120. Es un protocolo multicanal que permite
separar canales virtuales para transportar la informacin entre el servidor y el cliente.
Utiliza encriptacin y soporta ms de 64000 para la transmisin de datos y proporciona
transmisiones multipunto.

En el servidor RDP usa su propio driver de video para procesar la salida por pantalla en los
clientes recibe los datos procesados y los interpreta con su correspondiente tarjeta grfica.
Las entradas de datos a travs del teclado y el ratn son redireccionadas al servidor, hacia
un teclado y ratn virtual que se encarga de interpretar los eventos.



4.7.4 TELNET. (Terminal Networking).

El protocolo TELNET, naci prcticamente por necesidad, De qu sirve poseer una red
rica en aplicaciones, si no podemos acceder a computadoras remotas y usar estas
aplicaciones? ste protocolo fue su principal motivo por el cual se diseo el protocolo
TELNET.

Este protocolo est orientado a proporcionarnos una conexin remota con un host mediante
TCP, para que podamos utilizar los recursos y aplicaciones de esa mquina, sin necesidad
de estar sentado frente a esa computadora.
117
Otra de las razones por la cual se produjo el nacimiento de este protocolo, fue porque cada
uno de los fabricantes estaba intentando lanzar su propio sistema propietario es decir, sus
propios terminales y aplicaciones para poder comunicarse con sus computadoras. Esto
provoc incompatibilidades entre aplicaciones y terminales de distintos fabricantes.

Con la aparicin del protocolo TELNET, los fabricantes deban implementar en sus
servidores el servicio TELNET y en sus terminales un cliente, de esta manera, se poda
acceder mediante cualquier Terminal a distintos sistemas, sin necesidad de que fueran del
mismo fabricante.

Otra de las ventajas del protocolo TELNET, es que ste. Se diseo de forma general para el
establecimiento de conexiones TCP entre dos hosts. Esto ha aportado una flexibilidad a
este protocolo, ya que no slo se usa para acceder remotamente a un host, sino que
TELNET, es el soporte en las aplicaciones cliente/servidor de otros servicios como:
servicio de transferencia de archivos (FTP), servicio de noticias (NEWS), servicio World
Wide Web (WWW) y otros muchos.

Funcionamiento del protocolo TELNET.

El funcionamiento de TELNET tiene el siguiente procedimiento: el usuario interacciona
con una aplicacin denominada cliente de TELNET, la cual se conecta al host el que se
desea realizar la conexin, manteniendo una conexin TCP con el puerto 23 del host
remoto. Que es el puerto en el cual escucha el servidor TELNET.
Una vez que la conexin ya est establecida el cliente se limita a enviar las pulsaciones de
teclado realizadas en el host local y mostrar por la pantalla del Terminal los datos que le
son enviados desde el host remoto.



Figura 4.9. Funcionamiento de TELNET.


El host remoto se dedica a escuchar las peticiones que le son realizadas a travs del puerto
23, as como interactuar con las aplicaciones que le son realizadas a travs del puerto 23,
as como interactuar con las aplicaciones, enviando los resultados al cliente. Aunque sta es
la forma bsica de comunicacin entre el cliente y el servidor de TELNET, es habitual que
el sistema no responda con un shell para poder ejecutar comandos, sino que se presenta un
sistema de autentificacin. Tradicionalmente un login y una clave son necesarios para
poder acceder a dicho shell.
El cliente se conecta al puerto 23
del servidor.
Servidor
TELNET


TCP
Cliente
TELNET


TCP
118
Tambin es posible que entre el cliente y el servidor, antes de iniciar su sesin de TELNET,
se intercambien una serie de parmetros como: tipo de Terminal, parmetros de
autentificacin, etc.

El cliente TELNET

El cliente de TELNET, como ya se ha comentado, tiene la misin de comunicarse con el
host remoto. Hace ya algn tiempo que no se usan terminales especficos para realizar las
conexiones, sino que se usa una aplicacin que permite emular a varios tipos de terminales
hardware y algunos virtuales. La aplicacin de emulacin de un Terminal es la primera
aplicacin de TCP/IP.
Los sistemas operativos de tipo UNIX, como es el caso de Linux, suelen llevar incorporado
un cliente de TELNET, que podemos ejecutar mediante el comando TELNET de igual
nombre que el protocolo. Mostraremos un ejemplo de una conexin mediante este
comando:

User$ telnet host1.midominio.org
Tryng 192.168.1.1
Connected to host1. midominio.org
Escape carcter is ` ^] `

Login: xxxxx
Last login: Sat Jul 29 19:02:08 from xxxxx
[xxxxx@xxxxx xxxxx]$ logout
Connection closed by foreign hot.

Como habr comprobado, tambin se le indica cul es el carcter de escape, este carcter o
esta secuencia de pulsaciones, le permitirn volver a la consola local para cerrar la
conexin o cambiar a otra, aunque habitualmente es ms correcto ejecutar algn tipo de
comando para que el servidor cierre la conexin (logout), Pero la secuencia de escape s
resulta til en cierto caso, por ejemplo: se ha quedado colgada la conexin o no hemos
podido obtener el shell.


El problema de TELNET

El gran problema del protocolo telnet es la seguridad, puesto que en las redes de difusin
que son las ms habituales (Ethernet. FDDI, etc.) cualquier host conectado a esa red puede
obtener el login y la contra sea enviados por el telnet, a no ser que se hayan puesto medio
para evitar la difusin como, por ejemplo, el uso de swiches en ves de concentradores.

Aunque este problema ya est a punto de dar fin, puede desde hace algn tiempo se diseo
un sistema para que los clientes no enviaran las claves sin cifrar (Kerberos9. Adems
actualmente, se ha diseado un nuevo sistema para realizar conexiones remotas permitiendo
que stas sean mucho ms seguras (SSH).

119
4.7.5 TERMINAL X

Un servidor de Terminal X-Windows hace que las aplicaciones se ejecuten en el servidor X
y la visualizacin y captura de eventos de teclado y ratn sucedan en el Terminal. El
acceso a las secciones se realiza mediante el protocolo XDMCP.
Las terminales X son lo ltimo en terminales inteligentes y contienen una CPU tan potente
como la de la computadora principal con memoria, pantalla de gran resolucin, teclado y
ratn, y se comunica con ste por medio de una red, como Ethernet.

Un Terminal X es una computadora que ejecuta software X. Los programas de un Terminal
X, llamados servidores X, recogen informacin del teclado o ratn y aceptan comandos de
una computadora remota. Los servidores x se comunican a travs de una red con los
clientes X, que son ejecutados en algn host remoto.
La pantalla de un Terminal X contiene un determinado nmero de ventanas. Cada cliente X
es un programa llamado manejador de ventana, encargado de controlar en tareas como la
creacin, borrado, movimiento, etc. Pata ello el cliente x enva comando al servidor X
indicndoles lo que tiene que hacer.

Los dispositivos terminales son full-duplex. Los caracteres de entrada pueden llegar en
cualquier momento, incluso cuando el Terminal est enviando salida al hardware. Lo
caracteres entrantes se van almacenando en un buffer.


4.8 Gambas (Gambas Almost Jeans BASIC).

Es decir, `Gambas casi quiere decir Basic`. De hecho, Gambas abre el entorno de la
programacin visual en Linux a todo el mundo, como lo hizo en su da Visual Basic, en
Windows. Pero como el tiempo no pasa en vano, Gambas intenta no reproducir los errores
que se cometieron entonces. La ampliacin del lenguaje BASIC alcanza con Gambas
amplias cotas de potencia, profesionalidad y modernidad, sin abandonar nunca la sencillez
y claridad de este lenguaje de programacin de alto nivel. Ya nunca ms se podr decir que
construir aplicaciones visuales para Linux es un proceso largo y complejo que lleva aos de
trabajo.

Gambas no es slo un lenguaje de programacin, es tambin un entorno de programacin
visual para desarrollar aplicaciones grficas o de consola. Hace posible el desarrollo de
aplicaciones complicadas muy rpidamente. El programador disea las ventanas de forma
grfica, arrastra objetos desde la Caja de Herramientas y escribe cdigo en BASIC para
cada objeto. Gambas est orientado a eventos, lo que significa que llama automticamente a
los procedimientos cuando el usuario de la aplicacin elige un men, hace clic con el ratn,
mueve objetos en la pantalla, etc.

Con la popularizacin de sistemas operativos libres como GNU/Linux, stas y otras razones
hacan prever que la aparicin de un entorno no equivalente libre sera un xito y
contribuira a la presentacin de muchos nuevos desarrollos que lo utilizaran. Ha habido
varios intentos que no han cuajado, bien por la lentitud de su evolucin, bien por su
dificultad de uso o por no ser totalmente libre y no haber arrastrado a una comunidad de
120
usuarios detrs. Finalmente, Benoit Minisini, un programador con experiencia en la
escritura de copiladores que estaba harto de luchar contra los fallos de diseo de Visual
Basic, y deseaba poder usar un entorno de GNU/Linux fcil en su distribucin, comenz a
desarrollar su propio entorno para Linux basado en BASIC.

El 28 de febrero de 2002 puso en Internet la primera versin pblica de Gambas: gambas
0.20 Benoit elimin del diseo del lenguaje bastantes de los problemas que Visual Basic
tena, como la gestin de errores, y le aadi caractersticas comunes en los lenguajes
actuales ms modernos, como la orientacin a objetos y la propia estructura de los
programas. Como prueba de fuego, el propio entorno de desarrollo fue programado en
Gambas desde la primera versin, sirviendo a un tiempo de demostracin de la potencia del
lenguaje y de deteccin de necesidades y correccin de errores que fueron incorporando a
las distintas versiones.

En enero de 2005, Benoit public la versin 1.0, en la que ya se incorporaba un puado de
de componentes desarrollados por otros programadores que colaboraron con l: Daniel
Campos, Nigel Gerrard, Laurent Carlier, Rob Kudla y Ahmad Kahmal. Esta versin se
consider suficiente estable y cerr un ciclo. A partir de esa fecha empez la programacin
de la versin 2.0. sta ya incluye algunas mejoras en l lenguaje, muchos ms componentes
y un nuevo modelo de objetos que permitirn usar Gambas en un futuro para el desarrollo
de aplicaciones WEB con la misma filosofa y facilidad que actualmente se usa para
aplicaciones de escritorio.


Un entorno libre

Gambas es un entorno de desarrollo que se distribuye con la licencia GPL GNU (General
Public Licence). Esto significa que se distribuye siempre con el cdigo fuente y respeta las
cuatro libertades que define la Free Software Foundation:


La libertad de usar el programa con cualquier propsito (libertad 0).


La libertad de estudiar cmo funciona el programa y adaptarlo a las propias
necesidades (libertad 1). El acceso al cdigo fuente es una condicin previa para
esto.

La libertad de distribuir copias, con las que se puede ayudar al vecino (libertad 2).


La libertad de mejorar el programa y hacer pblicas las mejoras a los dems, de
modo que toda la comunidad se beneficie (libertad 3). El acceso al cdigo fuente es
un requisito previo para esto.


121
Una de los engaos ms comunes en el uso de Software Libre es la creencia de que este
modelo de desarrollo obliga a que el trabajo se publique gratis, lo que es del todo incierto.
Estas cuatro libertades permiten que, quien lo desee, venda copias de Gambas (entregando
siempre el cdigo fuente y respetando esas cuatro libertades) y, por supuesto, de cualquier
aplicacin desarrollada con este programa. Las aplicaciones desarrolladas con Gambas
pueden o no acogerse a la licencia GPL.

Tambin cualquier programador es libre de alterar el propio lenguaje y modificarlo a su
gusto, siempre y cuando entregue el cdigo correspondiente a esas modificaciones y respete
los derechos de autor de los desarrolladores originales.
Aparte de estas libertades propias de la naturaleza de un proyecto de Software Libre sobre
GNU/Linux, Gambas aade ms facilidades para el programador:

Una ayuda muy completa de lenguaje y cada uno de los componentes, algo que es
muy de agradecer para los que empiezan a programar en Gambas, y que no es
habitual en los proyectos de Software Libre. La ayuda que se publica est en ingls,
pero existen un grupo de personas trabajando en la traduccin a espaol.

Una API (Interfaz para programar la aplicacin) sencilla y bien documentada, lo
que facilita a los programadores crear nuevos componentes para Gambas. La API
no es de utilidad inmediata para quien desarrolle con este lenguaje, pero permite a
los programadores avanzados que lo deseen aadir funcionalidades al entorno de
desarrollo y crear nuevas herramientas para Gambas.

El lenguaje est preparado para ser independiente del gestor de ventanas que use. Esto
significa que, sin cambiar una sola lnea de cdigo, una aplicacin puede ser compilada
para ser ejecutada en un escritorio Gnome o KDE, usando las libreras propias de ese
escritorio y siendo una aplicacin nativa de ese entorno. En el futuro se pueden desarrollar
componentes para Windows, Fluxbox y otros gestores de ventanas, y los programas no
tendrn que modificarse su cdigo para que sean aplicaciones nativas de esos entornos,
Marcando, antes de compilar, una opcin en el entorno de desarrollo para elegir el
componente a usar (actualmente se puede elegir entre gtk y qt, para Gnome o KDE), se
generan distintas aplicaciones para distintos entornos con el mismo cdigo fuente. Esta
caracterstica no se encuentra disponible en ningn otro lenguaje existente, lo que convierte
a Gambas en un entorno nico.

4.8.1 Elementos de Gambas

Para poder desarrollar y ejecutar programas hechos con Gambas, son necesarios distintos
elementos:

Un copilador, que se encargar de transformar todo el cdigo fuente y archivos que
formen parte de un proyecto hecho en Gambas, en un programa ejecutable
.
Un intrprete capaz de hacer que los programas hechos en Gambas sean ejecutados
por el sistema operativo.
122

Un entorno de desarrollo que facilite la programacin y diseo de las interfaces
grficas de los programas.

Componentes que aaden funcionalidades al lenguaje. La palabra componente en
Gambas tiene un significado especfico, ya que no alude a partes genricas, sino a
libreras especficas que le dotan de ms posibilidades. En la actualidad existen
componentes para usar xml, conexiones de red, opngl, sdl, ODBC, distintas bases
de datos, expresiones regulares, escritorios basados en qt, en gtk, etc. Estos
componentes son desarrollados por distintos programadores, siguiendo las
directrices de la API de Gambas y la documentacin publica al efecto por por
Benoit Minisini.


4.9 Pruebas realizadas.


Se realizaron pruebas de la ejecucin del sistema operativo para clientes ligeros en
GNU/Linux, La ejecucin del sistema fue a travs de CD-ROM.
El CD-ROM es un SAMSUNG modelo SH-S202, es el mismo que se utilizo en todas las
pruebas ya que la velocidad de lectura del CD-ROM es un factor importante por que puede
atrasar o adelantar el inicio del sistema.


Procesador 600 MHz 900 MHz 1 Ghz 2.4 GHz 1.6 GHz 1.6 GHz
Marca Intel
Pentium
Intel
Celeron
Intel
Pentium
Intel
Pentium
Intel
Atom
Intel
Atom
Memoria
RAM
256MB 256 MB 1 GB 1 GB 2 GB 1 GB
Proceso1 02:32 02:28 02:23 01: 54 01:52 01:58
Proceso 2 00:42 00:30 00:29 00:29 00:32 00:31
Proceso 3 00:06 00:005 00:05 00:04 00:04 00:04
Proceso 4 00:15 00:12 00:09 00:07 00:06 00:06

Figura 4.10. Tabla de resultados experimentales con distintos procesadores.

Proceso1: Tiempo que tarda desde que se aplica voltaje al cliente ligero y este nos solicita
una contrasea de entrada.

Proceso 2: Tiempo que tarda desde el momento en que se presiona Enter despus de
proporcionar una contrasea de entrada hasta el momento que entramos al escritorio del
Sistema GNU/Linux para clientes ligeros.

Proceso 3: Tiempo que tarda en el momento que estamos en el escritorio y entramos a la
interfaz de conexin.

123
Proceso 4 Tiempo que tarda en entrar al servidor desde un cliente ligero utilizando RDP.

El tiempo esta en Minutos.


La red es de 100 Mbits.

El Lector de CD-ROM es un Samsung Modelo SH-S202 fabricado en Abril de 2008 y fue
utilizado en todas las pruebas de arranque del sistema operativo de GNU/Linux para
clientes ligeros.


124
Captulo 5
Conclusiones y Trabajos futuros

5.1 Conclusiones

El Sistema operativo GNU/Linux especialmente diseado para clientes ligeros, ha
demostrado su versatilidad al poderse ejecutar desde disco duro, memoria Flash y CD-
ROM.
En las pruebas realizadas con diferentes tarjetas madre con procesadores del tipo Intel
Pentium 600 MHz, 1GHz, y 2.4 GHz, Pentium Celeron 900 MHz y Intel Atom 1.6 GHz se
utilizo el mismo CD-ROM para el arranque del sistema operativo GNU/Linux para cliente
ligero en las cinco tarjetas madre con su respectivo procesado.

Es importante la velocidad de lectura del CD ROM pues el sistema operativo para
clientes ligero se ejecutara con mayor velocidad si el lector tambin lo es, si se utiliza un
lector con una velocidad menor se vera afectada la velocidad de ejecucin del sistema
operativo para clientes ligeros.

Es importante deshabilitar los elementos que no se ocupen tanto de las tarjetas madre
obsoletas como de las especiales para clientes ligeros. De esta manera el sistema operativo
que se ejecuta desde el CD ROM revisa y da de alta todos los elementos de la tarjeta
madre si esta tiene menos elementos, el sistema operativo tardar menos en ejecutarse.
Estos elementos son los que no se ocupen como el puerto serial, puerto paralelo y
MODEM.

La velocidad del procesador de un cliente ligero no determina una mayor velocidad de
inicio del sistema operativo, ni una mayor velocidad de conexin con el servidor utilizando
la interfaz hecha en gambas, si hay una pequea diferencia pero es por unos cuantos
segundos, como se puede apreciar en la tabla de resultados.

La memoria RAM puede ayudar a mejorar la velocidad de arranque y conexin, pero no es
un elemento determinante, los equipos empleados como cliente ligero tienen memoria
RAM desde 256 MB hasta 2GB y no se encontr gran diferencia de tiempo de inicio del
sistema operativo y de conexin con el servidor utilizando la interfaz en gambas.

Los clientes ligeros hechos con computadoras obsoletas no cumplen con algunas
caractersticas de los clientes ligeros comerciales.

Las tarjetas madre de computadoras obsoletas no son compacta pues el rango varia
entre (24cm x 30cm), (21cm x 30cm), (22cm x 24cm) y (24cm x 24cm) si la
comparamos con una tarjeta diseada para cliente ligero de (17cm x 17cm) puede
fabricarse su gabinete con material de desecho o en su defecto utilizar los gabinetes
disponibles.
125
Los clientes ligeros fabricados con computadoras obsoletas no son silenciosos en su
operacin pues generan ruido procedente de los ventiladores que como mnimo
llevan cinco aos trabajando estos ventiladores son de la fuente de voltaje y del
procesador.
Los clientes ligeros fabricados con computadoras obsoletas ahorran energa al no
tener disco duro instalado, y tener perifricos deshabilitados como MODEM,
puerto serial y puerto paralelo. El procesador consumir energa, igual que antes
cuando era una computadora obsoleta no hay un mtodo de ahorro de energa para
el procesador para clientes ligeros hechos con computadoras obsoletas.
Los clientes ligeros fabricados con computadoras obsoletas si generan calor este
procede del procesador y de la fuente de voltaje.


Los clientes ligeros hechos con el procesador Atom de Intel si cumple con todas las
caractersticas de los clientes ligeros.

Es ligero su peso es igual o menor a una computadora laptop.
Su consumo de energa es bajo.
Son silenciosos, por su bajo consumo de energa, a la fuente se le puede quitar el
ventilador, sin que esta presente calentamiento. El procesador Atom no necesita
ventilador y cuenta con un disipador de aluminio muy pequeo.
No genera calor.


Independientemente del cliente ligero hecho con computadoras obsoletas o con hardware
especialmente diseado para cliente ligero, realizan su funcin de ejecutar el sistema
operativo GNU/Linux cliente ligero y de conexin con servidor, excelentemente.

La seleccin de una tarjeta de red es un elemento importantote en el cliente ligero.
La seleccin de una tarjeta de red para una computadora en particular se basa en varios
factores diferentes:

El protocolo de enlace de datos utilizados por la red.
La velocidad de transmisin de la red.
El tipo de interfaz que conecta la tarjeta a la red.
El tipo de bus en el que se instala la tarjeta.
Los recursos de hardware requeridos por la tarjeta.
La potencia elctrica de la tarjeta.
El papel de la computadora que usa la tarjeta: servidor frente a estacin de trabajo, y
computadoras domstica frente a computadoras de empresas
La disponibilidad de controladores apropiados.

En los clientes ligeros los protocolos pueden funcionar a diferentes velocidades y la
capacidad de una tarjeta de red para admitir esas velocidades y puede ser un factor
importante en el desempeo del cliente ligero.
126
Una tarjeta de red a elegir son las tarjetas Fast Ethernet que admiten velocidades de 10 y
100 Mbps.

El contar con una red 100 Mbps garantiza que el cliente ligero ejecute las aplicaciones del
servidor sin que exista latencia.


Las ventajas de los clientes ligeros sean de computadoras obsoletas o no son las siguientes:

No se instala localmente software en ningn cliente ligero, todo est en el servidor.
Un ahorro de licencias en entornos Microsoft.
El utilizar un entorno GNU/Linux para utilizarlo como sistema operativo a parte de
ser una alternativa libre tiene una gran capacidad, calidad y confiabilidad.
La actualizacin de un software para todos los usuarios de hace en un solo equipo,
en el servidor, no en todos los clientes ligeros
La incorporacin de nuevos usuarios es inmediata.
Seguridad alta, por tener una administracin centralizada.



Podemos terminar recalcando que la computacin centralizada combinada con clientes
ligeros puede cortar dramticamente con los ciclos de inversin de hardware y software
como as tambin reducir los costos de mantenimiento y actualizaciones.
Esta combinacin tambin provee un mejor control sobre el software de aplicaciones y los
datos y reduce los problemas de los usuarios finales.





















127

5.2 Trabajos Futuros.

Las computadoras Macintosh se vuelven obsoletas ms rpidamente que las PC. Las
Actualizaciones del sistema son gratuitas por Internet pero los equipos Macintosh no
cumplen el requisito de hardware y no pueden tener acceso a esas actualizaciones y los
programas y aplicaciones tambin son muy especficos sobre que caractersticas tienen que
cumplir para poderse instalar, as es como quedan obsoletas y en desuso.





Figura 5.1 Computadoras obsoletas, cinco Power PC, dos G3 y Tres PC Pentium III.

Un buen proyecto a futuro es el hacer clientes ligeros con computadoras Macintosh,
utilizando GNU/Linux, pero con caractersticas que aproveche las computadoras
Macintosh.
Estas computadoras son silenciosas en su operacin y sus componentes son de larga
duracin siendo poco frecuente las fallas por problemas de hardware.

Otro proyecto Interesante y til a futuro es la creacin de programas que se apliquen
directamente al procesador En GNU/Linux, y disminuyan el consumo de energa del
procesador cuando no sea utilizado al 100 %.

128




Figura 5.2. Computadoras obsoletas en el centro de cmputo del IIA
9
.



9
Instituto de Investigaciones Antropolgicas UNAM.
129
ANEXO 1

Cdigo empleado para la programacin de la interfaz grfica en
Lenguaje de Programacin Visual GAMBAS

Cdigo que nos permite seleccionar el tipo de servicio de conexin.

Text = ("Protocolo de Conexion")

{ RadioButton1 RadioButton

Move(42,21,112,21)

Text = ("VNC")

Value = True

}

{ RadioButton2 RadioButton

Move(224,21,126,21)

Text = ("TerminalX")

}

{ RadioButton5 RadioButton

Move(42,49,105,21)

Text = ("RDP")

}

{ RadioButton7 RadioButton

Move(42,77,112,21)

Text = ("TelNet")

130
}

{ RadioButton3 RadioButton

Move(224,49,98,21)

Text = ("SSH")

}

}

{ Frame2 Frame

Move(14,224,469,84)

Foreground = Color.Foreground

Text = ("Descripcion")

{ TextLabel3 TextLabel

Move(14,14,441,63)

Text = ("")

}

}

{ Button3 Button

Move(21,322,105,28)

Text = ("Ayuda")

Picture = Picture["icon:/32/help"]

}

}

131
Cdigo que permite seleccionar el servidor.

# Gambas Form File 2.0
{ Form Form

MoveScaled(57.1429,28.4286,52,28)

Text = ("")

Icon = Picture["icon:/32/network"]

Border = Window.Fixed

{ Frame1 Frame

MoveScaled(2,2,48,19)

Text = ("Configuracion")

{ Label1 Label

MoveScaled(2,3,19,3)

Text = ("Direccion del sevidor:")

}

{ TextBox1 TextBox

MoveScaled(22,3,24,3)

ToolTip = ("Ejemplo: 198.256.35.2")

Text = ("0.0.0.0")

}

{ Label2 Label

MoveScaled(3,7,18,3)

Text = ("Nombre de usuario:")

}

{ TextBox2 TextBox

132
MoveScaled(22,7,24,3)

Text = ("")

}

{ Label3 Label

MoveScaled(11,11,10,3)

Text = ("Escritorio:")

}

{ TextBox3 TextBox

MoveScaled(22,11,6,3)

Text = ("")

}

{ Label4 Label

MoveScaled(13,15,7,3)

Text = ("Puerto:")

}

{ TextBox4 TextBox

MoveScaled(22,15,6,3)

Text = ("")

}

}

{ Button1 Button

MoveScaled(18,23,15,3)

Text = ("Conectar")

133
Picture = Picture["icon:/32/connect"]

}

{ Button2 Button

MoveScaled(35,23,15,3)

Text = ("Cancelar")

Picture = Picture["icon:/32/cancel"]

}

}

134

Cdigo en el cual se presenta una forma al usuario con informacin con ayuda para
realizar una conexin satisfactoria.

# Gambas Form File 2.0

{ Form Form

MoveScaled(38.8889,19.8889,85,51)

Text = ("Ayuda Idefix")

{ TextArea1 TextArea

MoveScaled(1,3,83,41)

Text = ("Ayuda de Idefix\n\nPara establecer una conexi\xC3\xB3n siga los siguientes
pasos:\n 1. En la ventana principal seleccione el protocolo de acceso.\n 2. Haga clic sobre el
boton configurar.\n 3. Asigne la direccion del servidor o escritorio.\n 4. Proporcione la
informacion adicional segun sea el caso.\n 5. Clic en Conectar")

}

{ Acerca Button

MoveScaled(48,46,16,3)

Text = ("Acerca de ..")

}

{ Button2 Button

MoveScaled(67,46,15,3)

Text = ("Cerrar")

Picture = Picture["icon:/32/cancel"]

}

}


135
Cdigo que permite seleccionar el protocolo de conexin.
' Gambas class file
STATIC PRIVATE boton AS String
STATIC PUBLIC opcion AS String

PUBLIC SUB Form_Open()

END

PUBLIC SUB Form_Close()
Fmain.Hide()
END

PUBLIC SUB Button1_Click() 'configurar
config.Show()
END

PUBLIC SUB RadioButton1_Click()
'configuracion vnc

TextLabel3.Text = "Virtual Network Computing es un control de acceso remoto que
permite ver e interactuar plenamente con una computadora (Servidor VNC), usando un
simple programa (cliente VNC) en otra computadora desktop en cualquier lugar."

opcion = 1
END

PUBLIC SUB RadioButton3_Click()
TextLabel3.Text = "Secure SHell"
opcion = 2
END

PUBLIC SUB RadioButton5_Click()

TextLabel3.Text = "Rdesktop is an open source client for Windows Terminal Services,
capable of natively speaking Remote Desktop Protocol (RDP) in order to present the user's
Windows desktop."
opcion = 3
END


PUBLIC SUB RadioButton7_Click()
opcion = 4
TextLabel3.Text = "TELecommunication NETwork"
END

136
PUBLIC SUB Button2_Click() 'CANCELAR
ME.Close()
END

PUBLIC SUB RadioButton2_Click()
opcion = 5
TextLabel3.Text = "TerminalX"
END

PUBLIC SUB RadioButton1_DblClick()
opcion = 1
config.Show()
END

PUBLIC SUB RadioButton5_DblClick()
opcion = 3
config.Show()
END

PUBLIC SUB RadioButton7_DblClick()
opcion = 4
config.Show()
END

PUBLIC SUB RadioButton2_DblClick()
opcion = 5
config.Show()
END

PUBLIC SUB RadioButton3_DblClick()
opcion = 2
config.Show()

END

PUBLIC SUB Button3_Click()
help.Show()
END

PUBLIC SUB TextLabel3_MouseDown()
END

PUBLIC SUB TrayIcon1_Menu()
END

137
' Gambas class file
STATIC PUBLIC textshell AS String

PUBLIC SUB Form_Close()
FMain.Show()
config.Close()
END

PUBLIC SUB Form_Open()
SELECT CASE FMain.opcion
CASE 1 'VNC servidor, ecritorio
FMain.Hide()
config.Text = "Configuracion para VNC"
TextBox2.Enabled = FALSE
TextBox4.Enabled = FALSE
Label2.Enabled = FALSE
label4.Enabled = FALSE

CASE 2 'ssh
FMain.Hide()
config.Text = "Configuracion para SSH"
TextBox3.Enabled = FALSE
TextBox4.Enabled = FALSE
Label3.Enabled = FALSE
label4.Enabled = FALSE

CASE 3 'rdesktop
FMain.Hide()
config.Text = "Configuracion para RDesktop"
Label2.Enabled = FALSE

TextBox2.Enabled = FALSE
TextBox3.Enabled = FALSE
TextBox4.Enabled = FALSE
Label2.Enabled = FALSE
Label3.Enabled = FALSE
label4.Enabled = FALSE

CASE 4 'telnet
FMain.Hide()

config.Text = "Configuracion para TelNet"
TextBox2.Enabled = FALSE
TextBox3.Enabled = FALSE
Label2.Enabled = FALSE
Label3.Enabled = FALSE

138


CASE 5 'terminalx
FMain.Hide()
config.Text = "Configuracion para TerminalX"
TextBox2.Enabled = FALSE
TextBox4.Enabled = FALSE
Label2.Enabled = FALSE
label4.Enabled = FALSE

CASE ELSE
PRINT "ERROR"
END SELECT
END

PUBLIC SUB Button1_Click()
SELECT CASE FMain.opcion
CASE 1 'VNC servidor, ecritorio
textshell = "xvnc4viewer " & TextBox1.Text & ":" & TextBox3.Text

CASE 2 'ssh
textshell = "ssh " & TextBox2.text & "@" & TextBox1.text

CASE 3 'rdesktop
textshell = "rdesktop " & TextBox1.Text

CASE 4 'telnet
textshell = "telnet " & TextBox1.text & " " & TextBox4.text

CASE 5 'terminalx
textshell = "X :" & TextBox3.Text & " -query " & TextBox1.Text

CASE ELSE
PRINT "ERROR"
END SELECT

SHELL textshell
FMain.Show()
Form_Close()
END

PUBLIC SUB Button2_Click()
Form_Close()

END


139
Referencias.

[1] Joseph Sinclair and Mark Mekow.
20003 Thin Client (Cleary expplanned).

[2] M.L. Liu
2007 Computacin Distribuida, fundamentos y aplicaciones.

[3] Colouris G.
2001 Sistemas Distribuidos.

[4] Andrews. Ptanenbaum
2002 Redes de computadoras.

[5] Vicente Lpez Camacho
2002 Linux Gua de instalacin y administracin.

[6] ngel Lpez Alejandro Novo
2007 Protocolos de Internet, Diseo e implementacin.

[7] John Lombardo
2002 Linux incrustado.

[8] Kart Wall et al.
2004 Programacin en Linux.

[9] Daniel Campos Jos Luis Redrego.
2004 Gambas. Programacin visual con Software Libre.

[10] Craig Zacker
2002 Manual de referencia Redes.

[11] Clonen C. Lonvick
2006 The Secure Shell (SSH) Protocol Architecture.

[12] Olaf Kirch, Terry Dawson.
2002 Gua de Administracin de Redes con Linux.

[13] Mako Hill, Brnjamin, Bacon, Jono, Berger Corey
2007 Libro official de ubuntu.

[14] Red Hat Linux 7.3: Manual oficial de referencia de Red Hat Linux

[15] Stallings, W.
2003 Cryptography and Network Security, Principles and Practice,
3rd ed. Upper Saddle River: Prentice Hall.
140
[16] Harvey. M. Deitel.
1998 Introduccin a los Sistemas Operativos. Editorial Addison Wessley

[17] Gibbs Mark.
1997 Redes Para Todos. Editorial Prentice Hall

[18] Travis Dewire Dawn.
1998 Client/Server Computing. Editorial Mc Graw-Hill

[19] Molina, F.J.
2004 Instalacin y mantenimiento de servicios de redes locales. RA-MA

[20] Molina, F.J.
2006 Instalacin y Mantenimiento de Servicios de Internet. Ra-Ma

[21] Heywood Drew.
1999 Redes con Microsoft TCP/IP. PRENTICE HALL,

[22] Gonzlez Fernndez. Jonathan
1998 Teora de Redes Informticas.

[23] Amenta Gabriela, Navarro Gustavo, 2004 Manual del Usuario: Redes y
Comunicaciones Electronicas, CLACSO

[24] W. Richard Stevens
1994 TCP/IP Illustrated, Volume 1 Addison-Wesley

[25] De Krol / OReilly & Associates, Inc.
2002 Conctate al Mundo de Internet Editorial Mc Graw Hill

[26] Mrquez Garca Francisco
1993 Manuel UNIX. Programacin Avanzada. RA-MA