UNIVERSIDAD TECNICA DE MACHALA

ESCUELA DE INFOMATICA

MANUAL DE PROGRAMACION II

ALUMNA:

TATIANA MEDINA

DOCENTE:

ING. RAMIRO QUEZADA

QUIMESTRE:

8VO. QUIMESTRE ´Aµ

AÑO LECTIVO

2010-2011
Unidad 1. IDENTIFICACIÓN DEL LENGUAJE DE PROGRAMACIÓN

1.1.V FAMILIARIZACION CON EL LENGUAJE DE PROGRAMACION

La plataforma NetBeans permite que las aplicaciones sean desarrolladas a partir de un conjunto
de componentes de software llamados módulos. Un módulo es un archivo Java que contiene
clases de java escritas para interactuar con las APIs de NetBeans y un archivo especial (manifest
file) que lo identifica como módulo. Las aplicaciones construidas a partir de módulos pueden ser
extendidas agregándole nuevos módulos. Debido a que los módulos pueden ser desarrollados
independientemente, las aplicaciones basadas en la plataforma NetBeans pueden ser extendidas
fácilmente por otros desarrolladores de software.

CREANDO UN PROYECTO:

Para seguir conociendo a fondo nuestro IDE empezaremos creando un proyecto el cual nos ayudara
para ver las demás herramientas las cuales podremos utilizar más adelante en proyectos más
complejos. Para crear un proyecto primero tenemos que darle:

1.V Clic en el menú/ File

2.V New Project. o Seleccionando el icono

yV Menú de Proyecto Nuevo

3.V Ahora seleccionamos el tipo de proyecto

Escogemos Java. Java Aplication. Ya que deseamos crear un

proyecto de escritorio.

Presionamos el botón siguiente.

yV Ahora le damos el nombre al proyecto

Presionamos el botón FINISH

 yV El IDE genera la estructura del proyecto

yV Se crea la clase principal

Por el momento nuestro proyecto no hace nada pero si queremos empezar a trabajar podemos
hacer el famoso hola mundo luego de poner este código.

System.out.println(´hola mundoµ);

Para correr nuestro proyecto, tenemos que dar un clic en nuestro icono color verde que está en
nuestra barra de accesos directos, con esto podemos corremos nuestro proyecto. Y nos quedaría así
fíjense bien en nuestro output en esa parte tendremos el resultado de nuestro pequeño ejemplo.

Cuando esté escribiendo código Java, debería saber que Java reserva ciertas palabras clave como
parte del lenguaje. No hay muchas, de cualquier modo.
yV abstract: Especifica la clase o método que se va a implementar más tarde en una subclase.
yV boolean: Tipo de dato que sólo puede tomar los valores verdadero o falso.
yV Vreak: Sentencia de control para salirse de los Vucles.
yV V te: Tipo de dato que soporta valores en 8 Vits.
yV V
alue: Reser
ada para uso futuro.
yV case: Se utiliza en las sentencias switch para indicar bloques de texto.
yV cast: Reservada para uso futuro.
yV catch: Captura las excepciones generadas por las sentencias tr .
yV char: Tipo de dato que puede soportar caracteres Unicode sin signo en 16 bits.
yV class: Declara una clase nueva.
yV const: Reservada para uso futuro.
yV continue: Devuelve el control a la salida de un bucle.
yV ° fault: In°ica l bloqu ° có°igo por ° f cto n una s nt ncia switch.
yV °
 Inicia un bucle °
hile.
yV °
uVl  Tip
° °at
qu s
p
rta núm r
s n c
ma fl
tant , 64 Vits.
yV ls  Indica la opción alt rnativa n una s nt ncia if.
yV t n° In°ica qu una cla  ° riva°a ° otra o ° una int rfaz.
yV final Indica que una variable soporta un valor constante o que un método no se
sobrescribirá.
yV finall  Indica un bloque de código en una estructura tr - catch que siempre se ejecutará.
yV fl
at Tip
de dat
que s
p
rta un númer
en c
ma fl
tante en 32 bits.
yV f
r Utilizad
para iniciar un bucle f
r.
yV futur  R s rvada para uso futuro.
yV Ò n ric R s rvada para uso futuro.
yV Ò
t
 Reservada para us
futur
.
yV =f Evalúa s= una expres= n es verdadera o falsa y la d=r=ge adecuadamente.
yV =
pl
nt Ep c=f=ca qu una cla =
pl
nta una =nt rfaz.
yV =
p
rt Referenc=a a
tras clases.
yV =nn r R s rvada para uso futuro.
yV =ntanc
f Ind=ca = un
bj t
 una =ntanc=a d una cla p cíf=ca
=mpl m nta una
=nt rfaz p cíf=ca.
yV =nt T=po de dato que puede soportar un entero con s=gno de 32 b=ts.
yV =nt rfac  D clara una =nt rfaz.
yV l
nÒ Tip
de dat
que s
p
rta un enter
de 64 bits.
yV nat=
 Esp c=f=ca qu un método stá =mpl m ntado con c d=go nat=
o ( sp cíf=co d la
plataforma).
yV n  Cr a obj tos nu vos.
yV null Indica que una referencia no se refiere a nada.
yV
p rat
r R s rvad
para us
futur
. .
yV
ut r R s rvad
para us
futur
.
yV packaÒ  D clara un paqu t Java.
yV pr=
at  Esp c=f=cador d acc so qu =nd=ca qu un método o
ar=abl s lo pu d s r
acc s=bl d sd la clas n la qu stá d clarado.
yV pr
t ct ° Esp cifica°
r ° acc s
qu in°ica qu un mét
°

variabl s l
pu ° s r
acc sibl ° s° la clas n la qu stá ° clara°
(
una subclas ° la clas n la qu stá
° clara°a u
tras clas s ° l mism
paqu t ).
yV puVl=c Espec=f=cador de acceso ut=l=zado para clases, =nterfaces, métodos y var=aVles que
=nd=can que un tema es acces=Vle desde la apl=cac= n (o desde donde la clase def=na que es
acces=Vle).
yV r t R  rvada para uo futuro.
yV r turn Envía control posibl m nt d vu lv un valor d sd l método qu fu invocado.
yV h
rt Tip
de dat
que puede 
p
rtar un enter
de 16 bit.
 yV tat=c Ind=ca que una var=able o método e un método de una clae (má que etar l=m=tado
a un objeto part=cular).
yV up r S r fi r a una cla ba d la cla (utilizado n un método o contructor d cla ).
yV =tch Sentenc=a que ejecuta c d=go baándoe en un valor.
yV synchronized: Especifica secciones o métodos críticos de c digo multihilo.
yV this: Se refiere al objeto actual en un método o constructor
yV throw: Crea una excepci n.
yV throws: Indica qué excepciones puede proporcionar un método,
yV transient: Especifica que una variable no es parte del estado persistente de un objeto.
yV tr  Inicia un bloque de c digo que es comprobado para las excepciones.
yV var: Reservado para uso futuro.
yV void: Especifica que un método no devuelve ningún valor.
yV volatile: Indica que una variable puede cambiar de forma asíncrona.
yV while: Inicia un bucle while.

Herencia:
Parece una pena, sin embargo, acometer todo el problema para crear una clase y
posteriormente BASE
verse forzado a crear una nueva que podría tener una funcionalidad similar. Sería
mejor si pudiéramos hacer uso de una clase ya existente, clonarla, y después hacer al
"clon" las adiciones y modificaciones que sean necesarias. Efectivamente, esto se logra
mediante la herencia, con la excepci n de que si se cambia la clase original DERIVADA
(denominada la clase base, clase super o clase padre), el "clon" modificado
(denominado clase derivada, clase heredada, subclase o clase hijo) también reflejaría esos cambios.

1.2.VAPLICACIONES GUI

Dentro de Java hay una serie de paquetes destinados a la creaci n de aplicaciones con un Interface

Gráfico de Usuario, es decir, son aplicaciones compuestas de ventanas, menús que se pueden
desplegar, iconos para las distintas funciones, sonidos, etc.

En definitiva, con la GUI se pueden hacer una aplicaci n como las

que estamos acostumbrados a ver habitualmente.

JFC son la siglas para las Clases de la Fundaci n de JavaTM, que

engloban un grupo de características para ayudar a construir los
Interfaces Gráficos de los Usuarios en las aplicaciones (GUIs).Las
clases de la fundaci n de Java (JFC) son un sistema de bibliotecas
de clases que Java proporciona, como parte de J2SE, al interfaz
utilizador de los gráficos (GUI) para dar funcionalidad a los
gráficos y para los diferentes usos que se puedan dar en las
tecnologías basadas en Java del cliente.

Es muy común a la hora de crear aplicaciones de escritorios querer

utilizar formularios que interactúen con los usuarios. Claro esto
hace que tu aplicaci n sea amigable y querida por los mismos. Java provee un paquete llamado
.swing que agrupa componentes ya definidos y que serán de mucha utilidad para el programador a
la hora de diseñar nuestras aplicaciones; en la Figura 1 se observa un formulario creado con
componentes swing.
PARTE I: DISEÑO LA GUI
Primero debemos ingresar al NetBeans, vamos a crear un nuevo proyecto, ingresando al menú File ²
New Project, tal como se observa en la Figura 2,

Aquí nos mostrará el cuadro de dialogo New Project,

seleccionamos la categoría General y como proyecto Java
Aplication, tal como se observa en la Figura 3.

Dentro de este nuevo proyecto vamos a insertar un JFrame del

componente Swing, pulsamos
clic derecho en el paquete luego seleccionamos la opci n New, y
finalmente seleccionamos del
submenú la opci n JFrame Form, tal como se observa en la Figura

Ahora nos encontramos dentro del entorno del paquete java. Swing, un ambiente muy amigable,
que no tiene nada que envidiar a otros leguajes visuales. La figura muestra las partes del entorno.
1.3.VFLUJOS

Los flujos surgen por la necesidad de las aplicaciones Java de interaccionar con el exterior de dos
posibles formas:

yV Generando salida a la consola del DOS, a un fichero, etc.

yV Capturando datos procedentes del teclado, de ficheros, de páginas web, etc.
Concepto de flujo: es como un río. El agua en movimiento es el flujo, su contenido son los datos. Lo
que permite que esos datos viajen de un origen a un destino es el agua en movimiento, es decir, el
flujo. En el caso de la captura, desde un programa Java, de datos introducidos por un usuario
mediante teclado, el origen es el teclado, el destino, el programa Java y los datos, lo tecleado por el
usuario.
Java modela flujos mediante clases del paquete java.io. Este paquete se estudiará más adelante, por
el momento se va a explicar c mo una aplicaci n Java captura datos introducidos por el usuario a
través del teclado y c mo realiza todo tipo de operaciones sobre los mismos.

Lectura

Las clases Reader e InputStream son similares aunque se refieren a distintos tipos de datos, lo mismo
ocurre con Writer y OutputSream.

Escritura

La clase Writer proporciona tres métodos para escribir un carácter char o un array de caracteres

int write(int c)
int write(char buf[])
int write(char buf[], int offset, int len)

La clase OutputStream proporciona métodos similares

int write(int c)
int write(byte buf[])
int write(byte buf[], int offset, int len)
1.4.VPROGRAMACION

Variables y Tipos de Datos

