Download UDPyMultiCap7 - DCC

Módulo 8: Desarrollo de Aplicaciones en Redes
Transmisión de datos sin
conexión y Multicasting
Capítulo 6
1
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Comunicación Servidor-Cliente sin
conexión
 Hasta ahora hemos visto cómo se logran comunicar 2
programas estableciendo entre ellos un circuito virtual a
través de una conexión TCP/IP.
 Sabemos que en una conexión de este tipo se genera
mucho tráfico y que la comunicación es más lenta, ya que
el protocolo subyacente de confirmación, retransmisión,
descarte y/o reordenación de paquetes se basa en mensajes
de datagramas.
 Habíamos visto que a veces el usuario debería optar por
una transmisión sin conexión, especialmente si no es
necesario garantizar la llegada de todos los datagramas.
 Para eso existen en JAVA todos lor recursos de modo de
mandar un datagrama aislado a un destinatario dado.
2
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Manejo de Datagramas en JAVA
 La comunicación se basa en armar paquetes UDP y enviarlos
a la internet con la siguiente información:
 Datos: un arreglo de bytes
 Número de port del destinatario: int
 Dirección Internet del destinatario: InetAddress
 El servidor se pone a escuchar en un socket dado si hay
paquetes destinados a él.
 El cliente arma un paquete y lo lanza a la internet.
 El servidor recibe el paquete y extrae los datos, número de
port y dirección internet del enviador.
 Si necesita responder manda un paquete a la dirección (port
y dirección internet) que venía en el paquete recibido
3
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
UDP: comunicación con datagramas
DATAGRAMA: un mensaje independiente, autocontenido,
enviado a través de la internet internet, cuya llegada, tiempo
de llegada y contenido no están garantizados (como el cooreo
regular en algunos países....)
Una vez que un servidor está escuchando, el cliente podría
crear un datagrama con la dirección del servidor, número de
puerto y el mensaje.
www.waseda2.jp
www.waseda1.jp
A SERVER
A CLIENT
?
4444
www.waseda1.jp
4444
message
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
4
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Mandando datagramas con protocolo UDP
Luego éste podría abrir un socket y enviar el datagrama a la
internet. El “algoritmo de enrutamiento” encontrará el camino
al computador blanco.
www.waseda1.jp
A SERVER
www.waseda2.jp
A CLIENT
?
3333
4444
5
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Mandando datagramas con protocolo UDP
Antes que el datagrama abandone al cliente, éste
recibe la dirección del computador de origen y el
número de socket.
www.waseda1.jp
A SERVER
www.waseda2.jp
A CLIENT
!
4444
3333
6
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Mandando datagramas con protocolo UDP
Luego de que el datagrama es enviado, el computador
del cliente puede empezar a escuchar en el puerto
creado para enviar el datagrama si es que se espera una
respuesta del servidor.
www.waseda1.jp
www.waseda2.jp
?
A SERVER
4444
A CLIENT
3333
7
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Mandando datagramas con protocolo UDP
El servidor puede extraer la dirección del cliente y el
número del puerto para crear otro datagrama con la
respuesta.
www.waseda1.jp
www.waseda2.jp
?
A SERVER
A CLIENT
3333
4444
answer
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
8
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Mandando datagramas con protocolo UDP
Finalmente el datagrama es enviado con la respuesta al
“cliente”. Cuando un datagrama es enviado no hay garantía de
que llegará al su destino. Si se desea comunicación confiable,
debera proveerse de un mecanismo de chequeo, o usar...
www.waseda1.jp
www.waseda2.jp
?
A SERVER
4444
TiroPaquetes
A CLIENT
3333
ReciboPaquetes
9
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Clases para Datagramas en JAVA: envío
 Definición: Un datagrama es un mensaje independiente,
autocontenido que se manda de un programa a otro por la red
pero que su llegada, tiempo de llegada y contenido no estan
garantizados.
 Crear un socket por donde mandar el datagrama
 DatagramSocket ds = new DatagramSocket();
 Crear y armar el datagrama
 byte[] datos = new byte[256];
 InetAddress direccion = InetAddress.getByName(“www.ctc.cl”);
 DatagramPacket paquete = new DatagramPacket(datos,
datos.length,direccion,4444);
 Mandarlo
 ds.send(paquete);
 Esperar respuesta
 socket.receive(packet); //limpiarlo antes !!!
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
10
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Clases para Datagramas en JAVA: recepción
 Para poder recibir tengo que escuchar en un port acordado (ya
que de otra manera no hay cómo ponerse de acuerdo)
 socket = new DatagramSocket(4444);
 Preparar un Datagrama para recibir datos
 byte[] datos = new byte[256];
 DatagramPacket paquete = new DatagramPacket(datos,datos.length);
 Ponerse a escuchar si alguien manda un datagrama a este
