Documentos de Académico
Documentos de Profesional
Documentos de Cultura
import java.net.*;
import java.io.*;
public class UDPClient {
public static void main(String args[]) {
DatagramSocket socket = null;
try {
socket = new DatagramSocket();
byte[] m = args[0].getBytes();
InetAddress host = InetAddress.getByName(args[1]);
int port = 6789;
DatagramPacket req = new DatagraPacket(m,
args[0].length, host, port);
socket.send(req);
byte[] n = new byte[1000];
DatagramPacket rep = new
DatagraPacket(n, n.length);
socket.receive(rep);
System.out.println(Received + new String
(rep.getData()));
} catch (SocketException e) {
System.out.println(Socket: +e.getMessage()); }
} catch (IOException e) {
System.out.println(IO: +e.getMessage());}
} finally { if (socket != null) socket.close(); }
}
}
import java.net.*;
import java.io.*;
public class UDPServer {
public static void main(String args[]) {
DatagramSocket socket = null;
try {
socket = new DatagramSocket(6789);
byte[] n = new byte[1000];
while (true) {
DatagramPacket req = new
DatagraPacket(n, n.length);
socket.receive(req);
DatagramPacket rep = new
DatagramPacket(req.getData(),
req.getLength(), req.getAddress(),
req.getPort());
socket.send(rep);
}
} catch (SocketException e) {
System.out.println(Socket: +e.getMessage()); }
} catch (IOException e) {
System.out.println(IO: +e.getMessage());}
} finally { if (socket != null) socket.close(); }
}
}
Particularidades de UDP
Tamao del mensaje: el recibidor debe establecer el largo
del mensaje a recibir, si es ms chico que el que se mand se
trunca (se puede hasta 216 pero muchos ambientes lo limitan
a 8 kilobytes)
Bloqueo: la instruccin de send no bloquea Los datagramas
son almacenados en una cola en el destino. Si no hay proceso
esperndolos se descartan. Receive bloquea hasta que hay
algo que leer de la cola o hasta el timeout
Timeouts: se pueden definir sobre el socket, por default no
hay setSoTimeout. Concurrencia ?
Recibe de cualquiera: el receive no especifica de quin, as
que el origen se saca del datagrama. Se puede abrir un
DatagramSocket que slo pueda mandar a una direccin y a
un port connect (en qu casos es til?)
import java.net.*;
import java.io.*;
public class UDPServer {
public static void main(String args[]) {
try {
DataInputStream in = null;
DataOutputStream out = null;
ServerSocket ss = new ServerSocket(6789);
while(true) {
Socket s = ss.accept();
in = new DataInputStream(s.getInputStream());
out = new OutputStream(s.getOutputStream());
String data = in.readUTF();
out.writeUTF(data);
}
} catch (EOFException e) {
System.out.println(EOF: +e.getMessage());}
} catch (IOException e) {
System.out.println(IO: +e.getMessage());}
} finally { if (socket != null) try { socket.close(); }
catch(IOException e) {}
}
}
Particularidades de TCP
Coincidencia de datos en los extremos :
Bloqueo: hay chequeo (ack)
Fallas : TCP trata de hacer coincidir las velocidades de escritura
y lectura. Si el escribidor es muy rpido, trata de bloquearlo hasta
que el lector haya consumido suficiente.
Duplicacin y orden de mensajes: los paquetes ip contienen
identificadores correlativos que permiten al recibidor detectar
duplicados o cambiados de orden
Destino de los mensajes: como se abre una conexin virtual entre
ambos extremos, no es necesario especificar a quin va ya que el
socket se abre con un connect
Qu esconde TCP
Tamao del mensaje: Las aplicaciones deciden cunto leer y
cunto escribir. El sistema subyacente decide cmo transmitirlo.
Mensajes Perdidos: hay chequeo (ack)
Control de flujo: TCP trata de hacer coincidir las velocidades de
escritura y lectura. Si el escribidor es muy rpido, trata de
bloquearlo hasta que el lector haya consumido suficiente.
Duplicacin y orden de mensajes: los paquetes ip contienen
identificadores correlativos que permiten al recibidor detectar
duplicados o cambiados de orden
Destino de los mensajes: como se abre una conexin virtual entre
ambos extremos, no es necesario especificar a quin va ya que el
socket se abre con un connect
Problemas de TCP
Coincidencia de datos: Lo que se mande por un lado y lo que se
lea (formato) debe coincidir (en especial al mandar objetos).
Bloqueo: hay que asegurarse que cundo se escribe pocos datos
estos se manden si es necesario contar con ellos pronto o pueden
bloquear la ejecucin (buffer)
La comunicacin se establece de punto a punto, as que slo se
atiende a un cliente a la vez (a menos que se haga concurrente)
Falla de la conexin: si se demora mucho en hacer el ack
entonces la conexin se declara rota (se tira un IOException). En
este sentido TCP no es ms seguro de lo que la red lo es.
El proceso usando la conexin no puede distinguir si la falla se
debe a la red o a que el proceso par se cay
No puede saber despus de la cada qu llego efectivamente a
destino y qu no alcanz a llegar
El esquema request-reply
Muchas veces cuando se usa TCP o UDP se modela el protocolo
de comunicacin entre cliente y servidor con el esquema de
request-reply
Son la base para implementar middleware como RMI, RPC,
CORBA o algo parecido
Se basan en un trio de primitivas de comunicacin: doOperation,
getRequest y sendReply
Cliente
doOperation
(wait)
(continue)
Servidor
getRequest
(select object)
(execute meth.)
sendReplay
El esquema request-reply
Aunque a Implementacin UDP tiene ventajas se han
implementado ya algunas versiones en TCP:
el acknowladge de TCP es innecesario ya que se hace un reply
a cada request a nivel de aplicacin
se evitan los mensajes para la conexin
el control de flujo es innecesario cuando los argumentos
pasados son pequeos (caben en una trama)
Un esquema en Java (Ejemplo)
public byte[] doOperation(RemoteObjectref o, int methodID,
byte args)
manda una operacin sobre un objeto y retorna el reply
public byte[] getRequest()
recibe un request de un cliente
public void sendReply(byte[] reply, InetAddress clientHost,
int clientPort)
manda un reply a la direccin y port especificados
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
operacin.
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
varan el servidor manda mensajes por multicast
Propagacin de eventos de notificacin: para notificar a
procesos interesados en ciertos eventos que estos tuvieron lugar
(jini)
Fallas en Multicast
Ya que se basa en UDP puede pasar :
Tolerancia a fallas basada en la replicacin 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 localizacin 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
Propagacin de eventos de notificacin: El servicio de anuncio
acerca de nuevos servicios en la red provisto por Jini envia
mensajes multicast reiterativos a tiempos regulares
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); }
catch (InterruptedException e) {
try {
}
Thread.currentThread().sleep(200); }
}
catch (InterruptedException e) {}
}
}
}
} catch (IOException e) {}
}
}
Reliable Multicast
Reliable multicast implica que se cumplen 3 propiedades:
Integridad: el mensaje que se manda es igual al que se
procesa y que ningn mensaje es procesado dos veces. Un
proceso p hace la operacin 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 tambin lo har