Las variables son las partes importantes de un lenguaje de programaci n: ellas son las entidades
(valores, datos) que actúan y sobre las que se actúa.
Una declaraci n de variable siempre contiene dos componentes, el tipo de la variable y su nombre.
tipoVariable nombre;

Tipos de Variables
Todas las variables en el lenguaje Java deben tener un tipo de dato. El tipo de la variable determina
los valores que la variable puede contener y las operaciones que se pueden realizar con ella.
Existen dos categorías de datos principales en el lenguaje Java: los tipos primitivos y los tipos
referenciados.
Los tipos primitivos contienen un s lo valor e incluyen los tipos como los enteros, coma flotante, los
caracteres, etc... La tabla siguiente muestra todos los tipos primitivos soportados por el lenguaje Java,
su formato, su tamaño y una breve descripci n de cada uno.

Tipo Tamaño/Formato Descripci n

(Números
enteros)
8-bit Entero de un
byte
complemento a 2 Byte
16-bit
short Entero corto
complemento a 2
32-bit
int Entero
complemento a 2
64-bit
long Entero largo
complemento a 2
(Números reales)
Coma flotante de
float 32-bit IEEE 754
precisi n simple
Coma flotante de
double 64-bit IEEE 754
precisi n doble
(otros tipos)
char 16-bit Carácter Un s lo carácter
Un valor
booleano
boolean true o false
(verdadero o
falso)

Los tipos referenciados se llaman así porque el valor de una variable de referencia es una referencia
(un puntero) hacia el valor real. En Java tenemos los arrays, las clases y los interfaces como tipos de
datos referenciados.

Nombres de Variables
Un programa se refiere al valor de una variable por su nombre. Por convenci n, en Java, los
nombres de las variables empiezan con una letra minúscula (los nombres de las clases empiezan con
una letra mayúscula).
Un nombre de variable Java.
1.V debe ser un identificador legal de Java comprendido en una serie de caracteres Unicode. Unicode
es un sistema de codificaci n que soporta texto escrito en distintos lenguajes humanos. Unicode
permiten la codificaci n de 34.168 caracteres. Esto le permite utilizar en sus programas Java
varios alfabetos como el japonés, el griego, el ruso o el hebreo. Esto es importante para que los
programadores pueden escribir c digo en su lenguaje nativo.
2.V no puede ser el mismo que una palabra clave o el nombre de un valor booleano (true or false)
3.V no deben tener el mismo nombre que otras variables cuyas declaraciones aparezcan en el mismo
ámbito.
La regla número 3 implica que podría existir el mismo nombre en otra variable que aparezca en un
ámbito diferente.
Por convenci n, los nombres de variables empiezan por una letra minúscula. Si una variable está
compuesta de más de una palabra, como 'nombreDato' las palabras se ponen juntas y cada palabra
después de la primera empieza con una letra mayúscula.

Operadores Aritméticos
El lenguaje Java soporta varios operadores aritméticos - incluyendo + (suma), - (resta), *
(multiplicaci n), / (divisi n), y % (m dulo)-- en todos los números enteros y de coma flotante. Por
ejemplo, puedes utilizar este c digo Java para sumar dos números:
Suma Esto + a Esto
O este c digo para calcular el resto de una divisi n:
Divide Esto % por Esto
Esta tabla sumariza todas las operaciones aritméticas binarias en Java.
Operador Uso Descripci n
+ op1 + op2 Suma op1 y op2
- op1 - op2 Resta op2 de op1
* op1 * op2 Multiplica op1 y op2
/ op1 / op2 Divide op1 por op2
% op1 % op2 Obtiene el resto de dividir op1 por op2
Nota: El lenguaje Java extiende la definici n del operador + para incluir la concatenaci n de
cadenas.
Los operadores + y - tienen versiones unarias que seleccionan el signo del operando.
Operador Uso Descripci n
Indica un
+ + op valor
positivo
Niega el
- - op
operando
Además, existen dos operadores de atajos aritméticos, ++ que incrementa en uno su operando, y --
que decrementa en uno el valor de su operando.
Operador Uso Descripci n
++ op ++ Incrementa op en 1; evalúa el valor antes de incrementar
++ ++ op Incrementa op en 1; evalúa el valor después de incrementar
-- op -- Decrementa op en 1; evalúa el valor antes de decrementar
-- -- op Decrementa op en 1; evalúa el valor después de decrementa
UNIDAD 2: INTRODUCCION DE REDES.

En su nivel más elemental, una red de equipos consiste en dos equipos conectados entre sí con un
cable que les permite compartir datos. Todas las redes de equipos, independientemente de su nivel
de sofisticaci n, surgen de este sistema tan simple. Aunque puede que la idea de conectar dos
equipos con un cable no parezca extraordinaria, al mirar hacia atrás se comprueba que ha sido un
gran logro a nivel de comunicaciones.

Las redes de equipos surgen como respuesta a la

necesidad de compartir datos de forma rápida. Los
equipos personales son herramientas potentes que
pueden procesar y manipular rápidamente grandes
cantidades de datos, pero no permiten que los
usuarios compartan los datos de forma eficiente.

En ocasiones, al proceso de copiar archivos en

disquetes y dárselos a otras personas para copiarlos en
sus equipos se le denomina «red de alpargata»
(sneakernet). Esta antigua versi n de trabajo en red la
hemos usado muchos de nosotros, y puede que
sigamos usándola actualmente.

Este sistema funciona bien en ciertas situaciones, y presenta sus ventajas (nos permite tomar un café o
hablar con un amigo mientras intercambiamos y combinamos datos), pero resulta demasiado lento e
ineficiente para cubrir las necesidades y expectativas de los usuarios informáticos de hoy en día. La
cantidad de datos que se necesitan compartir y las distancias que deben cubrir los datos superan con
creces las posibilidades del intercambio de disquetes.

Esta interconexi n de equipos y otros dispositivos se llama una red.

yV El concepto de conectar equipos que comparten recursos es un sistema de red.

¿Por qué usar una red?

yV Las redes aumentan la eficiencia y reducen los costos.

yV Las tres razones principales son:

ÈV Compartir informaci n o datos

ÈV Compartir hardware o software.
ÈV Centralizar la administraci n y el apoyo.

Compartir informaci n o datos

yV Al hacer que la informaci n esté disponible para compartir las redes pueden reducir la
necesidad de comunicaci n por escrito, aumenta la eficiencia y hace que cualquier tipo de
dato esté disponible simultáneamente para cualquier usuario que lo necesite.
 Configuraci n de Redes

yV La configuraci n de los equipos de la red y la forma en que comparten la informaci n

determina si la red es ´peer-to-peerµ o basada en servidor.

yV En general todas las redes tienen ciertos componentes, funciones y características comunes,
estos incluyen:

KV Tamaño de la Organizaci n

KV Nivel de seguridad requerido

KV Tipo de negocio

KV Nivel de apoyo administrativo disponible

KV Cantidad de tráfico en la red

KV Necesidades de los usuarios de la red

KV Presupuesto de la red

Topologías más Comunes

Bus: Esta topología permite que todas las estaciones reciban la

informaci n que se transmite, una estaci n transmite y todas las restantes
escuchan. Consiste en un cable con un terminador en cada extremo del
que se cuelgan todos los elementos de una red. Todos los nodos de la red
están unidos a este cable: el cual recibe el nombre de "Backbone Cable".
Tanto Ethernet como Local Talk pueden utilizar esta topología.

Anillo: Las estaciones están unidas unas con otras formando un círculo
por medio de un cable común. El último nodo de la cadena se conecta al
primero cerrando el anillo. Las señales circulan en un solo sentido
alrededor del círculo, regenerándose en cada nodo. Con esta
metodología, cada nodo examina la informaci n que es enviada a través
del anillo. Si la informaci n no está dirigida al nodo que la examina, la
pasa al siguiente en el anillo. La desventaja del anillo es que si se rompe una conexi n, se cae la red
completa.

Estrella: Los datos en estas redes fluyen del emisor hasta el concentrador, este realiza todas las
funciones de la red, además actúa como amplificador de los datos.

La red se une en un único punto, normalmente con un panel de control centralizado, como un
concentrador de cableado. Los bloques de informaci n son dirigidos a través del panel de control
central hacia sus destinos. Este esquema tiene una ventaja al tener un panel de control que monitorea
el tráfico y evita las colisiones y una conexi n interrumpida no afecta al resto de la red.
2.2. MODELO OSI Y TCP/IP

Modelo de referencia OSI

Siguiendo el esquema de este modelo se crearon numerosos

protocolos. El advenimiento de protocolos más flexibles donde las
capas no están tan demarcadas y la correspondencia con los niveles no
era tan clara puso a este esquema en un segundo plano. Sin embargo
es muy usado en la enseñanza como una manera de mostrar c mo
puede estructurarse una "pila" de protocolos de comunicaciones.
El modelo especifica el protocolo que debe ser usado en cada capa, y
suele hablarse de modelo de referencia ya que es usado como una gran
herramienta para la enseñanza de comunicaci n de redes. Este modelo
está dividido en siete capas:

Capa física (Capa 1)

Es la que se encarga de las conexiones físicas de la computadora hacia la red, tanto en lo que se
refiere al medio físico como a la forma en la que se transmite la informaci n.
Sus principales funciones se pueden resumir como:

öV Definir el medio o medios físicos por los que va a viajar la comunicaci n: cable de pares
trenzados (o no, como en RS232/EIA232), coaxial, guías de onda, aire, fibra ptica.

öV Definir las características materiales (componentes y conectores mecánicos) y eléctricas (niveles de

tensi n) que se van a usar en la transmisi n de los datos por los medios físicos.

öV Definir las características funcionales de la interfaz (establecimiento, mantenimiento y liberaci n

del enlace físico).

öV Transmitir el flujo de bits a través del medio.

öV Manejar las señales eléctricas del medio de transmisi n, polos en un enchufe, etc.

öV Garantizar la conexi n (aunque no la fiabilidad de dicha conexi n).