computador a este port
 socket .receive(paquete);
 Sacar los datos, el port y la dirección de donde venía
 int port = paquete.getPort();
 InetAddress dirección = paquete getAddress();
 String contenido = new String(paquete.getData());
 Mandar una respuesta
 DatagramPacket respuesta = new DatagramPacket(datos,
datos.length, port, direccion);11
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
El Reloj Remoto
Servidor reloj remoto
UDPClockServer.java
Un servidor reloj remoto estará
poniendo al día el reloj con los UDPClockClient.java
paquetes UDP
12
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
El Servidor Reloj Remoto Múltiple
Un servidor reloj remoto
estará poniendo al día el
reloj con los paquetes
UDP
UDPClockServerThread.java
UDPClockMServer.java
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
13
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
¿ Qué hay de la pérdida de paquetes ?
Datagramas UDP pueden perderse como los
paquetes de internet
Podemos ver esto numerando los paquetes
Hagamos experimentos:
 package loss entre Chile and Germany
 package loss entre Japan and Chile
 package loss entre Chile and Japan
Lo mismo para una red local:
 con un número variable de clientes
Tiro/ReciboPaquetesNoEnd
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
14
Módulo 8: Desarrollo de Aplicaciones en Redes
Un cliente Ping UDP
Usaremos el servidor de echo
en una máquina unix el servidor de echo está
oyendo en el port 7 para UDP y para TCP
No es el mismo programa servidor sino que hay 2
sockets amarrados al mismo port !pero con diferente
protocolo
El cliente ping va a mandar un paquete al servidor
con la hora en que se mandó y el servidor lo enviará
de vuelta
Comparando la hora en el datagrama y la actual
podemos ver cuánto se demoró el viaje en redondo
El programa también calculará el max/min y med
Ping.java
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
15
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Multicasting
Qué pasa cuando se quiere hacer un broadcasting de
datos demasiado pesados ?
Por cada cliente, el servidor queda mucho rato
“pegado” escribiendo datos.
Imáginémonos ahora la situación en una
videoconferencia: se trata de transmitir varios
frames de video por segundo a una cantidad grande
de “oyentes” => no es posible en la práctica!
En el Multicasting se trata de transmitir una sola
vez la información a un punto en la internet, y desde
ahí la leen los clientes.
Esto implica que el hardware (el de la red, se
entiende) debe ser “multicastingable”
16
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
El Paradigma del Multicast
PROG2
PROG1
PROG2
PROG2
17
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Multicast & Broadcast
Multicast & Broadcast son protocolos que
permiten a una aplicación poner un paquete
único en la red el cual será recibido por varias
aplicaciones
Broadcast trabaja sólo dentro de la red local. Un
paquete mandado por broadcast lo recibirán
todos.
Requiere soporte de hardware de la red local.
Un paquete de multicast sólo lo recibirán los
programas que se registraron para ello
previamente
Multicast requiere apoyo en el host y los routers18
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Multicast
Multicast en Java es similar a UDP excepto que el
envío-recibo de paquetes debe ser implementado
para una dirección IP en el rango (224.0.0.0 239.255.255)
Para poder recibir paquetes de multicast el cliente
debe haber previamente haber expresado su interes
en unirse a un grupo multicast identificado por una
direccion IP multicast y un port.
La red (es decir los ruteadores) se encargarán de
transmitir los paquetes a todas las aplicaciones
interesadas en la internet (teóricamente!)
Cualquier aplicación puede mandar paquetes al
grupo !
19
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Qué pasa cuando se lanza un paquete
El paquete será tomado por todas las máquinas
de la red local interesadas.
Además, los ruteadores tomarán el paquete y lo
mandarán a las redes vecinas si hay una
aplicación interesada
El determinar si hay una aplicación interesada
en las redes adyacentes añade una complejidad
significativa al algoritmo de ruteo
El problema es cómo va a saber el ruteador si
una vecina a la vecina está interesada
Esto requiere el almacenaje de mayor
información en las tablas de ruteo
20
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Comunicación de Grupo con Multicast
Provee:
• Tolerancia a fallas basada en la replicidad de servicios: un
servicio replicado consiste en un grupo de servidores. El cliente
manda el request a todos los servidores que realizan la misma
operación.
• Encuentro de servicios de descubrimiento de servidores:
clientes y servidores usan mensajes de multicast para localizar
servicios presentes en la red para poder registrar sus interfaces y
y hacer lookup de interfaces de otros servicios
• Mejor performance por datos replicados: a veces se replican
los datos en los computadores cliente (cache) cuando estos
varían el servidor manda mensajes por multicast
• Propagación de eventos de notificación: para notificar a
procesos interesados en ciertos eventos que estos tuvieron lugar
(jini)
21
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Fallas en Multicast
Ya que se basa en UDP puede pasar :
• Tolerancia a fallas basada en la replicación de servicios: Si los
servidores parten de un mismo estado inicial y se coordinan con
los updates en un orden preciso. Si un miembro no recibe el
update o lo recibe en mal orden se vuelve inconsistente
• Encuentro de servicios de descubrimiento de servidores: esto
no es problema si las peticiones de localización se hacen
reiterativamente en tiempos regulares. Así se hace en Jini
• Mejor performance por datos replicados: si en vez de replicar
operaciones en los datos lo que se replica es el dato mismo, estos
pueden aparecer inconsistentemente en cada servidor
• Propagación de eventos de notificación: El servicio de anuncio
acerca de nuevos servicios en la red provisto por Jini envía
mensajes multicast reiterativos a tiempos regulares
22
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Ejemplo de Multicast en Java
Módulo 8: Desarrollo de Aplicaciones en Redes
import java.io.*;
import java.io.*;
import java.net.*;
import java.net.*;
public class MulticastClient {
import java.util.*;
public static void main(String[] args) throws IOException {
public class MulticastServer {
MulticastSocket socket = new MulticastSocket(4446);
static public void main(String args[]) {
InetAddress address =
DatagramSocket socket = null;
InetAddress.getByName("224.2.2.3");
BufferedReader in = null;
socket.joinGroup(address);
boolean moreQuotes = true;
byte[] buf = new byte[256];
try {
DatagramPacket packet;
socket = new DatagramSocket();
while (true) {
while(true) {
InetAddress grupo = InetAddress.getByName("224.2.2.3");
packet = new DatagramPacket(buf, buf.length);
for (int i=1; i< 1000; i++) {
socket.receive(packet);
String dString = i+"--"+(InetAddress.getLocalHost());
byte[] buf = dString.getBytes();
String received = new String(packet.getData());
DatagramPacket packet =
System.out.println("Received: " + received);
new DatagramPacket(buf, buf.length, grupo, 4446);
try {
socket.send(packet);
Thread.currentThread().sleep(0); }
try {
catch (InterruptedException e) {
}
Thread.currentThread().sleep(200); }
}
catch (InterruptedException e) {}
}
}
}
} catch (IOException e) {}
}
}
23
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Modelo de Multicast para grupos
Multicast tiene cualidades que lo hacen más eficiente para
transmitir un mensaje a varios miembros de un grupo
Modelo:
message(g,m) : operación de transmisión de un
mensaje m a los miembros de un grupo g
deliver(m) : operación de proceso de mensaje m
sender(m) : identificación del que manda el mensaje
group(m) : grupo de destino del mensaje
open/closed group : el grupo puede/no puede recibir
mensajes mandados por un por un
miembro que no pertenece al grupo
24
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Reliable Multicast
Reliable multicast implica que se cumplen 3 propiedades:
Integridad: el mensaje que se manda es igual al que se
procesa y que ningún mensaje es procesado dos veces. Un
proceso p hace la operación deliver(m) una sola vez y p 
group(m)
Validez : si un proceso manda un mensaje multicast, tarde
o temprano lo procesará si pertenece al grupo
Agreement : si un proceso procesa un mensaje m el resto
de los miembros del grupo también lo hará
25
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Reliable Multicast con IP !
• Cada proceso p mantiene un número de secuencia S(p,g) para grada
grupo g al que pertenece.
• También mantiene un registro R(q,g) que es el número de secuencia del
último mensaje procesado del proceso q que mandó al grupo g.
• Cuando p quiere mandar un mensaje a g incluye el número S(p,g) y
pares <q,R(q,g)>, luego incrementa S(p,g).
• Un proceso del grupo procesa el mensaje mandado por p sólo si el S =
R(p,g) +1
• Si S <= R(p,g) es un mensaje repetido y lo descarta
• Si S > R(p,g) + 1 significa que perdió un mensaje y manda un ack
negativo para que lo mande de nuevo.
• Integridad se alcanza por la detección de duplicados y los checkeos de
IP en los datagramas. Validez por propiedad de IP. Agreement implica
que los procesos siempre guardan copias de mensajes enviados para
enviarlos de nuevo
• para que esto funcione los proceso no deben fallar !!!!
26
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Ordenando los mensajes de Multicast
• Se usa un cola de mensajes multicast para guardarlos antes de procesarlos. Se
trata de asignar un número de secuencia para cada mensaje en el cual todos estén
de acuerdo. Cada proceso q en un grupo g mantiene un número A(q,g), el más
grande de la secuencia acordada que se ha observado para un grupo g y P(q,g) el
mayor de la secuencia propia. Cuando p quiere mandar un mensaje:
• Manda en forma segura <m,i> siendo m el mensaje e i un identificador
único para m
• cada proceso q responde a p con una proposición para acordar un número
de secuencia para ese mensaje P(q,g) = Max(A(q,g), P(q,g))+1. Cada
proceso guarda en su cola el mensaje con el número de secuencia que
propuso provisionalmente ordenado de menor a mayor número de secuencia
• p recolecta todos los números de secuencia propuestos y selecciona el
mayor a como el que se usará definitivamente y lo transmite en un mensaje
broadcast seguro <i,a>
• cada proceso entonces ordena la cola de mensajes antes de procesarlos
según los números de secuencia acordados
• ¿ Cómo se puede demostrar que esto es monotonicamente creciente ?
27
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Time to Live
Los paquetes multicast incluyen (como todos
los paquetes de internet) un campo TTL que
en este caso adquiere la importancia de evitar
que se propague demasiado por la internet
Por esto también es posible en java definir el
TTL que saldrán de un socket dado.
28
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Apoyo de Java para Multicast
MulticastSocket: extensión de DatagramSocket
 MulticastSocket( ) se amarra a cualquier port libre
 MulticastSocket(int port) usa port específico
Muchos socekts multicast pueden ser amarrados
al mismoport! (no como en TCP o UDP)
Métodos heredados (send, receive) + 3 nuevos
 joinGroup(InetAddress group)
 leaveGroup(InetAddress group)
 setTimeToLive(int ttl)
MulricastServer/client
29
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Un Chat basado en Multicast
No hay servidor.
Cada participante corre el mismo
programa uniéndose al grupo multicast
• Los mensajes salen como datagramas
“multicast” a la red, por lo cual cualquier
aplicación interesada lo recibirá
• No hay garantía de si llegará, en cuanto
rato, en qué órden ni si se duplicarán !
MulticastChat
30
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Spontaneous Networking
Multicasting is the right way to program
systems when the participants in the session may
come and go very frecuently
This is the case of spontaneous networking with
mobile devices in a room
Someone “announce” her precence to the other
members by sending message to all at regular
intervals
The fact that someone has left is recorded by the
others when there have been no messages from
her since a certain period of time
MulticastRegister
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
31
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
MBone
Multicast no está muy difundida en la internet. Esto
es por un lado porque se genera muho tráfico y, por
el otro, la ausencia de ruteadores con el protocolo
IGMP
Hay una subred llamada MBone que comunica islas
de redes multicas permitiéndo que los paquetes
multicast viajen entre ellas a través de túneles.
Un tunel omunica los routers de dos redes que no
están físicamente adjacentes.
Los paquetes serán pasados de una red a otra como
si estuvieran conectados físicamentes
32
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
Broadcast
Broadcast es similar a Multicast pero en una red
local
Cada red basada en broadcast (como ethernet) tiene
una dirección de broadcast IP. Cualquier mensaje
mandado a esta dirección será recibido por todos los
coputadores de esa red.
Usualmente esta es la última dirección IP de la
subred:
 Clase C: 192.1.2.0 -> 192.1.2.255
 Para una subred de 16 hosts 197.84.66.192 ->
197.84.66.207
Se debe en todo caso especificar el número de port
UDPBroadcastClient/Server
33
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001
Módulo 8: Desarrollo de Aplicaciones en Redes
¿ Broadcast o Multicast ?
Si se puede elegir es mejor usar multicast
porque moleta sólo a las máquinas interesadas.
A veces es necesario tener privilegios sobre la
red para usar la direccion multicast.
Multicast permite definir varios grupos dentro
de la misma red
El tráfico generado es el mismo: se pone un
paquete en la red pero todos lo leerán
Broadcast no tiene absolutamente ningúna
diferencia con UDP en Java. Sólo la dirección
IP es especial
34
Universidad de Chile – Av. Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl
2001