Nivel 4: Transporte Protocolos End-to-End Teoría de las Comunicaciones – Octubre de 2011

Nivel de Red milagros.dc.uba.ar stone.ac.upc.es Nivel de Red Nivel de Enlace HD HD HD HDHD HD Host a Host

Nivel de Transporte EnriLean Nivel de Red Nivel de Enlace Nivel de Aplicación Nivel de Transporte O.S. HeaderDataHeaderData HD HD HD HDHD HD Canal Proceso a Proceso milagros.dc.uba.ar stone.ac.upc.es

Modelo OSI Session Network Link Physical Application Presentation Transport Network Link Network Transport Session Presentation Application Network Link Physical Peer-layer communication layer-to-layer communication Router

Modelo TCP/IP / UDP Datagram

Protocolos End-to-End Se apoyan en la Capa de Red, la cual es de mejor esfuerzo (Best-Effort) –Descarta mensajes –Reordena mensajes –Puede entregar múltiples copias de un mensaje dado –Limita los mensajes a algún tamaño finito –Entrega mensajes después de un tiempo arbitrariamente largo Sin embargo, pretendemos otro tipo de Servicios End-to-End para las Aplicaciones –Garantía de entrega de mensajes –Entrega de mensajes en el mismo orden que son enviados –Entrega de no más de una copia de cada mensaje –Soporte para mensajes arbitrariamente largos –Soporte de sincronización –Permitir al receptor controlar el flujo de datos del transmisor –Soportar múltiples procesos de nivel aplicación en cada máquina Protocolos End-to-End: Algoritmos para proveer “Sevicios End-to-End sobre Servicios de Red Best Effort”

Primer paso: Servicio No Confiable de Entrega de Mensajes Proceso a Proceso Comunicación no costosa entre procesos –Soportar múltiples procesos de nivel aplicación en cada máquina –Evitar la sobrecarga y las demoras propias de la entrega ordenada y confiable de mensajes –Enviar mensajes desde y hacia sockets (“enchufes”) User Datagram Protocol (UDP) –IP + Número de Puerto (socket) para proveer demultiplexado hacia procesos destino –Control de error opcional

El Demultiplexor Simple UDP: User Datagram Protocol Provee comunicación Proceso a Proceso Multiplexación/demultiplexación de mensajes -> Múltiples Procesos compartiendo la misma red. SrcPortDstPort ChecksumLength Data UDP Message QueuesUDP Message Header (8 bytes)  ?

Características de UDP Servicio de entrega no confiable y no ordenado de datagramas Sin control de congestión –No reacciona ante señalizaciones de estado de congestión –Puede congestionar las colas de entrada y salida en los routers -> Tráfico egoísta –Soluciones posibles: Implementar el control de congestión en las Capas de Aplicación Implementar el control de congestión en los Routers –DCCP (Datagram Congestion Control Protocol) (experimental) No provee Control de Flujo –El destinatario puede verse saturado, perdiendo información No establece una conexión … mantiene varias características best-effort de IP !

Razones para adoptar UDP Control preciso sobre qué información se envía y cuándo se envía –Inmediatamente que un proceso escribe en el socket –… UDP lo empaqueta y lo envía a IP Sin demoras para establecimiento de conexión –UDP no contempla ningún procedimiento preliminar formal –… los cual evita cualquier tipo de demora extra Sin “estado de conexión” –No se reservan parámetros, números de secuencia, etc. –… lo cual facilita manipular muchos clientes activos simultáneamente Pequeño overhead por encabezado –UDP header de solo 8 bytes

Puertos y Aplicaciones UDP maneja Puertos definidos en cada extremo. (2^16 Ports) –El lado servidor posee (“expone”) puertos “bien conocidos” –Ver numbers/service-names-port-numbers.xml –En un host Linux ver /etc/services –Ej: smtp 25/tcp mail Utilizando getservicebyname() : pedro:~# telnet miservidor smtp Trying Connected to miservidor. Escape character is '^]'. 220 miservidor ESMTP Sendmail 8.9.1b+Sun/8.9.1; Sun, 31 Oct :43:20 GMT quit 221 miservidor closing connection Connection closed by foreign host. pedro:~# pedro:~# telnet miservidor 25 Trying Connected to miservidor. Escape character is '^]'. 220 miservidor ESMTP Sendmail 8.9.1b+Sun/8.9.1; Sun, 31 Oct :43:06 GMT quit 221 miservidor closing connection Connection closed by foreign host. pedro:~# pedromiservidor IANA: Internet Assigned Numbers Authority

Puertos y Rangos …

Aplicaciones DHCPNTPVoIP

User process Web server (port 80) Client host Server host Echo server (port 7) Service request for socket (i.e., the Web server) Web server (port 80) Echo server (port 7) Service request for socket (i.e., the echo server) OS Client Client host Server Socket Client Socket Canal Proceso a Proceso:

VersionHLen TOSLength IdentFlagsOffset TTLProtocolChecksum SourceAddr DestinationAddr Options (variable) Pad (variable) Contexto para encabezado UDP SrcPortDstPort ChecksumLength Data IP UDP Pseudo encabezado Largo de encabezado + datos (UDP) – 8 (UDPh) – 20 (IPh) = (UDPd) Chequeo de suma opcional: Psuedo header (IP) + UDP header + Data

Máquinas de Estado Port asignado automáticamente por el kernel Cada socket UDP provee un modelo de Server iterativo El buffer de recepción opera en modo FIFO Cuando el proceso llama recvfrom(), obtiene el datagrama tomado con disciplina FIFO. Buffer limitado Cada socket UDP provee un modelo de Server iterativo El buffer de recepción opera en modo FIFO Cuando el proceso llama recvfrom(), obtiene el datagrama tomado con disciplina FIFO. Buffer limitado

udp-client.c #include int main(int argc, char**argv) { int sockfd,n; struct sockaddr_in servaddr,cliaddr; char sendline[1000]; char recvline[1000]; // Leo los argumentos de la linea de comando. if (argc != 3) { Uso: udp-client printf("Uso: udp-client \n"); exit(1); } // Creo un socket de UDP (SOCK_DGRAM). sockfd=socket(AF_INET,SOCK_DGRAM,0); // Especifico la dirección y puerto del servidor. bzero(&servaddr,sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr=inet_addr(argv[1]); servaddr.sin_port=htons(atoi(argv[2])); // Envio y recibo mensajes hasta que el usuario entre CTRL-D. while (fgets(sendline,10000,stdin)!= NULL) { sendto(sockfd,sendline,strlen(sendline),0, (struct sockaddr *)&servaddr,sizeof(servaddr)); // Me bloqueo, esperando un mensaje. n=recvfrom(sockfd,recvline,10000,0,NULL,NULL); recvline[n]=0; fputs(recvline,stdout); } socket pointer to buffer for data size of buffer flags MSG_PEEK, MSG_OOB, MSG_WAITALL address struct of sending peer length of address struct of sending peer socket pointer to buffer for data size of buffer flags MSG_PEEK, MSG_OOB, MSG_WAITALL address struct of sending peer length of address struct of sending peer Si no se especifica MSG_WAITALL se devolverá solamente los bytes hasta el final del primer mensaje.

udp-server.c #include int main(int argc, char**argv) { int sockfd,n; struct sockaddr_in servaddr,cliaddr; socklen_t len; char mesg[1000]; // Leo los argumentos de la linea de comando. if (argc != 2) { Uso: udp-server \n printf("Uso: udp-server \n"); exit(1); } // Creo un socket de UDP (SOCK_DGRAM). sockfd=socket(AF_INET,SOCK_DGRAM,0); // Ligo el socket al puerto elegido. bzero(&servaddr,sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr=htonl(INADDR_ANY); servaddr.sin_port=htons(atoi(argv[1])); bind(sockfd,(struct sockaddr *)&servaddr,sizeof(servaddr)); for (;;) { len = sizeof(cliaddr); // Me bloqueo, esperando un mensaje. printf("Esperando un mensaje...\n"); n = recvfrom(sockfd,mesg,1000,0,(struct sockaddr *)&cliaddr,&len); // Llegó un mensaje; envio respuesta al cliente. sendto(sockfd,mesg,n,0,(struct sockaddr *)&cliaddr,sizeof(cliaddr)); mesg[n] = 0; Mensaje recibido: %s",mesg printf("Mensaje recibido: %s",mesg); } }

Multicast y Broadcast TCP y UDP UDP Solamente con UDP No es posible con TCP –Sería ineficiente sostener para cada posible host destino (es decir, para cada “conexión”) los mecanismos de retransmisión, ordenamiento de paquetes, control de flujo, etc. –Atentaría contra el objetivo principal de aliviar la utilización de la red –Imposible sostener una conexión con estado, ya que se desconoce el destino

Otro protocolo de transporte: Remote Procedure Call (RPC) Paradigma clásico de Pedido/Respuesta o Transacción orientada a Mensajes Mecanismo bien conocido para estructurar sistemas distribuidos Abstrae las llamadas locales: El Server puede ser local o remoto El Cliente se bloquea esperando la respuesta No alcanza con UDP: Se deben identificar los correctos procesos en los hosts destino y origen para entregar debidamente pedidos y respuestas. TCP podría solucionarlo, pero a un costo demasiado alto (overhead) RPC es confiable y soporta tamaños grandes de mensajes. Implementaciones más conocidas: SunRPC, DCE-RPC

Mapeo Automático de Puertos Puerto bien Conocido (111)

Real Time Protocol (RTP) UDP ideal por su simpleza y bajo overhead RTP sobre UDP Aplicaciones (voz, video) con requerimientos temporales estrictos (80’s) Información de tiempo (timestamps) Orden Tipo de codificación/compresión de la señal analógica Negociación RTCP (Control) (<5% del BW RTP) Información periódica de control acerca del flujo RTP Performance Sincronización Identidad

Real Time Protocol (RTP) RTP + RTCP (Control) (<5% del BW RTP) Información periódica de control acerca del flujo RTP Performance Sincronización Identidad +RTCP