Capa de enlace de datos (Capa 2)
Esta capa se ocupa del direccionamiento físico, de la topología de la red, del acceso a la red, de la
notificaci n de errores, de la distribuci n ordenada de tramas y del control del flujo.
Como objetivo o tarea principal, la capa de enlace de datos se encarga de tomar una transmisi n de
datosµ crudaµ y transformarla en una abstracci n libre de errores de transmisi n para la capa de red.
Este proceso se lleva a cabo dividiendo los datos de entrada en marcos de datos (de unos cuantos
cientos de bytes), transmite los marcos en forma secuencial, y procesa los marcos de estado que envía
el nodo destino.
Capa de red (Capa 3)
El objetivo de la capa de red es hacer que los datos lleguen desde el origen al destino, aún cuando
ambos no estén conectados directamente. Los dispositivos que facilitan tal tarea se
denominan encaminadores, aunque es más frecuente encontrar el nombre inglésrouters y, en
ocasiones enrutadores. Los routers trabajan en esta capa, aunque pueden actuar como switch de nivel
2 en determinados casos, dependiendo de la funci n que se le asigne. Los firewalls actúan sobre esta
capa principalmente, para descartar direcciones de máquinas.
En este nivel se realiza el direccionamiento l gico y la determinaci n de la ruta de los datos hasta su
receptor final.
Capa de transporte (Capa 4)
Capa encargada de efectuar el transporte de los datos (que se encuentran dentro del paquete) de la
máquina origen a la de destino, independizándolo del tipo de red física que se esté utilizando.
La PDU de la capa 4 se llama Segmento o Datagrama, dependiendo de si corresponde a TCP o UDP.
Sus protocolos son TCP y UDP; el primero orientado a conexi n y el otro sin conexi n.
Capa de sesi n (Capa 5)
Esta capa es la que se encarga de mantener y controlar el enlace establecido entre dos computadores
que están transmitiendo datos de cualquier índole.
Por lo tanto, el servicio provisto por esta capa es la capacidad de asegurar que, dada una sesi n
establecida entre dos máquinas, la misma se pueda efectuar para las operaciones definidas de
principio a fin, reanudándolas en caso de interrupci n. En muchos casos, los servicios de la capa de
sesi n son parcial o totalmente prescindibles.
Capa de presentaci n (Capa 6)
El objetivo es encargarse de la representaci n de la informaci n, de manera que aunque distintos
equipos puedan tener diferentes representaciones internas de caracteres los datos lleguen de manera
reconocible.
Esta capa es la primera en trabajar más el contenido de la comunicaci n que el c mo se establece la
misma. En ella se tratan aspectos tales como la semántica y la sintaxis de los datos transmitidos, ya
que distintas computadoras pueden tener diferentes formas de manejarlas.
Esta capa también permite cifrar los datos y comprimirlos. En pocas palabras es un traductor.
Capa de aplicaci n (Capa 7)
Ofrece a las aplicaciones la posibilidad de acceder a los servicios de las demás capas y define los
protocolos que utilizan las aplicaciones para intercambiar datos, como correo
electr nico (POP y SMTP), gestores de bases de datos y servidor de ficheros (FTP), por UDP pueden
viajar (DNS y RIP). Hay tantos protocolos como aplicaciones distintas y puesto que continuamente se
desarrollan nuevas aplicaciones el número de protocolos crece sin parar.
Cabe aclarar que el usuario normalmente no interactúa directamente con el nivel de aplicaci n. Suele
interactuar con programas que a su vez interactúan con el nivel de aplicaci n pero ocultando la
complejidad subyacente.

MODELO TCP/IP

El TCP/IP es la base de Internet, y sirve para comunicar todo tipo de dispositivos, computadoras que
utilizan diferentes sistemas operativos, minicomputadoras y computadoras centrales sobre redes de
área local (LAN) y área extensa (WAN). TCP/IP fue desarrollado y demostrado por primera vez en
1972 por el departamento de defensa de los Estados Unidos, ejecutándolo en ARPANET, una red de
área extensa del departamento de defensa.
 EL MODELO TCP/IP esta compuesto por cuatro capas o niveles, cada nivel se encarga de
determinados aspectos de la comunicaci n y a su vez brinda un servicio específico a la capa superior.
Estas capas son:

Algunas de las capas del modelo TCP/IP poseen el mismo nombre que las capas del modelo OSI.
Resulta fundamental no confundir las funciones de las capas de los dos modelos ya que si bien tienen
aspectos en común, estas desempeñan diferentes funciones en cada modelo.

Capa de Aplicaci n

La capa de aplicaci n del modelo TCP/IP maneja protocolos de alto nivel, aspectos de
representaci n, codificaci n y control de diálogo. El modelo TCP/IP combina todos los aspectos
relacionados con las aplicaciones en una sola capa y asegura que estos datos estén correctamente
empaquetados antes de que pasen a la capa siguiente. TCP/IP incluye no s lo las especificaciones de
Internet y de la capa de transporte, tales como IP y TCP, sino también las especificaciones para
aplicaciones comunes. TCP/IP tiene protocolos que soportan la transferencia de archivos, e-mail, y
conexi n remota, además de los siguientes:

yV FTP (Protocolo de transferencia de archivos): es un servicio confiable orientado a conexi n que

utiliza TCP para transferir archivos entre sistemas que admiten la transferencia FTP. Permite las
transferencias bidireccionales de archivos binarios y archivos ASCII.
yV TFTP (Protocolo trivial de transferencia de archivos): es un servicio no orientado a conexi n que
utiliza el Protocolo de datagrama de usuario (UDP). Es útil en algunas LAN porque opera más
rápidamente que FTP en un entorno estable.
yV NFS (Sistema de archivos de red): es un conjunto de protocolos para un sistema de archivos
distribuido, desarrollado por Sun Microsystems que permite acceso a los archivos de un dispositivo
de almacenamiento remoto, por ejemplo, un disco rígido a través de una red.
yV SMTP (Protocolo simple de transferencia de correo): administra la transmisi n de correo electr nico
a través de las redes informáticas. No admite la transmisi n de datos que no sea en forma de texto
simple.
yV TELNET (Emulaci n de terminal): Telnet tiene la capacidad de acceder de forma remota a otro
computador. Permite que el usuario se conecte a un host de Internet y ejecute comandos. El cliente
de Telnet recibe el nombre de host local. El servidor de Telnet recibe el nombre de host remoto.
yV SNMP (Protocolo simple de administraci n de red): es un protocolo que provee una manera de
monitorear y controlar los dispositivos de red y de administrar las configuraciones, la recolecci n de
estadísticas, el desempeño y la seguridad.
yV DNS (Sistema de denominaci n de dominio): es un sistema que se utiliza en Internet para convertir
los nombres de los dominios y de sus nodos de red publicados abiertamente en direcciones IP.

Capa de Transporte
 La capa de transporte proporciona servicios de transporte desde el host origen hacia el host destino.
En esta capa se forma una conexi n l gica entre los puntos finales de la red, el host transmisor y el
host receptor. Los protocolos de transporte segmentan y reensamblan los datos mandados por las
capas superiores en el mismo flujo de datos, o conexi n l gica entre los extremos. La corriente de
datos de la capa de transporte brinda transporte de extremo a extremo.

Se suele decir que internet es una nube. La capa de transporte envía los paquetes de datos desde la
fuente transmisora hacia el destino receptor a través de la nube. El control de punta a punta, que se
proporciona con las ventanas deslizantes y la confiabilidad de los números de secuencia y acuses de
recibo, es el deber básico de la capa de transporte cuando utiliza TCP. La capa de transporte también
define la conectividad de extremo a extremo entre las aplicaciones de los hosts. Los servicios de
transporte incluyen los siguientes servicios:

Protocolos TCP Y UDP

yV Segmentaci n de los datos de capa superior

yV Envío de los segmentos desde un dispositivo en un extremo a otro dispositivo en otro extremo.

Características del protocolo TCP

yV Establecimiento de operaciones de punta a punta.

yV Control de flujo proporcionado por ventanas deslizantes.
yV Confiabilidad proporcionada por los números de secuencia y los acuses de recibo.

Se dice que internet es una nube, por que los paquetes pueden tomar múltiples rutas para llegar a su
destino, generalmente los saltos entre routers se representan con una nube que representa las
distintas posibles rutas. La capa de transporte envía los paquetes de datos desde la fuente transmisora
hacia el destino receptor a través de la nube. La nube maneja los aspectos tales como la
determinaci n de la mejor ruta, balanceo de cargas, etc.

Capa de Internet

Esta capa tiene como prop sito seleccionar la mejor ruta para enviar paquetes por la red. El
protocolo principal que funciona en esta capa es el Protocolo de Internet (IP). La determinaci n de la
mejor ruta y la conmutaci n de los paquetes ocurren en esta capa.

Protocolos que operan en la capa de internet:

yV IP proporciona un enrutamiento de paquetes no orientado a conexi n de máximo esfuerzo. El IP no

se ve afectado por el contenido de los paquetes, sino que busca una ruta de hacia el destino.
yV ICMP, Protocolo de mensajes de control en Internet suministra capacidades de control y envío de
mensajes.
yV ARP, Protocolo de resoluci n de direcciones determina la direcci n de la capa de enlace de datos, la
direcci n MAC, para las direcciones IP conocidas.
yV RARP, Protocolo de resoluci n inversa de direcciones determina las direcciones IP cuando se conoce
la direcci n MAC.

Funciones del Protocolo IP

‡ Define un paquete y un esquema de direccionamiento.

‡ Transfiere los datos entre la capa Internet y las capas de acceso de red.
‡ Enruta los paquetes hacia los hosts remotos.

A veces, se considera a IP como protocolo poco confiable. Esto no significa que IP no enviará
correctamente los datos a través de la red. Llamar al IP, protocolo poco confiable simplemente
significa que IP no realiza la verificaci n y la correcci n de los errores. De esta funci n se encarga
TCP, es decir el protocolo de la capa superior ya sea desde las capas de transporte o aplicaci n.

Capa de Acceso de Red

También denominada capa de host de red. Esta es la capa que maneja todos los aspectos que un
paquete IP requiere para efectuar un enlace físico real con los medios de la red. Esta capa incluye los
detalles de la tecnología LAN y WAN y todos los detalles de las capas físicas y de enlace de datos del
modelo OSI.

Los controladores para las aplicaciones de software, las tarjetas de m dem y otros dispositivos
operan en la capa de acceso de red. La capa de acceso de red define los procedimientos para realizar
la interfaz con el hardware de la red y para tener acceso al medio de transmisi n. Los estándares del
protocolo de los m dem tales como el Protocolo Internet de enlace serial (SLIP) y el Protocolo de
punta a punta (PPP) brindan acceso a la red a través de una conexi n por m dem. Debido a un
intrincado juego entre las especificaciones del hardware, el software y los medios de transmisi n,
existen muchos protocolos que operan en esta capa. Esto puede generar confusi n en los usuarios. La
mayoría de los protocolos reconocibles operan en las capas de transporte y de Internet del modelo
TCP/IP.

Son funciones de esta capa: la asignaci n de direcciones IP a las direcciones físicas, el

encapsulamiento de los paquetes IP en tramas. Basándose en el tipo de hardware y la interfaz de la
red, la capa de acceso de red definirá la conexi n con los medios físicos de la misma.

Comparaci n del Modelo TCP/IP con el Modelo OSI

2.3. ARQUITECTURA CLIENTE ² SERVIDOR

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa
(el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan
sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a
través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque
son más importantes las ventajas de tipo organizativo debidas a la centralizaci n de la gesti n de la
informaci n y la separaci n de responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separaci n entre cliente y servidor es una separaci n de tipo l gico, donde el servidor no se
ejecuta necesariamente sobre una sola máquina ni es necesariamente un
s lo programa. Los tipos específicos de servidores incluyen los
servidores web, los servidores de archivo, los servidores del correo, etc.
Mientras que sus prop sitos varían de unos servicios a otros, la
arquitectura básica seguirá siendo la misma.
Una disposici n muy común son los sistemas multicapa en los que el
servidor se descompone en diferentes programas que pueden ser
ejecutados por diferentes computadoras aumentando así el grado de
distribuci n del sistema.
La arquitectura clienteservidor sustituye a la arquitectura monolítica en la
que no hay distribuci n, tanto a nivel físico como a nivel l gico.
La red clienteservidor es aquella red de comunicaciones en la que todos los clientes están conectados
a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que
los pone a disposici n de los clientes cada vez que estos son solicitados. Esto significa que todas las
gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los
requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público
y los que son de uso restringido, los archivos que son de s lo lectura y los que, por el contrario,
pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se este
utilizando en una red mixta.

Características

En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:

öV Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicaci n
(dispositivo maestro o amo).
öV Espera y recibe las respuestas del servidor.
öV Por lo general, puede conectarse a varios servidores a la vez.
öV Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de
usuario.
öV Al contratar un servicio de redes, se tiene que tener en la velocidad de conexi n que le otorga al
cliente y el tipo de cable que utiliza, por ejemplo: cable de cobre ronda entre 1 ms y 50 ms.
Al receptor de la solicitud enviada por cliente se conoce como servidor. Sus características son:

öV Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel
pasivo en la comunicaci n (dispositivo esclavo).
öV Tras la recepci n de una solicitud, la procesan y luego envían la respuesta al cliente.
öV Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número
máximo de peticiones puede estar limitado).
öV No es frecuente que interactúen directamente con los usuarios finales.

