67
COMUNICACIÓN EN SISTEMAS COMUNICACIÓN EN SISTEMAS DISTRIBUIDOS DISTRIBUIDOS Sistemas Operativos Avanzados UTN-FRSF Tomado de: Sistemas Operativos Distribuidos - A.S.Tanenbaum Capítulo 2

SOA02- Comunicacion en Sistemas Distribuidos (Tanenbaum-Capitulo 2)

  • Upload
    des-mtz

  • View
    65

  • Download
    10

Embed Size (px)

Citation preview

  • COMUNICACIN EN SISTEMAS DISTRIBUIDOSSistemas Operativos Avanzados UTN-FRSF

    Tomado de: Sistemas Operativos Distribuidos - A.S.TanenbaumCaptulo 2

  • Modelo Cliente - ServidorProtocolo Request-Reply. Redes WAN:TCP/IP OSIRedes LAN: Protocolos de 3 capas Menor overhead

  • Modelo Cliente - ServidorSe usan slo 3 capas:FsicaEnlaceREQUEST/REPLYServicio provistos por microkernelSend()Receive()

  • Modelo Cliente - ServidorCaractersticas DireccionamientoPrimitivas con y sin BloqueoPrimitivas con y sin BufferPrimitivas Confiables y no Confiables

  • DireccionamientoEsttico (Mquina.Proceso)Requerimiento por BroadcastServidor de nombres

  • Esttico (mquina.proceso)VentajaLocalizacin directa, rpida.DesventajasNo tolerante a fallosNo EscalableCambio direccin Servidor => recompilar

  • Requerimiento por BroadcastVentajaDireccionam. dinmico.Mayor flexibilidad.Mayor transparencia.DesventajaSe necesita localizar al servidor.Perdida de tiempo en la localizacin.Muy costoso, sobrecarga el sistema.

  • Servidor de nombresVentajaDireccionamiento dinmico.Mayor flexibilidad.Mayor transparencia.Evita sobrecarga al sistema.DesventajaConocer direccin.Componente centralizado.SobrecargaUnico punto de fallo

  • Primitivas con bloqueo vs. sin bloqueoSend() con bloqueoCPU ociosa durante la transmisin del mensaje.Pueden usarse timeouts

  • Primitivas con bloqueo vs. sin bloqueoSend() sin bloqueo con copiaTiempo de CPU desperdiciado por copia extra.

  • Primitivas con bloqueo vs. sin bloqueoSend() sin bloqueo con interrupcionesDificulta la programacin.

  • Primitivas con bloqueo vs. sin bloqueoReceive() con bloqueoCPU ociosa mientras esperaWait()Test()Receive() condicional puede especificarse timeoutdevuelve el mensaje una seal de falla.

  • Primitivas con y sin bufferQue pasa cuando ser recibe un mensaje y el receptor no lo est esperando?Se lo descarta ?Se lo almacena ?Hasta cuando ?A quien descarto cuando el buffer est lleno? Al primero que llego?Al ltimo que llego

    ???

  • Primitivas con y sin bufferCon buffer (buzones)Un buzn por proceso para recibir mensajes.Mantiene los mensajes hasta que recibidosLos buzones son finitos y pueden llenarse.

  • Primitivas con y sin bufferSin buffer (2 casos)1. Si no hay Receive(), se descarta2. Los conserva esperando el Receive() del servidor

  • Primitivas confiables vs. no confiablesNo confiableSin ningn tipo de confirmacin.Confiable4 mensajes 3 mensajes

  • Resmen

    Caractersticas

    Opcin 1

    Opcin 2

    Opcin 3

    Direccionamiento

    Esttico Mquina.proceso

    Broadcast

    Servidor de Nombres

    Bloqueo

    Con bloqueo

    Sin bloqueo, con copia al kernel

    Sin bloqueo, con interrupcin

    Buffer

    Sin buffer, descarte de mens.

    Sin buffer, guardando temp.

    Con buffer (buzones)

    Confirmacin

    No Confiable

    Req Ack Resp Ack

    Req Resp - Ack

  • Llamada a Procedimientos Remotos (RPC)

    Objetivo: Transparencia

  • RPC - Como funciona LPCread(fd, buf, bytes);

  • RPC - Diagrama

  • RPC - Diagrama

  • RPC - Paso de ParmetrosEl stub cliente empaca los parmetros, en el mensaje (parameter marshaling).Los parmetros deben convertirse a un formato entendible por las dos partes. (XDR/ASN.1)Representacin de los tipos en ambos extremosA un tipo estndar en ambos extremos => 2 Transformacin Al tipo de uno de los extremos => 1 Transformacin

  • RPC - Paso de ParmetrosPasaje de parmetros por referencia y uso de punterosProhibirlo (altamente indeseable).Sustituir por el paso de parmetros por valor de entrada, salida o ambos, para casos simples.An no se pueden manipular estructuras complejas.

  • RPC: Enlace Dinmico

  • RPC: Enlace Dinmico

  • RPC: Enlace DinmicoVentajasLocalizacin dinmica del servidor.Utilizacin de un binder (vinculador) de interfaces.Registra los servidores, la versin, un identificador nico, y un handle (ej. direccion IP)Testea que estn funcionando correctamente.Puede manipular varios servidores.Independencia de clientes y servidores.

  • RPC: Enlace DinmicoDesventajaEl binder se trasforma en un cuello de botella.Aporta carga extra al sistema, por el costo de exportar e importar interfaces.Dificultades asociadas al mantenimiento de rplicas.

  • RPC: Enlace DinmicoServidorSe registra en el binder cuando comienza a brindar servicio.Se desregistra explcitamente cuando ya no est preparado para brindar el servicio.Se desregistra implcitamente cuando el binder detecta alguna falla en el servidor registrado.

  • RPC: Enlace DinmicoCliente (stub)Ejecuta un procedimiento remoto, sino esta vinculado a un servidor, se contacta con el binder.El binder busca en la base de datos, sino encuentra el servidor solicitado, retorna error.Si encuentra el servidor solicitado, retorna el handle y el identificador nico.

  • RPC Asincrnico

  • RPC Asincrnico

  • RPC - FallasPosibles FallasEl cliente no es capaz de localizar al servidor.El mensaje de REQUEST se pierde.El mensaje de REPLY se pierde.El Server falla despus de recibir un REQUEST.El cliente falla despus de enviar un REQUEST.

  • RPC - FallasCliente no puede localizar el ServerRespuesta con un valor invlido.Utilizar manejo de excepciones.Prdida de mensajes REQUESTTimer para intentar nuevamente, despus de un nmero de veces concluye que el servidor est cado.

  • RPC - FallasPrdida de mensajes REPLYUtiliza un timer no puede determinar si el REQUEST lleg o no.No funciona para REQUESTno idempotentesSe utilizan nmeros de secuencia, e identificacin del mensaje original o de la retransmisin.

  • RPC - FallasCada del servidor

  • RPC - FallasCada del servidorProblemas con REQUEST no idempotentes.Al menos una vez.Como mucho una vez.No garantizar nada.Exactamente una vez (el ideal)Posibles conflictos:Caso 1: Recibe, ejecuta, crash.Caso 2: Recibe, crash.El cliente no sabe a que caso se refiere slo expira su timer

  • RPC - FallasCada del clienteEste caso es el de una llamada hurfana.Problemas:Ciclos de CPU desperdiciados.Posibles archivos bloqueados.

  • RPC - FallasCada del clienteSoluciones :Exterminacin (log antes de enviar llamada RPC)Reencarnacin (broadcast de epoca)Reencarnacin Gentil (idem intenta localizar cliente)Expiracin (se le asigna un perido T para finalizar)En la prctica ninguno de estos mtodos es deseableEl peor es matar un proceso hurfano, puede traer consecuencia imprevistas.

  • ImplementacinEl xito de un sistema distribuido depende a menudo de su performance.La performance es muy dependiente de la velocidad de las comunicaciones.

  • ImplementacinProtocolo RPCOrientado a la conexinAspectos Resueltos por el protocolo de TransportePrdida de performance sobre LANNo orientado a la conexinMs complejo, debe hacer lo que el protocolo de Trasporte no haceEs el ms usado sobre una red tipo LAN

  • ImplementacinProtocolo de RPCUDP sobre IPEl protocolo ya est diseadoMuchas implementaciones estn disponiblesLa mayora de los sistemas usan este protocoloLos paquetes IP y UDP son soportados por la mayora de las redesUso especficoMejor performanceDiseado especficamente para RPCTamao de los paquetes o mensajesOverhead independiente del tamaos de datos a enviar

  • ImplementacinConfirmaciones (ACK)Protocolo de Start/StopProtocolo de RfagaProtocolo de Repeticin SelectivaControl de flujoError de OverrunEl receptor est ocupado procesando paqueteEl buffer de entrada esta lleno

  • ImplementacinCamino Crtico

  • ImplementacinCamino Crtico (sin parmetros)

  • ImplementacinCamino Crtico (con parmetros)

  • ImplementacinTiempo de Copia

    Copia 1 - Stub del cliente al buffer del KernelCopia 2 - Buffer del Kernel al buffer del chip de redCopia 3 - De la red al buffer del chip de red de la maquina destinoCopia 4 - Del chip de red al buffer del KernelCopia 5 - Del buffer del Kernel al stub del Server

  • Implementacin

  • ImplementacinAdministracin de relojesDebido a la prdida de paquetes en la red se deben tener relojes para verificar el timeout de la transmisin de un paquete, para su retransmisinPara sto existen dos soluciones:una lista ordenada por tiempo de vencimiento.una tabla por procesos teniendo el tiempo de vencimiento para la retransmisin.

  • Implementacinreas Problemticas

    Variables GlobalesLenguajes con comprobacin dbil de tiposPunterosPipe (Tuberas)

  • Programacin con RPC/* remote_users.c - Client program for the remote users service. */#include #include #include "remote.h"

    main(argc, argv)int argc;char *argv[];{ CLIENT *cl; char *server; char **sresult;

    server = argv[1]; if ((cl = clnt_create(server, REMOTE_PROG, REMOTE_VERS, "udp")) == NULL){ clnt_pcreateerror(server); exit(2); }if ((sresult = remote_users_1(NULL, cl)) == NULL){ clnt_perror(cl, server); exit(3); } printf("Users logging on Server %s\n%s\n", server, *sresult);

    clnt_destroy(cl); exit(0);}

  • Programacin con RPC/* remote_server.c - remote procedure called by server stub */#include #include #include

    #include #include "remote.h"

    char **remote_users_1(){ static char *ptr; FILE *fp; struct utmp tmp; char buffer[1024]; char tmp_buff[10];

    buffer[0] = '\0'; fp = fopen("/etc/utmp", "rb"); while (!feof(fp)){ fread(&tmp, sizeof(struct utmp), 1, fp); if (strlen(tmp.ut_name)){ sprintf(tmp_buff, "%.8s ", tmp.ut_name); strcat(buffer, tmp_buff); } } fclose(fp); ptr = buffer; return(&ptr);}

  • Programacin con RPC

  • Programacin con RPCClient-Server Application using RPCremote.xremote_server.cremote_users.cremote_svc.cremote.hremote_clnt.cremote_serverremote_usersRPCrun-timeLibraryrpcgenserver stubclient stubccccserver programclient programserver procedure

  • Programacin con RPCUse rpcgen para generar remote.h, remote_svc.c, remote_clnt.c rpcgen remote.xPara compilar el programa server: cc -o remote_server remote_server.c remote_svc.c -lrpcsvcPara compilar el programa cliente: cc -o remote_users remote_users.c remote_clnt.c -lrpcsvc

    /* remote.x */program REMOTE_PROG { version REMOTE_VERS { string REMOTE_USERS(void) = 1; } = 1;} = 0x32345678;

  • Comunicacin de GruposIntroduccinConjunto de procesos que actan juntos en un sistemaSi se enva un mensaje al grupo todos lo recibenComunicacin uno a muchosLos grupos son dinmicoscrear destruir agregar integrantesborrar integrantes

  • Comunicacin de GruposIntroduccinUn proceso puede participar de varios gruposSe necesita una administracin de gruposMulticasting (propiedad de algunas redes)Direccin especial de red (direccin de grupo)Mltiples mquinas adheridas a esta direccinTodos reciben los paquetes enviados a esta direccin

  • Comunicacin de GruposBroadcastingDireccin para todas las mquinas de una redSe puede usar para implementar grupos pero es menos eficienteSe chequea por software si el paquete pertenece a algn grupo de la mquina o, sino se descartaInterrupciones desperdiciadas por los paquetes no pertenecientes al grupo

  • Comunicacin de GruposUnicastingEs la comunicacin punto a puntoSe puede implementar la comunicacin de grupos pero se necesitaran N paquetes para un grupo con N integrantes

  • Comunicacin de GruposGrupos Cerrados o AbiertosGrupos CerradosSlo los miembros pueden enviar mensajes al grupoExternos al grupo no pueden enviar mensajes al grupo, slo a miembros individualesTpicamente usados para procesamiento paraleloGrupos AbiertosCualquier integrante del sistema pertenezca o no del grupo puede enviar un mensaje al grupoEs muy usado para soportar la replicacin de servidores

  • Comunicacin de GruposGrupos Todos con TodosTodos los integrantes son igualesLas decisiones se toman en conjuntoVentajaNo tiene un punto de falla, si uno falla el grupo se hace ms pequeo pero puede continuar trabajandoDesventajaLa toma de decisiones se hace muy complicada, la votacin demora el sistema

  • Comunicacin de GruposGrupos JerrquicoExiste un coordinadorLas decisiones son tomadas por el coordinadorVentajaLas decisiones son rpidasDesventajaSi se cae el coordinador puede llegar a caerse el sistema sino existe uno de respaldo

  • Comunicacin de GruposMembresaServidor de GruposAdministracin distribuidaProblemasCuando un integrante se cae, deja de pertenecer al grupo o noLos mensajes que recibe un integrante cuando se une al grupo y cuando deja de pertenecer al grupoCuando se cae el grupo por completo o casi completo

  • Comunicacin de GruposDireccionamiento de GrupoMulticastBroadcastUnicastLista con las mquinas que pertenecen al grupo (ineficiente administracin)Direccionamiento por predicado

  • Comunicacin de GruposPrimitivasIdealmente podran ser las mismas que para una comunicacin normal, dependiendo de la direccin, se comportaran distinto, si es de grupo o noProblemas para mezclar con primitivas de RPCun envo tendra muchas respuestasun proceso no puede enviar y recibir al mismo tiempoEn la prctica por lo general existen primitivas diferentes, para grupos y para procesos individuales

  • Comunicacin de GruposAtomicidad o Broadcast atmicoTodos los integrantes del grupo tienen que recibir el paquete de lo contrario ninguno tiene que recibirloEs deseable porque hace la comunicacin distribuida ms fcilAlgoritmos para asegurar el Broadcast atmico

  • Comunicacin de GruposOrden de los MensajesFIFO: los mensajes de un mismo origen son recibidos en orden por todos los miembros.Orden de Tiempo Global: los mensajes son recibidos en el mismo orden en que fueron enviados.Orden de Tiempo Consistente: los mensajes pueden no ser recibidos en el mismo orden en que fueron enviados, pero todos los integrantes del grupo los reciben en el mismo orden

  • Comunicacin de GruposEscalabilidadProblemas que puede enfrentar un sistema de comunicacin grupalTamao de los gruposCantidad de gruposDependencia del HW, como por ejemplo una LANUso de Gateways