UNIDAD 3: SOCKETS

3.1. INTRODUCCION.
Las aplicaciones desarrolladas en Sockets están basadas en la arquitectura Cliente Servidor. La
aplicaci n necesita conocer el papel que va a desempeñar (cliente o servidor) ya que la estructura del
sw y primitivas difieren.

Permiten comunicaciones orientadas a conexi n o sin conexi n.

Un socket está completamente definido cuando consta de direcci n y puerto (ej. IP+puerto TCP)
3.2. MODELO DE COMUNICACIONES

ÈV InputStr a
/
OutputStr a

Ah
ra n cli nt t n

s la c
n xi n c
n l cli nt (valga la r dundancia). L
únic
qu t n

s
qu hac r s
bt n r d él l OuputStr a

InputStr a
c
n l
s
ét
d
s g tOutputStr a
()

g tInputStr a
(). La clas OutpuStr a
n
s sirv para nviarl dat
s al cli nt . La clas InputStr a

n
s sirv para l r dat
s d l cli nt .

yV InputStream entrada = cliente.getIntputStream();

yV OutputStream salida = cliente.getOutputStream();

Construirnos un InputStream y/o un OutputStream más adecuados a nuestras necesidades

Los métodos de estas dos clases para leer o escribir datos son un poco feos, ya que únicamente
envían bytes. Suele ser habitual construir alguna otra clase de entrada/salida de datos que tenga
métodos más adecuados:

yV Si queremos enviar o recibir tipos normales (enteros, flotantes, strings) tenemos las clases
DataInputStream y DataOutputStream. Estas clases tienen un constructor que admite un
InputStream y un OutputStream respectivamente.

DataInputStream entradaDatos = new DataInputStream (entrada);

DataOuputStream salidaDatos = new DataOutputStream (salida);

yV Si queremos enviar o recibir clases enteras propias nuestras, tenemos las clases
ObjectInputStream y ObjectDataStream. Al igual que las anteriores, usaremos el constructor
que admite un InputStream y un OutputStream

ObjectInputStream entradaObjetos = new ObjectInputStream (entrada);

ObjectOutputStream salidaObjetos = new ObjectOutputStream (salida);

Estas nuevas clases tienen métodos más bonitos de usar (writeInt(), writeChar(), etc)

3.2. MODELO DE COMUNICACIONES

El modelo de sockets más simple es:

· El servidor establece un puerto y espera durante un

cierto tiempo (timeout segundos), a que el cliente
establezca la conexi n. Cuando el cliente solicite una
conexi n, el servidor abrirá la conexi n socket con el
método accept().
· El cliente establece una conexi n con la máquina host a través del puerto que se designe en puerto#

· El cliente y el servidor se comunican con manejadores InputStream OutputStream

´ ´






 

V
Si estamos programando un //cliente//, el socket se abre de la forma:

Socket miCliente;
miCliente = new Socket ( "maquina",numeroPuerto );

Donde ##maquina## es el nombre de la máquina en donde estamos intentando abrir la conexi n y

##numeroPuerto## es el puerto (un número) del servidor que está corriendo sobre el cual nos
queremos conectar. Cuando se selecciona un número de puerto, se debe tener en cuenta que los
puertos en el rango 0-1023 están reservados para usuarios con muchos privilegios (//superusuarios//
o //root//). Estos puertos son los que utilizan los servicios estándar del sistema como //email//, //ftp//
o //http//. Para las aplicaciones que se desarrollen, asegurarse de seleccionar un puerto por encima
del 1023.

En el ejemplo anterior no se usan excepciones; sin embargo, es una gran idea la captura de
excepciones cuando se está trabajando con sockets. El mismo ejemplo quedaría como:

Socket miCliente;
try {
miCliente = new Socket( "maquina",numeroPuerto );
} catch( IOException e ) {
System.out.println( e );
}

Si estamos programando un //servidor//, la forma de apertura del socket es la que muestra el

siguiente ejemplo:

Socket miServicio;
try {
miServicio = new ServerSocket( numeroPuerto );
} catch( IOException e ) {
System.out.println( e );
}

A la hora de la implementaci n de un servidor también necesitamos crear un objeto socket desde el

ServerSocket para que esté atento a las conexiones que le puedan realizar clientes potenciales y
poder aceptar esas conexiones:

Socket socketServicio = null;

try {
socketServicio = miServicio.accept();
} catch( IOException e ) {
System.out.println( e );
}
V
Siempre deberemos cerrar los canales de entrada y salida que se hayan abierto durante la ejecuci n
de la aplicaci n. En la parte del cliente:

try {
salida.close();
entrada.close();
miCliente.close();
} catch( IOException e ) {
System.out.println( e );
}

Y en la parte del servidor:

try {
salida.close();
entrada.close();
socketServicio.close();
miServicio.close();
} catch( IOException e ) {
System.out.println( e );
}

Veamos el c digo que presentamos en el siguiente ejemplo, minimoServidor.java, donde

desarrollamos un mínimo servidor TCP/IP, para el cual desarrollaremos. La aplicaci n servidor
TCP/IP depende de una clase de comunicaciones proporcionada por Java: ServerSocket. Esta clase
realiza la mayor parte del trabajo de crear un servidor.

import java.awt.*;
import java.net.*;
import java.io.*;

class minimoServidor {
public static void main( String args[] ) {
ServerSocket s = (ServerSocket)null;
Socket s1;
String cadena = "Tutorial de Java!";
int longCad;
OutputStream s1out;

// Establece el servidor en el socket 4321 (espera 300 segundos)

try {
s = new ServerSocket( 4321,300 );
} catch( IOException e ) {
System.out.println( e );
}

// Ejecuta un bucle infinito de listen/accept

while( true ) {
try {
// Espera para aceptar una conexi n
s1 = s.accept();
// Obtiene un controlador de fichero de salida asociado
// con el socket
s1out = s1.getOutputStream();

// Enviamos nuestro texto

longCad = sendString.length();
for( int i=0; i < longCad; i++ )
s1out.write( (int)sendString.charAt( i ) );

// Cierra la conexi n, pero no el socket del servidor

s1.close();
} catch( IOException e ) {
System.out.println( e );
}
}
}
}
V

3.4. TRANSMISION DE FLUJOS (DATOS)

Envio/Lectura de datos normales (enteros, flotantes, strings)

El envío/lectura de datos normales se hace con las clases DataInputStream y DataOutputStream. No

tienen ningún truco especial, basta usar el método adecuado (writeInt(), writeFloat(), readInt(), etc).
Para strings usaremos los métodos writeUTF() y readUTF(), que envían/leen las cadenas en formato
UTF.

Envio/Lectura de clases enteras

Para el envío/lectura de clases normales usaremos los métodos readObject() y writeObject() de

ObjectInputStream y ObjectOutputStream. Para poder usar estos métodos las clases que enviemos
deben implementar la interface Serializable.

Las clases de tipos de java (Integer, Float, String, etc) implementan esa interface, así que se pueden
enviar/leer a través de estos métodos.

Si una clase nuestra contiene atributos que sean primitivos de java (int, float, etc) o clases primitivas
(Float, Integer, String, etc), basta con hacer que implemente la interface Serializable para poder
enviarlas. No hace falta que escribamos ningún método, simplemente poner que se implementa.

// Esta clase se puede enviar/leer por un socket.

class Atributo implements Serializable
{
int a;
String b;
}

Si alguno de los atributos no es primitivo de java, basta con que implemente la misma interface
Serializable. Si es así, no tendremos ningún problema.
// Esta clase se puede enviar/leer por un socket
class DatoSocket implements Serializable
{
int c;
String d;
Atributo e; // Esta clase es serializable.
}

Si alguna de las clases no es Serializable, tendremos que implementar los métodos privados

private void writeObject(java.io.ObjectOutputStream out) throws IOException {

// Enviamos los atributos a y b en un orden cualquiera.
out.writeInt (a);
out.writeUtf (b);
}

private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException

{
// Leemos los atributos a y b en el mismo orden que los enviamos en writeObject()
a = in.readInt();
b = in.readUtf();
}

En el método writeObject() deberemos enviar por el ObjectOutputStream todos los atributos de

nuestra clase, en el orden que consideremos adecuado. En el método readObject() deberemos ir
leyendo del ObjectInputStream todos los atributos de nuestra clase e ir rellenando nuestros atributos.
El orden en que leemos debe ser el mismo que en el que escribimos y el formato leído el mismo que
el escrito.

En los dos cuadros de ejemplo de arriba hemos puesto el c digo de ambos métodos para la clase
Atributo, pero realmente no hace falta escribir este c digo. En las fuentes de ejemplo aparece el
c digo, pero está comentado. Si lo descomentas funcionará igual.

Para enviar una de estas clases el c digo es sencillo

DatoSocket dato = new DatoSocket();

cliente.writeObject(dato);

Para leerlo es igual de simple, s lo que tenemos que saber qué tipo de clase estamos recibiendo para
hacer el "cast" adecuado.

DatoSocket dato;
Object aux;
aux = socket.readObject();// Se lee el objeto
if (aux instanceof DatoSocket) // Se comprueba si es de tipo DatoSocket
dato = (DatoSocket)aux; // Se hace el cast.

Debemos ir haciendo varios if con las posibles clases que nos envíen desde el otro lado.

3.5. SOCKETS CON TCP Y UDP

V
Sockets Stream (TCP)
Son un servicio orientado a conexi n, donde los datos se transfieren sin encuadrarlos en registros o
bloques. Si se rompe la conexi n entre los procesos, éstos serán informados de tal suceso para que
tomen las medidas oportunas.
El protocolo de comunicaciones con streams es un protocolo orientado a conexi n, ya que para
establecer una comunicaci n utilizando el protocolo TCP, hay que establecer en primer lugar una
conexi n entre un par de sockets. Mientras uno de los sockets atiende peticiones de conexi n
(servidor), el otro solicita una conexi n (cliente). Una vez que los dos sockets estén conectados, se
pueden utilizar para transmitir datos en ambas direcciones.

Sockets Datagrama (UDP)

Son un servicio de transporte sin conexi n. Son más eficientes que TCP, pero en su utilizaci n no está
garantizada la fiabilidad. Los datos se envían y reciben en paquetes, cuya entrega no está
garantizada. Los paquetes pueden ser duplicados, perdidos o llegar en un orden diferente al que se
envi .
El protocolo de comunicaciones con datagramas es un protocolo sin conexi n, es decir, cada vez
que se envíen datagramas es necesario enviar el descriptor del socket local y la direcci n del socket
que debe recibir el datagrama. Como se puede ver, hay que enviar datos adicionales cada vez que se
realice una comunicaci n, aunque tiene la ventaja de que se pueden indicar direcciones globales y el
mismo mensaje llegará aun muchas máquinas a la vez.

Diferencias entre Sockets Stream y Datagrama

Ahora se presenta un problema, al haber varias opciones, ¿qué protocolo, o tipo de sockets, se debe
emplear - UDP o TCP? La decisi n depende de la aplicaci n cliente/servidor que se esté escribiendo;
aunque hay algunas diferencias entre los protocolos que sirven para ayudar en la
decisi n y decantar la utilizaci n de sockets de un tipo.

En UDP, cada vez que se envía un datagrama, hay que enviar también el descriptor del socket
local y la direcci n del socket que va a recibir el datagrama, luego los mensajes son más grandes que
los TCP. Como el protocolo TCP está orientado a conexi n, hay que establecer esta conexi n entre
los dos sockets antes de nada, lo que implica un cierto tiempo empleado en el establecimiento de la
conexi n, que no es necesario emplear en UDP.

En UDP hay un límite de tamaño de los datagramas, establecido en 64 kilobytes, que se pueden
enviar a una localizaci n determinada, mientras que TCP no tiene límite; una vez que se ha
establecido la conexi n, el par de sockets funciona como los streams: todos los datos se leen
inmediatamente, en el mismo orden en que se van recibiendo. UDP es un protocolo desordenado,
no garantiza que los datagramas que se hayan enviado sean recibidos en el mismo orden por el
socket de recepci n. Al contrario, TCP es un protocolo ordenado, garantiza que todos los paquetes
que se envíen serán recibidos en el socket destino en el mismo orden en que se han enviado.
Los datagramas son bloques de informaci n del tipo lanzar y olvidar. Para la mayoría de los
programas que utilicen la red, el usar un flujo TCP en vez de un datagrama UDP es más sencillo
y hay menos posibilidades de tener problemas. Sin embargo, cuando se requiere un rendimiento
ptimo, y está justificado el tiempo adicional que supone realizar la verificaci n de los datos, la
comunicaci n a través de sockets TCP es un mecanismo realmente útil.

En resumen, TCP parece más indicado para la implementaci n de servicios de red como un control
remoto (rlogin, telnet) y transmisi n de ficheros (ftp); que necesitan transmitir datos de longitud
indefinida. UDP es menos complejo y tiene una menor sobrecarga sobre la conexi n; esto hace que
sea el indicado en la implementaci n de aplicaciones cliente/servidor en sistemas distribuidos
montados sobre redes de área local.

3.6. APLICACIÓN CLIENTE-SERVIDOR

Los sockets proporcionan una comunicaci n de dos vías, punto a punto entre dos procesos. Los
sockets son muy versátiles y son un componente básico de comunicaci n entre interprocesos e
intersistemas. Un socket es un punto final de comunicaci n al cual se puede asociar un nombre.

Para lograr tener un socket es necesario que se cumplan ciertos requisitos

! V 2
 programa s
a capaz d
localizar al otro
2 V 2
ambos programas s
a capac
s d
it
rcambiars
iormació

Por lo que son necesarios tres recursos que originan el concepto de socket

a) Un protocolo de comunicaciones, que permite el intercambio de octetos.

b) Una direcci n del Protocolo de Red (Direcci n IP, si se utiliza el Protocolo TCP/IP), que identifica
una computadora.

c) Un número de puerto, que identifica a un programa dentro

de una computadora. Con un socket se logra implementar
una arquitectura cliente-servidor. la comunicaci n es
iniciada por uno de los programas (cliente). Mientras el
segundo programa espera a que el otro inicie la
comunicaci n (servidor). Un Socket es un archivo existente
en el cliente y en el servidor.

Si un socket es un punto final de un puente de

comunicaron de dos vías entre dos programas que se
comunican a través de la red, ¿C mo funciona?
Normalmente, un servidor funciona en una
computadora específica usando un socket con un
número de puerto específico. El cliente conoce el
nombre de la maquina (hostname) o el IP, en la cual el
servidor está funcionando y el numero del puerto con el
servidor está conectado.

Si el cliente lanza una demanda de conexi n y el servidor

acepta la conexi n, este abre un socket en un puerto
diferente, para que pueda continuar escuchando en el
puerto original nuevas peticiones de conexi n, mientras que
atiende a las peticiones del cliente conectado. El cliente y el
servidor pu8eden ahora comunicarse escribiendo o leyendo
en sus respectivos sockets.

Los tipos de socket definen las propiedades de comunicaci n visibles para la aplicaci n. Los procesos
se comunican solamente entre los sockets del mismo tipo. Existen cinco tipos de sockets.
El Cliente actúa de la siguiente forma.

1) Establece una conexi n con el servidor (Crea un socket con el servidor). 2) Mandar mensajes al
servidor o Esperar un mensaje de él. (Consultas) 3) Esperar su respuesta o contestarle (existen casos
en que este paso no es necesario). 4) Repetir los pasos 2 y 3 mientras sea necesario. 5) Cerrar la
conexi n con el servidor.

El servidor actúa así.

1) Inicializa un puerto de comunicaci n, en espera de clientes que intenten conectarse a él (Crea un

serverSocket).

2) Una vez que se conecta alguien, crea un hilo de ejecuci n para este usuario mientras que el
thread principal vuelve al paso 1. Esto comunmente se hace para que el servidor puede atender a
varios clientes al mismo tiempo.

3) Se comunica con el cliente mediante el socket creado entre el cliente y él.

4) Espera que el cliente se vaya o lo bota el mismo servidor (Cierrra el socket entre ellos) y elimina
el thread de comunicaci n entre ellos.

Las propiedades de un socket dependen de las características del protocolo en el que se

implementan. El protocolo más utilizado es TCP, aunque también es posible utilizar UDP o IPX.
Gracias al protocolo TCP, los sockets tienen las siguientes propiedades:

I.V Orientado a conexi n. Se garantiza la transmisi n de todos los octetos sin

errores ni omisiones.

II.V
Se garantiza que todo octeto llegará a su destino en el mismo orden en que se
ha transmitido.

Los tipos de socket definen las propiedades de comunicaci n visibles para la aplicaci n. Los procesos
se comunican solamente entre los sockets del mismo tipo. Existen tres tipos básicos de sockets.

Socket de flujo : da un flujo de datos de dos vías, confiable, y sin duplicados sin límites de grabaci n.
El flujo opera en forma parecida a una conversaci n telef nica. El tipo del socket es SOCK_STREAM,
el cual en el dominio de Internet usa TCP (Transmission Control Protocol).

Socket de datagrama

Soporta un flujo de mensajes de dos vías. En un socket de datagrama podría recibir mensajes en
diferente orden de la secuencia de la cual los mensajes fueron envíados. Los límites de grabaci n en
los datos son preservados. Los sockets de datagrama operan parecidos a pasar cartas hacia adelante y
hacia atrás en el correo. El tipo de socket es SOCK_DGRAM, el cual en el dominio de internet usa
UDP (User Datagram Protocol).

Socket de paquete secuencial

da una conexi n de dos vías, secuencial y confiable para datagramas de una longitud fija máxima. El
tipo de socket es SOCK_SEQPACKET. No hay protocolo en Internet implementado para este tipo de
socket.

Implementando un socket en java

En un programa Cliente-Servidor un socket nos ayuda a representar las conexiones entre un

programa cliente y uno servidor. En el lado del cliente se utiliza la clase Socket y en el del servidor
el Server Socket para representar dichas conexiones.

PROGRAMA CLIENTE

El programa cliente se conecta a un servidor indicando el nombre de la máquina y el número puerto

(tipo de servicio que solicita) en el que el servidor está instalado. Una vez conectado, lee una cadena
del servidor y la escribe en la pantalla:

import java.io.*; import java.net.*; class Cliente

{
static final String HOST = ´localhostµ;
static final int PUERTO=5000;
public Cliente( )
{
try
{
Socket skCliente = new Socket( HOST , Puerto );
Input Stream aux = skCliente.getInputStream();
Data Input Stream? flujo = new Data Input Stream( aux );
System.out.println( flujo.readUTF() );
skCliente.close();
}
catch( Exception e )
{
System.out.println( e.getMessage() );
}
}
public static void main( String[] arg )
{
new Cliente();
}
}

En primer lugar se crea el Socket denominado skSocket, al que se le especifican el nombre de host
(HOST) y el número de puerto (PORT) en este ejemplo constante. Luego se asocia el flujo de datos
de dicho Socket (obtenido mediante getInputStream), que es asociado a un flujo (flujo) Data Input
Streamde? lectura secuencial. De dicho flujo capturamos una cadena ( readUTF()), y la imprimimos
por pantalla (System.out). El Socket se cierra, una vez finalizadas las operaciones, mediante el
método close(). Debe observarse que se realiza una gesti n de excepci n para capturar los posibles
fallos tanto de los flujos de datos como del Socket.

PROGRAMA SERVIDOR
El programa servidor se instala en un puerto determinado, a la espera de conexiones, a las que
tratará mediante un segundo SOCKET. Cada vez que se presenta un cliente, le saluda con una frase
´Hola cliente Nµ. Este servidor s lo atenderá hasta tres clientes, y después finalizará su ejecuci n,
pero es habitual utilizar ciclos infinitos (while(true)) en los servidores, para que atiendan llamadas
continuamente.Tras atender cuatro clientes, el servidor deja de ofrecer su servicio:

import java.io.* ; import java.net.* ; class Servidor

{
static final int PUERTO=5000;
public Servidor( )
{
try
{
Server Socket skServidor = new Server Socket( PUERTO );
System.out.println(´Escucho el puerto ´ + PUERTO );
for ( int numCli = 0; numCli < 3; numCli++; ) {
Socket skCliente = skServidor.accept(); // Crea objeto
System.out.println(´Sirvo al cliente ´ + numCli);
Output Stream aux = skCliente.getOutputStream();
Data Output Stream flujo= new Data Output Stream( aux );
flujo.writeUTF( ´Hola cliente ´ + numCli );
skCliente.close();
} // Cierra while

System.out.println(´Demasiados clientes por hoyµ);

}
catch( Exception e )
{
System.out.println( e.getMessage() );
}
}
public static void main( String[] arg ) {
new Servidor();
}
Ü

UNIDAD 4: CONCURRENCIA

4.1 PROCESOS Y HEBRAS

Un proceso es un programa en ejecuci n. Un proceso simple tiene un hilo de ejecuci n, por el

momento dejemos esta última definici n como un concepto, luego se verá en más detalle el
concepto de hilo. Una vez definido que es un proceso nos podríamos preguntar cuál es la diferencia
entre un programa y un proceso, y básicamente la diferencia es que un proceso es una actividad de
cierto tipo que contiene un programa, entradas salidas y estados.

Los procesos pueden ser cooperantes o independientes, en el primer caso se entiende que los
procesos interactúan entre sí y pertenecen a una misma aplicaci n. En el caso de procesos
independientes en general se debe a que no interactúan y un proceso no requiere informaci n de
otros o bien porque son procesos que pertenecen a distintos usuarios.
Una hebra posee también su propio entorno de ejecuci n pero al crear una nuea hebra, se necesitan
menos recursos que para un nuevo proceso. Las hebras tienen un ciclo de vida dentro de un proceso
y comparten los recursos de este proceso incluyendo la memoria asignada, los ficheros abiertos y
todos los recursos.

4.2 EJECUCION DE PROCESOS

La implementaci n del modelo de procesos se logra debido a que el sistema operativo almacena en
una tabla denominada tabla de control de procesos informaci n relativa a cada proceso que se está
ejecutando en el procesador. Cada línea de esta tabla representa a un proceso.

La informaci n que se almacena es la siguiente:

1) Identificaci n del proceso.

2) Identificaci n del proceso padre.

3) Informaci n sobre el usuario y grupo.

4) Estado del procesador.

5) Informaci n de control de proceso

5.1) Informaci n del planificador.

5.2) Segmentos de memoria asignados.

5.3) Recursos asignados.

4.3 EJECUCION DE HEBRAS

La ejecuci n de múltiples hebras es una característica esencial en Java. Todas las aplicaciones tienen al
menos una hebra o varias si tomamos cada llamada al sistema System como una hebra que se va a
ejecutar de forma independiente.

Desde el punto de vista del programador, cada programa java comienza con una hebra
denominada main que posee la habilidad de crear hebras adicionales.

La idea es crear aplicaciones que puedan realizar a la vez diferentes tareas o, al menos, hacer creer a
los usuarios de que se están realizados varias cosas simultáneamente. Por ejemplo, una aplicaci n
multithreaded que gestiona un almacén será capaz de recibir datos por la red, realizar cálculos y a la
vez, aceptar la entrada del usuario. Aunque s lo se ejecutará un thread a la vez, el sistema operativo
que ejecuta el programa, va ejecutando durante cierto tiempo un thread y luego saltará al siguiente
thread y al usuario le dará la impresi n de que se están ejecutando todos a la vez.
Para entender c mo se codifican los threads, vamos a ver un ejemplo que contiene un solo proceso.
En este ejemplo, el c digo se ejecuta de forma lineal hasta que se llega a la última línea, entonces el
proceso termina.

public class Saludo {

// MÉTODOS
public void saluda (String quien) {
System.out.println (quien + " ha saludado");
}
// MAIN
public static void main (String args[]) {

Saludo presentador = new Saludo();

presentador.saluda ("persona1");
presentador.saluda ("persona2");
presentador.saluda ("persona3");
System.out.println ("Todo el mundo ha saludado");
}
}

Explicaci n: La ejecuci n comienza y se crea una instancia de la clase Saludo. Luego se llama tres
veces al método saluda(). Cada llamada se ejecuta y luego se devuelve el control al programa
principal. La última sentencia del main() escribe "Todo el mundo ha saludado" y entonces el
programa termina. Al introducir los threads en este programa, se romperá la linealidad de la
ejecuci n. El programa se dividirá en fragmentos y cada uno de los cuales se encargará de escribir el
mensaje en pantalla.

public class Saludo implements Runnable {

// METODOS
public void run () {
System.out.println (Thread.currentThread().getName() + " ha saludado");
}
// MAIN
public static void main (String args[]) throws InterruptedException {
int i = 0;
Saludo presentador = new Saludo();
// Se crea el primer thread
Thread unThread = new Thread (presentador, "persona1");
// Se crea el segundo thread
Thread otroThread = new Thread (presentador, "persona2");
unThread.start(); // se arranca el primer thread
otroThread.start(); // se arranca el segundo thread
// Cuerpo del programa principal
while (unThread.isAlive() || otroThread.isAlive()) i++;
// Se ejecuta después de los threads han terminado
System.out.println ("El valor de i es " + i );
System.out.println ("Todo el mundo ha saludado");
}
}

Ahora el programa inicia dos threads que se ejecutan concurrentemente a la vez que el programa
principal. Después de que se crean los threads, se llama al método start() de cada thread, lo que le
dice al intérprete de Java que comience a procesar ese thread. El método main() es el responsable de
inicializar cada thread y de determinar cuando terminan. Esto es necesario porque el programa
necesita saber cuándo es seguro ejecutar la línea de c digo:

System.out.println ("El valor de i es " + i );

De otro modo, el programa podría terminar antes de que los threads hayan terminado y el
programa podría colgarse. Para controlar esto, se ha puesto un bucle que incrementa el valor de una
variable mientras los threads se están ejecutando.

while (unThread.isAlive() || otroThread.isAlive()) i++;

Si se compila y ejecuta este programa, se podrá comprobar que el valor de la variable i es diferente
en cada ejecuci n del programa. Esta variable almacena el número de veces que se ejecuta el bucle
while mientras se ejecutan los threads. El hecho de que este valor cambie, ilustra como Java ejecuta
los programas que se dividen en distintos procesos.

4.4 USO COMPARTIDO DE RECURSOS

En la actualidad casi todos los sistemas operativos proporciona servicios para la programaci n
multihilo pero el tratamiento por parte de la JVM es algo distinto a como lo realizan estos sistemas.
Todas las JVM de todas las plataformas proporcionan hilos de ejecuci n aunque el sistema operático
subyacente no los proporcione, en este caso el JVM simula ese comportamiento. Sin embargo incluso
en sistemas que sí admiten este tipo de programaci n hasta la versi n del JDK 1.2 los hilos de la JVM
no se correspondían a hilos nativos del sistema (excepto en su versi n para Solaris) con lo cual el
rendimiento del programe en general se veía gravemente dañado. Sin embargo a partir de esta
versi n la JVM para entornos Windows proporciona servicios de hilos nativos (esto es
proporcionados por el api Win32 y no simulados por el sistema) y a partir de la versi n 1.3 realiza el
mismo tratamiento para entornos Windows. A parte de estos hilos nativos la JVM en todo caso sigue
proporcionando hilos simulados por ella misma (no nativos) conocidos como hilos verdes (green
threads) que garantizan el mismo comportamiento en todas las plataformas en las que se ejecuten en
cuanto a la cuesti n de la planificaci n (que hilo toma el control del procesador y en qué momento).

Habíamos dicho un hilo puede crearse extendiendo a la clase Thread o bien implementando a la
interfaz Runnable.En ambos casos la clase debe proporcionar una definici n del método run () que
contiene el c digo a ejecutarse una vez que el hilo entre en estado de ejecuci n. Veamos un ejemplo
de los dos métodos:

//Clase HiloThread
public classHiloThread extendsThread {
public voidrun() {
while(true) {
System.out.println("Hola mundo,soy el hilo HiloTread"); } } }

//Clase HiloRunnable
public classHiloRunnable implementsRunnable
{
public voidrun() {
while(true) {
System.out.println("Hola mundo,soy el hilo HiloRunnable"); } } }
 
 

''
  

''
       

** Establ
c
la co
io y cr
a la v
taa y la clas
d
cotrol

packag
Chat_Hilos chat cli
t


import java 
t Sock
t

import java swig
ram

import java swig idowCostats

p blic class Cli
t
Chat

{
privat
Sock
t sock
t /** Sock
t co
l s
rvidor d
l chat */
privat
Pa
lCli
t
pa
l /** Pa
l co la v
taa d
l cli
t
*/

p blic static void maiStrig[] args)

{

w Cli
t
Chat) /*** Arraca
l Cli
t
d
chat ***/
}

p blic Cli
t
Chat) /** Cr
a la v
taa,
stabl
c
la co
io
istacia al cotrolador

**/
{
try
{
cr
aYVis alizaV
taa)
sock
t = 
w Sock
tlocalhost, 5557)
CotrolCli
t
cotrol = 
w CotrolCli
t
sock
t, pa
l)
} catch Ec
ptio
)
{
Syst
m o t pritError)
}
}

privat
void cr
aYVis alizaV
taa) /** Cr
a a v
taa, l
m
t
d
tro
l pa
l para
l
cli
t
y la vis aliza **/
{

ram
v = 
w
ram
)
pa
l = 
w Pa
lCli
t
v g
tCot
tPa
))
v pack)
v s
tVisibl
tr
)
v s
tD
a ltClos
p
ratioidowCostats EXIT_ _CLSE)
}
}
/**
' 
 

'
             
* Lo q
ll
ga por
l sock
t lo m
stra

l t
tAr
a d
l pa
l, lo q

*
scrib

l s ario

l pa
l lo
via por
l sock
t
*/
packag
Chat_Hilos chat cli
t


import java awt
v
t ActioEv
t

import java awt
v
t ActioList

r
import java io DataIp tStr
am
import java io Data tp tStr
am
import java 
t Sock
t

p blic class CotrolCli
t
impl
m
ts ActioList

r, R abl

{

privat
DataIp tStr
am dataIp t /** Para l
ct ra d
datos d
l sock
t */
privat
Data tp tStr
am data tp t /** Para
scrit ra d
datos

l sock
t */
privat
Pa
lCli
t
pa
l /** Pa
l co los cotrol
s para
l s ario */
privat
Strig ombr
 /** E
sta Variabl
s
g arda
l ombr
q os da
l s
rvidor*/

p blic CotrolCli
t
Sock
t sock
t, Pa
lCli
t
pa
l)

{ /** Cotr y
a istacia d

sta clas
, lazado  hilo para at
d
r al sock
t */
this pa
l = pa
l
try
{
dataIp t = 
w DataIp tStr
amsock
t g
tIp tStr
am))
data tp t = 
w Data tp tStr
amsock
t g
t tp tStr
am))
pa
l addActioList

rthis)
Thr
ad hilo = 
w Thr
adthis)
hilo start)

} catch Ec
ptio
)
{

pritStackTrac
)
}
}
p blic void actioP
rorm
dActioEv
t
v
to)
{
try
{
data tp t writ

Tombr
+ pa
l g
tT
to))
} catch Ec
ptio
c
pcio)
{

c
pcio pritStackTrac
)
}
}

/**
 * M
todo r  para at
d
r al sock
t Todo lo q
ll
ga por
l sock
t s

*
scrib


l pa
l
*/
p blic void r )
{
try
{
ombr
= dataIp t r
ad
T)
pa
l Po
r ombr
ombr
)
whil
tr
)
{
pa
l addT
todataIp t r
ad
T) +)
}
} catch Ec
ptio
)
{

pritStackTrac
)
}
}
}
/**
' 
 

* Pa
l para mostrar la cov
rsacio y p
dir al s ario
l t
to q
q i
r

viar
*/
packag
Chat_Hilos chat cli
t


import java awt Bord
rLayo t

import java awt Cotai
r
import java awt lowLayo t
import java awt
v
t ActioList

r
import java swig
Lab
l
import java swig
B tto
import java swig
Pa
l
import java swig
ScrollPa

import java swig
T
tAr
a
import java swig
T
ti
ld
import java lag Strig

p blic class Pa
lCli
t

{
privat

ScrollPa
scroll
privat

T
tAr
a t
tAr
a
privat

T
ti
ld t
ti
ld
privat

B tto boto
privat

Lab
l lbl ombr

s
rvidor*/
/* Scroll */
/* Ar
a para mostrar la cov
rsacio */
/* Para p
dir
l t
to al s ario */
/* Boto para
viar
l t
to */
/* Lab
l para mostrar
l ombr
d
l cli
t

viado 

p blic Pa
lCli
t
Cotai
r cot

dor) /* Cr
a
l pa
l co todos s s compo
t
s */

{
 cot

dor s
tLayo t
w Bord
rLayo t))
lbl ombr
= 
w
Lab
l)
lbl ombr
s
tT
t
s ario )
t
tAr
a = 
w
T
tAr
a20,50)
scroll = 
w
ScrollPa
t
tAr
a)

Pa
l pa
l = 
w
Pa
l
w lowLayo t))
t
ti
ld = 
w
T
ti
ld50)
boto = 
w
B ttoEviar)
pa
l addt
ti
ld)
pa
l addboto)
cot

dor addlbl ombr
,Bord
rLayo t LI E_START)
cot

dor addscroll, Bord
rLayo t CE TER)
cot

dor addpa
l, Bord
rLayo t S
TH)
}

p blic void addActioList

rActioList

r accio) /* Añad
los
v
tos al boto y al p lsar

<itro> */
{
t
ti
ld addActioList

raccio)
boto addActioList

raccio)
}

p blic void addT
toStrig t
to) /** Añad

l t
to q
s
l
pasa al t
tAr
a */

{
t
tAr
a app
dt
to)
}
p blic void Po
r ombr
Strig t
to) /* Escrib

l ombr
d
cli
t


l lab
l lat
ral */
{
lbl ombr
s
tT
tt
to)
}

p blic Strig g
tT
to) /** D
v
lv

l t
to q
hay

l t
ti
ld y lo borra */
{
Strig t
to = t
ti
ld g
tT
t)
t
ti
ld s
tT
t)
r
t r t
to
}
}

Concurrencia y sincronizaci n

La programaci n concurrente puede dar lugar a muchos errores debido a la utilizaci n de recursos
compartidos que pueden ser alterados. Las secciones de codigo potencialmente peligrosas de
provocar estos errores se conocen como secciones criticas. En general los programas concurrentes
deben ser correctos totalmente. Este concepto es la suma de dos conceptos distintos la correcci n
parcial(o safety) esto es que no entrará nunca en ningún mal estado y la correcci n temporal(o
liveness) esto es que terminará en un algun momento de tiempo finito.En estos programas por tanto
hay que evitar que varios hilos entren en una secci n critica (exclusi n mutua o mutex) y que los
programas se bloqueen (deadlock). Además los programas que no terminan nunca (programas
reactivos) deben cumplir la ausencia de inanici n (starvation) esto es que tarde o temprano todos los
hilos alcanzan el control del procesador y ninguno quede indefinidamente en la lista de hilos listos y
también deben cumplir la propiedad de equitativita (fairwess) esto es repartir el tiempo de la forma
más justa entre todos los hilos.

Un monitor impide que varios hilos accedan al mismo recurso compartido a la vez. Cada monitor
incluye un protocolo de entrada y un protocolo de salida. En Java los monitores se consiguen
mediante el uso de la palabra reservadasynchronized bien como instrucci n de bloque o bien como
modificador de acceso de metodos.Este segundo caso se declararía como sigue: public synchronized
void método() Este método declarado de tal forma garantiza que solo un hilo de esta clase puede
acceder a este método a la vez, de tal forma que si un hilo de la misma clase intenta llamar a este
método mientras otro hilo esta dentro del hilo que realiza la llamada quedará en estado de
bloqueado esperando a que el primer hilo libere el monitor, esto es, salga del método sincronizado.
Sin embargo las seccione criticas, y el uso de monitores define secciones criticases muy costoso en
tiempo de ejecucuci n dado que los demás hilos se detendrán hasta que el monitor sea liberado. Y
también es costoso en tiempo de computaci n ya que como media se ha determinado que un
método sincronizado se ejecuta 6 veces más lento que uno que no este sincronizado. Por tanto es
recomendable sincronizas sola y exclusivamente aquellas partes del codigo que formen la secci n
critica y nada más. A este fin responde el delimitador de bloque synchronized, cuyo uso es el
siguiente:

synchronized(objeto)

{
...
}

4.5 APLICACIÓN CLIENTE-SERVIDOR CON SUBPROCESO MULTIPLE.

! // Cli
t
q
l

y m
stra la iormació q
l

vía  S
rvidor

2 import java io *
3 import java 
t *
4 import java awt *
5 import java awt
v
t *
6 import java swig *
7
8 p blic class Cli
t

t
ds
ram
{
9 privat

T
ti
ld campoItrod cir
!0 privat

T
tAr
a ar
aPatalla
!! privat
bj
ct tp tStr
am salida
!2 privat
bj
ctIp tStr
am
trada
!3 privat
Strig m
saj
= 
!4 privat
Strig s
rvidorChat
!5 privat
Sock
t cli
t

!6
!7 // iicializar s
rvidorChat y coig rar G
I
!8 p blic Cli
t
 Strig host )
!9 {
20 s p
r Cli
t
 )
2!
22 s
rvidorChat = host //
stabl
c
r
l s
rvidor al q
s
va a co
ctar
st
cli
t

23
24 Cotai
r cot

dor = g
tCot
tPa
)
25
26 // cr
ar campoItrod cir y r
gistrar compo
t
d

sc cha
27 campoItrod cir = 
w
T
ti
ld)
28 campoItrod cir s
tEditabl
 als
)
29 campoItrod cir addActioList

r
30 
w ActioList

r) {
3!
32 //
viar m
saj
al s
rvidor
33 p blic void actioP
rorm
d ActioEv
t
v
to )
34 {
35
viarDatos
v
to g
tActioCommad) )
36 campoItrod cir s
tT
t  )
37 }
38 }
39 )
40
4! cot

dor add campoItrod cir, Bord
rLayo t RTH )
42
43 // cr
ar ar
aPatalla
44 ar
aPatalla = 
w
T
tAr
a)
45 cot

dor add 
w
ScrollPa
 ar
aPatalla ),
46 Bord
rLayo t CE TER )
47
48 s
tSiz
 300, !50 )
49 s
tVisibl
 tr
)
50
5! } // i d
l costr ctor d
Cli
t

52
53 // co
ctars
al s
rvidor y proc
sar m
saj
s d
l s
rvidor
54 privat
void
j
c tarCli
t
)
55 {
56 // co
ctars
al s
rvidor, obt

r l jos, proc
sar la co
ió
57 try {
58 co
ctarAS
rvidor) // Paso ! cr
ar  sock
t para r
alizar la co
ió
59 obt

rl jos) // Paso 2 obt

r los l jos d

trada y salida
60 proc
sarCo
io) // Paso 3 proc
sar la co
ió
6! }
62
63 //
l s
rvidor c
rró la co
ió
64 catch  EEc
ptio
c
pcioE ) {
65 Syst
m
rr pritl El cli
t
t
rmio la co
ió )
66 }
67
68 // proc
sar los probl
mas q
p
d
 oc rrir al com icars
co
l s
rvidor
69 catch  IEc
ptio
c
pcioES ) {
70
c
pcioES pritStackTrac
)
7! }
72
73 ially {
74 c
rrarCo
io) // Paso 4 c
rrar la co
ió
75 }
76
77 } // i d
l método
j
c tarCli
t

78
79 // co
ctars
al s
rvidor
80 privat
void co
ctarAS
rvidor) throws IEc
ptio
8! {
82 mostrarM
saj
 It
tado r
alizar co
ió )
83
84 // cr
ar Sock
t para r
alizar la co
ió co
l s
rvidor
85 cli
t
= 
w Sock
t I
tAddr
ss g
tBy am
 s
rvidorChat ), !2345 )
86
87 // mostrar la iormació d
la co
ió
88 mostrarM
saj
 Co
ctado a  +
89 cli
t
g
tI
tAddr
ss) g
tHost am
) )
90 }
9!
92 // obt

r l jos para
viar y r
cibir datos
93 privat
void obt

rl jos) throws IEc
ptio
94 {
95 //
stabl
c
r l jo d
salida para los obj
tos
96 salida = 
w bj
ct tp tStr
am cli
t
g
t tp tStr
am) )
97 salida l sh) // vacíar bú
r d
salida para
viar iormació d

cab
zado
98
99 //
stabl
c
r l jo d

trada para los obj
tos
!00
trada = 
w bj
ctIp tStr
am cli
t
g
tIp tStr
am) )
!0!
!02 mostrarM
saj
 S
r
cibi
ro los l jos d
E/S )
!03 }
!04
!05 // proc
sar la co
ió co
l s
rvidor
!06 privat
void proc
sarCo
io) throws IEc
ptio
!07 {
!08 // habilitar campoItrod cir para q

l s ario d
l cli
t
p
da
viar m
saj
s
!09
stabl
c
rCampoT
toEditabl
 tr
)
!!0
!!! do { // proc
sar m
saj
s
viados d
l s
rvidor
!!2
!!3 // l

r m
saj
y mostrarlo
 patalla
!!4 try {
!!5 m
saj
=  Strig )
trada r
adbj
ct)
!!6 mostrarM
saj
  + m
saj
)
!!7 }
!!8
!!9 // atrapar los probl
mas q
p
d
 oc rrir al l

r d
l s
rvidor
!20 catch  Class oto dEc
ptio
c
pcioClas
oEcotrada ) {
!2! mostrarM
saj
 S
r
cibió  obj
to d
tipo d
scoocido )
!22 }
!23
!24 } whil
 !m
saj

q als SERVIDR>>> TERMI AR ) )
!25
!26 } // i d
l método proc
sarCo
io
!27
!28 // c
rrar l jos y sock
t
!29 privat
void c
rrarCo
io)
!30 {
!3! mostrarM
saj
 C
rrado co
ió )
!32
stabl
c
rCampoT
toEditabl
 als
) // d
shabilitar campoItrod cir
!33
!34 try {
!35 salida clos
)
!36
trada clos
)
!37 cli
t
clos
)
!38 }
!39 catch IEc
ptio
c
pcioES ) {
!40
c
pcioES pritStackTrac
)
!4! }
!42 }
!43
!44 //
viar m
saj
al s
rvidor
!45 privat
void
viarDatos Strig m
saj
)
!46 {
!47 //
viar obj
to al s
rvidor
!48 try {
!49 salida writ
bj
ct CLIE TE>>>  + m
saj
)
!50 salida l sh)
!5! mostrarM
saj
 CLIE TE>>>  + m
saj
)
!52 }
!53
!54 // proc
sar los probl
mas q
p
d
 oc rrir al
viar
l obj
to
!55 catch  IEc
ptio
c
pcioES ) {
!56 ar
aPatalla app
d Error al
scribir
l obj
to )
!57 }
!58 }
!59
!60 // método tilitario q

s llamado d
sd
otros s bproc
sos para maip lar a
!6! // ar
aPatalla

l s bproc
so d
spachador d

v
tos
!62 privat
void mostrarM
saj
 ial Strig m
saj
AMostrar )
!63 {
!64 // mostrar m
saj
d
l s bproc
so d

j
c ció d
la G
I
!65 Swig
tiliti
s ivok
Lat
r
!66 
w R abl
) { // clas
it
ra para as
g rar q
la G
I s
act alic
apropiadam
t

!67
!68 p blic void r ) // act aliza ar
aPatalla
!69 {
!70 ar
aPatalla app
d m
saj
AMostrar )
!7! ar
aPatalla s
tCar
tPositio
!72 ar
aPatalla g
tT
t) l
gth) )
!73 }
!74
!75 } // i d
la clas
it
ra
!76
!77 ) // i d
la llamada a Swig
tiliti
s ivok
Lat
r
!78 }
!79
!80 // método tilitario q

s llamado d
sd
otros s bproc
sos para maip lar a
!8! // campoItrod cir

l s bproc
so d
spachador d

v
tos
!82 privat
void
stabl
c
rCampoT
toEditabl
 ial bool
a
ditabl
)
!83 {
!84 // mostrar m
saj
d
l s bproc
so d

j
c ció d
la G
I
!85 Swig
tiliti
s ivok
Lat
r
!86 
w R abl
) { // clas
it
ra para as
g rar q
la G
I s
act alic
apropiadam
t

!87
!88 p blic void r ) //
stabl
c
la capacidad d
modiicar campoItrod cir
!89 {
!90 campoItrod cir s
tEditabl

ditabl
)
!9! }
!92
!93 } // i d
la clas
it
ra
!94
!95 ) // i d
la llamada a Swig
tiliti
s ivok
Lat
r
!96 }
!97
!98 p blic static void mai Strig args[] )
!99 {
200 Cli
t
aplicacio
20!
202 i  args l
gth == 0 )
203 aplicacio = 
w Cli
t
 !27 0 0 ! )
204
ls

205 aplicacio = 
w Cli
t
 args[ 0 ] )
206
207 aplicacio s
tD
a ltClos
p
ratio
ram
EXIT_ _CLSE )
208 aplicacio
j
c tarCli
t
)
209 }
2!0
2!! } // i d
la clas
Cli
t

***************************************************

! // Coig rar  s
rvidor q
r
ciba a co
ió d
 cli
t
,
ví

2 // a cad
a al cli
t
y ci
rr
la co
ió
3 import java io *
4 import java 
t *
5 import java awt *
6 import java awt
v
t *
7 import java swig *
8
9 p blic class S
rvidor
t
ds
ram
{
!0 privat

T
ti
ld campoItrod cir
!! privat

T
tAr
a ar
aPatalla
!2 privat
bj
ct tp tStr
am salida
!3 privat
bj
ctIp tStr
am
trada
!4 privat
S
rv
rSock
t s
rvidor
!5 privat
Sock
t co
io
!6 privat
it cotador = !
!7
!8 // coig rar G
I
!9 p blic S
rvidor)
20 {
2! s p
r S
rvidor )
22
23 Cotai
r cot

dor = g
tCot
tPa
)
24
25 // cr
ar campoItrod cir y r
gistrar compo
t
d

sc cha
26 campoItrod cir = 
w
T
ti
ld)
27 campoItrod cir s
tEditabl
 als
)
28 campoItrod cir addActioList

r
29 
w ActioList

r) {
30
3! //
viar m
saj
al cli
t

32 p blic void actioP
rorm
d ActioEv
t
v
to )
33 {
34
viarDatos
v
to g
tActioCommad) )
35 campoItrod cir s
tT
t  )
36 }
37 }
38 )
39
40 cot

dor add campoItrod cir, Bord
rLayo t RTH )
4!
42 // cr
ar ar
aPatalla
43 ar
aPatalla = 
w
T
tAr
a)
44 cot

dor add 
w
ScrollPa
 ar
aPatalla ),
45 Bord
rLayo t CE TER )
46
47 s
tSiz
 300, !50 )
48 s
tVisibl
 tr
)
49
50 } // i d
l costr ctor d
S
rvidor
5!
52 // coig rar y
j
c tar
l s
rvidor
53 p blic void
j
c tarS
rvidor)
54 {
55 // coig rar s
rvidor para q
r
ciba co
io
s proc
sar las co
io
s
56 try {
57
58 // Paso ! cr
ar  obj
to S
rv
rSock
t
59 s
rvidor = 
w S
rv
rSock
t !2345, !00 )
60
6! whil
 tr
) {
62
63 try {
64
sp
rarCo
io) // Paso 2
sp
rar a co
ió
65 obt

rl jos) // Paso 3 obt

r l jos d

trada y salida
66 proc
sarCo
io) // Paso 4 proc
sar la co
ió
67 }
68
69 // proc
sar
c
pció EEc
ptio c ado
l cli
t
ci
rr
la co
ió
70 catch  EEc
ptio
c
pcioE ) {
7! Syst
m
rr pritl El s
rvidor t
rmió la co
ió )
72 }
73
74 ially {
75 c
rrarCo
io) // Paso 5 c
rrar la co
ió
76 ++cotador
77 }
78
79 } // i d
istr cció whil

80
8! } // i d
l bloq
try
82
83 // proc
sar probl
mas co E/S
84 catch  IEc
ptio
c
pcioES ) {
85
c
pcioES pritStackTrac
)
86 }
87
88 } // i d
l método
j
c tarS
rvidor
89
90 //
sp
rar q
la co
ió ll
g
, d
sp és mostrar iormació d
la co
ió
9! privat
void
sp
rarCo
io) throws IEc
ptio
92 {
93 mostrarM
saj
 Esp
rado a co
ió )
94 co
io = s
rvidor acc
pt) // p
rmitir al s
rvidor ac
ptar la co
ió
95 mostrarM
saj
 Co
ió  + cotador +  r
cibida d
  +
96 co
io g
tI
tAddr
ss) g
tHost am
) )
97 }
98
99 // obt

r l jos para
viar y r
cibir datos
!00 privat
void obt

rl jos) throws IEc
ptio
!0! {
!02 //
stabl
c
r l jo d
salida para los obj
tos
!03 salida = 
w bj
ct tp tStr
am co
io g
t tp tStr
am) )
!04 salida l sh) // vaciar bú
r d
salida para
viar iormació d

cab
zado
!05
!06 //
stabl
c
r l jo d

trada para los obj
tos
!07
trada = 
w bj
ctIp tStr
am co
io g
tIp tStr
am) )
!08
!09 mostrarM
saj
 S
r
cibi
ro los l jos d
E/S )
!!0 }
!!!
!!2 // proc
sar la co
ió co
l cli
t

!!3 privat
void proc
sarCo
io) throws IEc
ptio
!!4 {
!!5 //
viar m
saj
d
co
ió
itosa al cli
t

!!6 Strig m
saj
= Co
ió
itosa
!!7
viarDatos m
saj
)
!!8
!!9 // habilitar campoItrod cir para q

l s ario d
l s
rvidor p
da
viar m
saj
s
!20
stabl
c
rCampoT
toEditabl
 tr
)
!2!
!22 do { // proc
sar los m
saj
s
viados por
l cli
t

!23
!24 // l

r
l m
saj
y mostrarlo
 patalla
!25 try {
!26 m
saj
=  Strig )
trada r
adbj
ct)
!27 mostrarM
saj
  + m
saj
)
!28 }
!29
!30 // atrapar probl
mas q
p
d
 oc rrir al tratar d
l

r d
l cli
t

!3! catch  Class oto dEc
ptio
c
pcioClas
oEcotrada ) {
!32 mostrarM
saj
 S
r
cibió  tipo d
obj
to d
scoocido )
!33 }
!34
!35 } whil
 !m
saj

q als CLIE TE>>> TERMI AR ) )
!36
!37 } // i d
l método proc
sarCo
io
!38
!39 // c
rrar l jos y sock
t
!40 privat
void c
rrarCo
io)
!4! {
!42 mostrarM
saj
 ializado la co
ió )
!43
stabl
c
rCampoT
toEditabl
 als
) // d
shabilitar campoItrod cir
!44
!45 try {
!46 salida clos
)
!47
trada clos
)
!48 co
io clos
)
!49 }
!50 catch IEc
ptio
c
pcioES ) {
!5!
c
pcioES pritStackTrac
)
!52 }
!53 }
!54
!55 //
viar m
saj
al cli
t

!56 privat
void
viarDatos Strig m
saj
)
!57 {
!58 //
viar obj
to al cli
t

!59 try {
!60 salida writ
bj
ct SERVIDR>>>  + m
saj
)
!6! salida l sh)
!62 mostrarM
saj
 SERVIDR>>>  + m
saj
)
!63 }
!64
!65 // proc
sar probl
mas q
p
d
 oc rrir al
viar
l obj
to
!66 catch  IEc
ptio
c
pcioES ) {
!67 ar
aPatalla app
d Error al
scribir obj
to )
!68 }
!69 }
!70
!7! // método tilitario q

s llamado d
sd
otros s bproc
sos para maip lar a
!72 // ar
aPatalla

l s bproc
so d
spachador d

v
tos
!73 privat
void mostrarM
saj
 ial Strig m
saj
AMostrar )
!74 {
!75 // mostrar m
saj
d
l s bproc
so d

j
c ció d
spachador d

v
tos
!76 Swig
tiliti
s ivok
Lat
r
!77 
w R abl
) { // clas
it
ra para as
g rar q
la G
I s
act alic
apropiadam
t

!78
!79 p blic void r ) // act aliza ar
aPatalla
!80 {
!8! ar
aPatalla app
d m
saj
AMostrar )
!82 ar
aPatalla s
tCar
tPositio
!83 ar
aPatalla g
tT
t) l
gth) )
!84 }
!85
!86 } // i d
la clas
it
ra
!87
!88 ) // i d
la llamada a Swig
tiliti
s ivok
Lat
r
!89 }
!90
!9! // método tilitario q

s llamado d
sd
otros s bproc
sos para maip lar a
!92 // campoItrod cir

l s bproc
so d
spachador d

v
tos
!93 privat
void
stabl
c
rCampoT
toEditabl
 ial bool
a
ditabl
)
!94 {
!95 // mostrar m
saj
d
l s bproc
so d

j
c ció d
spachador d

v
tos
!96 Swig
tiliti
s ivok
Lat
r
!97 
w R abl
) { // clas
it
ra para as
g rar q
la G
I s
act alic
apropiadam
t

!98
!99 p blic void r ) //
stabl
c
la capacidad d
modiicar a campoItrod cir
200 {
20! campoItrod cir s
tEditabl

ditabl
)
202 }
203
204 } // i d
la clas
it
ra
205
206 ) // i d
la llamada a Swig
tiliti
s ivok
Lat
r
207 }
208
209 p blic static void mai Strig args[] )
2!0 {
2!! S
rvidor aplicacio = 
w S
rvidor)
2!2 aplicacio s
tD
a ltClos
p
ratio
ram
EXIT_ _CLSE )
2!3 aplicacio
j
c tarS
rvidor)
2!4 }
2!5
2!6 } // i d
la clas
S
rvidor
 EBGRAIA

http//casidiablo 
t/aplicacio
s-co-g i-
-
t-¿gtk-o-widows-orms/

http//
s wikip
dia org/wiki/
tB
as

http//www sc
h
s/sbw
b/isica/c rso
ava/ dam
tos/archivos/l jos htm

http// p
badajoz j ta
tr
mad ra 
t/compo
t/cot
t/articl
/!04-diario-oicial-d
-

tr
mad ra/288-istr ccio
s-sobr
-r
d
s

http//
s wikip
dia org/wiki/Mod
lo_SI

http//www alial com/T
mas/tcpip php

http//
s wikip
dia org/wiki/Cli
t
-s
rvidor

http://dialnet.unirioja.es/servlet/articulo?codigo

http//www docstoc com/docs/23955078/Sock
ts-
-
ava

http//www ch idiag com/cli /sock
ts/sock
ts_simp php

http//www ior va
s/~jv
gas/c rsos/prog/t
ma6 html

http//www idg
s/pcworld/Hilos-d
-proc
so-co-
ava-thr
ads/art!55444 htm