PTMF

PTMFPTMF

Protocolo de Transporte Multicast FiableProtocolo de Transporte Multicast Fiable

Exposición:Exposición:

I. Introducción

II. Especificación Protocolo Control del Grupo Local (CGL) Control de la Fiabilidad

III. Implementación

IV. FTPMulticast

V. ChatMulticast

MulticastMulticast

Técnica que permite que copias de un solo paquete se transfieran a un subconjunto seleccionado de todos los posibles destinos

MBoneMBone

Red con capacidad multicast

IP Multicast (host)IP Multicast (host)

Dirección IP de Clase D

224.0.0.0 – 239.255.255.255

IP

ICMP IGMP

IP Multicast (routers)IP Multicast (routers)

IGMPProtocolo de encaminamiento

Multicast para direcciones IP Multicast

– DVMRP, PIM (PIM-DM , PIM-SM)IGMP

MBone laboratorioMBone laboratorio

150.214.142.138

150.214.142.153150.214.142.145

150.214.142.130

150.214.142.160

150.214.142.137150.214.142.129

LANE Informática (150.214.142.0)

Laboratorio de Tecnología Electrónica

LabtecMR2 LabtecMR3

Subred: 150.214.142.128Máscara: 255.255.255.248Broadcast: 150.214.142.135



Subred: 150.214.142.136Máscara: 255.255.255.248Broadcast: 150.214.143

.140 .142

.146 .148

Proxy ARP

.133 .134.131 .132

.149 .150 .155 .156.154 .157 .158

.139 .141

Subred transparente “PTMF”: 150.214.142.128Máscara: 255.255.255.224

LabtecMR1

.147

Ventajas de utilizar Multicast:Ventajas de utilizar Multicast:

Transmitir información a múltiples receptores sin duplicar la información enviada para cada uno de ellos.

Reducción del Ancho de Banda

Reducción del Ancho de Banda Reducción del Ancho de Banda (18 receptores)(18 receptores)

0

100

200

300

400

500

600

Mb

Tx. UNICAST 540

Tx. MULTICAST 30

1

Reducción del Tiempo de tx.Reducción del Tiempo de tx.

12

34

PTMF

Windows 0.00.00

0.00.17

0.00.35

0.00.52

0.01.09

0.01.26

0.01.44

0.02.01

0.02.18

0.02.36

0.02.53

0.03.10

Tie

mp

o

Nº de Receptores

FTPMulticast utilizando PTMF - Windows 1 Emisor - 4 Receptores

PTMF 0.01.08 0.01.09 0.01.12 0.01.14

Windows 0.01.30 0.01.58 0.02.27 0.03.10

1 2 3 4

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

0.00.00

0.01.26

0.02.53

0.04.19

0.05.46

0.07.12

0.08.38

0.10.05

0.11.31

Tie

mp

o

Nº de receptores

FTPMulticast utilizando PTMF - Windows 1 Emisor - 18 Receptores

Aplicaciones para uso MulticastAplicaciones para uso Multicast

Todo tipo de aplicaciones que necesite transferir la misma información a más de un receptor.

Aplicaciones MulticastAplicaciones Multicast

Videoconferencia (NxN)Multidifusión de video (1xN)Multidifusión de audio (1xN) Transferencia de ficherosMultidifusión de mensajes (chat)...

Situación ActualSituación Actual

Aplicaciones Multicast que realizan:– control de la fiabilidad– control de flujo– control de la congestión

Características propias de un protocolo del nivel de transporte

Campo abierto de investigación:Campo abierto de investigación:

Protocolos de Transporte Multicast Fiable

– Ej: RMTP, TMTP, LGC.

Muchos de estos protocolo presentan limitaciones en cuanto a escalabilidad, incorporación de nuevos miembros a una comunicación en curso, rendimiento, ...

PTMFPTMF

PTMF recoge ideas importantes PTMF recoge ideas importantes de otros protocolos precursores de otros protocolos precursores y aporta otras nuevas e y aporta otras nuevas e innovadoras.innovadoras.

Características de PTMF:Características de PTMF:

1. Nivel de transporte (nivel 4 OSI)

2. Uso de IP Multicast en el nivel de red

TCP /UDP PTMF

IP Multicast

IP Multicast

Nivel 2 Nivel 2

Nivel 1 Nivel 1

Características de PTMFCaracterísticas de PTMF

1. Escalabilidad utilizando técnicas basadas en Grupos Locales jerárquicos.

2. Control de Errores Distribuido.

3. Control de Fiabilidad Híbrido (orientado al emisor y al receptor).

4. Control de Flujo.5. Control de la Congestión.

6. Seguridad mediante criptografía de los TPDUs

Características de PTMFCaracterísticas de PTMF

7. Incorporación de nuevos miembros a la conexión en curso.

8. Posibilidad de múltiples unidades de transferencia en una conexión.

9. Parametrizable.

10. Capacidad NxN (muchos a muchos).

11. Asentimientos Multicast y Unicast.

12. Retransmisiones Multicast y Unicast

DireccionamientoDireccionamiento

PTMF utiliza un TSAP o puerto de 16 bits para demultiplexar varias conexiones Multicast.

– Pueden existir 65.536 procesos en una misma máquina utilizando PTMF

TPDU PTMFTPDU PTMF

0 1 2 3 4 5 6 7 8 910

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Puerto Multicast Puerto Unicast

ID_GRUPO_LOCAL (4 bytes primeros)

ID_GRUPO_LOCAL (2 bytes últimos) Longitud

Cheksum V Tipo

Situación Multicast típicaSituación Multicast típica

Estrategias para el Control de la Estrategias para el Control de la FiabilidadFiabilidad

1. Orientada al Emisorel control de la fiabilidad recae en el Emisor, este suele utilizar técnicas basadas en el uso de asentimientos positivos (ACK).

2. Orientada al Receptorel control de la fiabilidad recae en el receptor, este suele utilizar técnicas basadas en el uso de asentimientos negativos (NACK).

Problemas “orientada al emisor”Problemas “orientada al emisor”

a. Reducción del Ancho de Banda por el excesivo nº de ACKs

b. Sobrecarga del Emisor por el procesamiento de todos estos ACKs

Problema conocido como: “Implosión de ACKs”

Implosión de ACKsImplosión de ACKs

Problemas “orientada al Problemas “orientada al receptor”receptor”

a. El emisor debe de mantener los TPDUs enviados en memoria

para posibles retransmisiones durante un tiempo indeterminado, pues no hay mecanismos que indiquen la correcta recepción de los datos por parte de los receptores y que permita así liberar memoria al emisor.

PTMF resuelve utilizando:PTMF resuelve utilizando:

1.1. El Protocolo CGLEl Protocolo CGL

Que organiza a los participantes en la comunicación Multicast de forma que el proceso de asentimiento sea más eficaz.

PTMF resuelve utilizando:PTMF resuelve utilizando:

2.2. Estrategia de Control de Fiabilidad Estrategia de Control de Fiabilidad HíbridaHíbrida.

Lo mejor de ambas aproximaciones:

Orientada al Emisor

+

Orientada al Receptor


I. Introducción II. Especificación Protocolo

Control del Grupo Local (CGL) Control de la Fiabilidad


IV. FTPMulticast

V. ChatMulticast

CGL CGL Control del Grupo Local Control del Grupo Local

PTMF

CGL

Grupo LocalGrupo Local

Un conjunto de sockets presentes en un determinado Canal Multicast y Ámbito que cooperan entre sí para garantizar la fiabilidad del protocolo PTMF y conseguir con su organización una mayor eficacia del proceso de asentimientos.

Identificador de Grupo Local Identificador de Grupo Local (IDGL)(IDGL)

IDGL = IPv4 + Puerto Unicast

Función de CGLFunción de CGL

Organizar los SocketsPTMF presentes en un determinado Canal Multicast y Ámbito en Grupos Locales establecidos de forma jerárquica para que el Control de la Fiabilidad se realice de forma eficiente.

Organizar en Grupos LocalesOrganizar en Grupos Locales

MisiónMisión del Controlador de Grupo (CG) del Controlador de Grupo (CG)

Actuar como si fuese el emisor e informar a sus CG superiores en el árbol o al emisor en última instancia, de la correcta recepción de los datos dentro del grupo local (retransmisiones, control de los receptores, ...) enviando:

Asentimientos positivos jerárquicos (HACK)

Grupos Locales jerárquicosGrupos Locales jerárquicos

Se consigue:Se consigue:

1.Reservar lo máximo posible el Ancho de Banda de las líneas de comunicación.

2.Evitar la saturación del Emisor por procesamiento de la avalancha de ACKs

evitando el “cuello de botella” en el lado del emisor por procesamiento de ACKs

Cabecera común TPDUs CGLCabecera común TPDUs CGL

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31



ID_GRUPO_LOCAL (2 bytes últimos)

Longitud

Cheksum V 0 0 Subtipo TTL

Métrica

IP

N_SECUENCIA Nº Ids

Nº MAX de Sockets/GL Nº de Sockets en GL

Cabecera Común TPDU PTMF Cabecera Común subtipo CGL

TPDU CGL ( IP = 0 )TPDU CGL ( IP = 0 )0 1 2 3 4 5 6 7 8 9 1

011

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31





Métrica

IP=0

N_SECUENCIA Nº Ids


ID_GRUPO_LOCAL 1 (32 primeros bis)

ID_GRUPO_LOCAL 1 (16 bits últimos)

TTL VECINO 1 ID_GRUPO_LOCAL 2 (16 bits primeros)

ID_GRUPO_LOCAL 2 (32 bits últimos) TTL VECINO 2

....

TPDU CGL ( IP = 1)TPDU CGL ( IP = 1)0 1 2 3 4 5 6 7 8 9 1

011

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31





Métrica

IP=1

N_SECUENCIA Nº Ids


IP 1

Puerto Unicast 1 IP N (2 primeros bytes)

IP N (2 bytes últimos) Puerto Unicast N

Descubrir Grupos LocalesDescubrir Grupos Locales

4BUSCAR_GRUPO_LOCAL

TTL = 1

Notificar Grupo LocalNotificar Grupo Local

Si el GL no supera MAX_Sockets_GL:

4 321

GL GRUPO_LOCAL {Lista de IDGLs a los que alcanza}

Unirse a un Grupo LocalUnirse a un Grupo Local

4 321

UNIRSE_A_GRUPO_LOCAL

{ID_Socket emisor}

GL

Aceptación de un Socket en el GLAceptación de un Socket en el GL

4 321

SOCKET_ACEPTADO_EN_GRUPO_LOCAL

{ID_Socket petición, lista de ID_Sockets miembros del GL}

GL

Miembro del GLMiembro del GL

3214

GL

Creación de un Grupo LocalCreación de un Grupo Local

5GRUPO_LOCAL

{TTL = 1

Nuevo IDGL}

IDGL = IPv4 + Puerto Unicast

Dejar el Grupo LocalDejar el Grupo Local

4DEJAR_GRUPO_LOCAL

{ID_Socket saliente,

Lista de ID_Sockets del GL}

Eliminación de un Grupo LocalEliminación de un Grupo Local

El último miembro del GL envía:

1 ELIMINACION_GRUPO_LOCAL

Búsqueda de GL “Vecinos”Búsqueda de GL “Vecinos”

Los GL “vecinos” se descubren mediante un proceso de “Expansión en Anillo”“Expansión en Anillo”

1 BUSCAR_GRUPO_LOCAL_VECINO

TTL = 1

TTL = 2

TTL = 4

...

Finalización búsqueda GL “vecinos”Finalización búsqueda GL “vecinos”

11 Recibido un TPDU GRUPO_LOCAL_VECINO

2. Se aumenta el “anillo de expansión” “anillo de expansión” hasta llegar al TTL de la sesión

Notificación de GL “vecino”Notificación de GL “vecino”

1GRUPO_LOCAL_VECINO

{TTL = el del TPDU BUSCAR_GRUPO_LOCAL_VECINO recibido

Lista de IDGLs vecinos que este GL conoce. El primer IDGL es el del GL que realizó la búsqueda}

Algoritmo para el cálculo de GL padres e Algoritmo para el cálculo de GL padres e

Hijos según un emisor dadoHijos según un emisor dado..

¿Qué GL o Gls me proporcionan fiabilidad para ese emisor, es decir, a quien tengo que enviar HACK o HNACK?, pero no solo esto, sino más concretamente la pregunta que necesita saber

PTMF es: ¿A qué distancia (TTL) tengo que enviar el ¿A qué distancia (TTL) tengo que enviar el HACK o HNACK MULTICAST de los HACK o HNACK MULTICAST de los asentimientos positivos o negativos?asentimientos positivos o negativos?

¿Existe algún GL “Hijo” que depende de mí para ¿Existe algún GL “Hijo” que depende de mí para garantizar la fiabilidad cuando emite un garantizar la fiabilidad cuando emite un determinado Emisor? ¿Cuáles son esos GL Hijos?determinado Emisor? ¿Cuáles son esos GL Hijos?

Búsqueda de un GL para un EmisorBúsqueda de un GL para un Emisor

Casos en los que un GL no conoce a que GLs en la jerarquía tiene que mandar asentimiento

1 BUSCAR_GL_EMISOR

TTL = MAX{TTL Emisor, TTL Sesión}

Respuesta a una búsqueda de GL para un emisorRespuesta a una búsqueda de GL para un emisor

1GL_PARA_EMISOR

{TTL el del TPDU BUSCAR_GL_PARA_EMISOR,

Lista de IDGLs a los que alcanza este GL}

Si se recibe el TPDU BUSCAR_GL_PARA_EMISOR y el GL buscado es GL “Hijo” de este GL:

Máquina de estados CGLMáquina de estados CGL





IV. FTPMulticast

V. ChatMulticast

Control De La FiabilidadControl De La Fiabilidad

Todos los miembros cooperan para asegurar la fiabilidad.

Control híbrido de la fiabilidad:Orientado Emisor: Espera

asentimientos positivos.Orientado Receptor: Solicita los datos

no recibidos mediante asentimientos negativos.

Control Fiabilidad LocalControl Fiabilidad Local

Los TPDUs utilizados para el control de la fiabilidad son:– TPDU datos Rtx.– TPDU ACK– TPDU HACK– TPDU HSACK– TPDU NACK– TPDU HNACK– TPDU MACK

El ámbito de envío de estos TPDU es local y se ajusta con el TTL.

Asentimientos Positivos

Asentimientos Negativos

Solicitud de CG

Emisor De DatosEmisor De Datos

Cualquiera puede ser emisor de datos en cualquier instante.

El emisor encapsula los datos en TPDUs y los envía por Multicast a todo el Grupo Multicast.

Los mantiene en la ventana de emisión hasta que han sido asentidos.

Indicar En Cada TPDU DatosIndicar En Cada TPDU Datos

Flag ACK: el TPDU tiene que ser asentido positivamente.

Flag FINC: indica que es el último TPDU Datos que envía al grupo.

Flag FINT: Se ofrece como ayuda al nivel de aplicación. Fin de una unidad de transferencia.Por ejemplo: Transferencia de ficheros.

Indicar En Cada TPDU DatosIndicar En Cada TPDU Datos

Número ráfaga: comienza en 1. Se incrementa cada X TPDUs.

Flag IR: es el primer TPDU datos de la ráfaga.

Número secuencia: inicio aleatorio. Se incrementa en uno por cada TPDU datos.Evitar duplicados.Ordenar en destino.

TPDU Datos TPDU Datos

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31




Cheksum V 0 1 0 0 0ACK

IR

FINC

FINT

NO USADOS

Tamaño de ventana Número de ráfaga

Número de secuencia

Datos

....

Recepción De DatosRecepción De Datos

Todos los miembros reciben los datos enviados al grupo.

Cada miembro del grupo multicast crea una ventana de recepción por cada emisor de datos:Ordenan los datos recibidos.Memoria intermedia para posibles

retransmisiones locales.

Controlador De Grupo Local (CG)Controlador De Grupo Local (CG)

En todos los GL se establece un CG para cada ráfaga de cada emisor.

Asegura la fiabilidad de los TPDUs de la ráfaga, actuando como si fuese el emisor fuente de la misma.

Cualquier miembro del grupo puede ser CG.

Configuración CGConfiguración CG

Al recibir una ráfaga que no tiene CG asignado:Todos los miembros del GL esperan un tiempo

aleatorio, transcurrido el cual solicitan ser CG, si no lo ha solicitado otro.

En el GL del emisor, el CG es el emisor. Para solicitar ser CG se envía un TPDU

MACK:Enviado por multicast con un alcance del GL

(TTL de 1).

Configuración CGConfiguración CG

En caso de conflicto:Permanece el que tenga la dirección IP

menor.El que quede como CG reenviará la

solicitud (TPDU MACK).

TPDU MACKTPDU MACK

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31




Cheksum V 0 1 0 1 0 No Usados

Número de ráfaga Fuente Dirección IP Fuente (2 bytes primero)

Dirección IP Fuente (2 bytes últimos) Puerto Unicast Fuente

Número de secuencia inicial de la ráfaga

Asentimientos PositivosAsentimientos Positivos

Utilizados para reconocer la correcta recepción de los datos.

Son acumulativos.Se envían por Unicast o por MulticastTipos:

ACKHACKHSACK

Asentimientos Positivos (ACK)Asentimientos Positivos (ACK)

ACK: Enviados por los miembros de cada GL

al CG. Son enviados por Unicast.

TPDU ACKTPDU ACK

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31







Número de Secuencia Fuente

Asentimientos Positivos (HACK)Asentimientos Positivos (HACK)

Enviados por los CG a los CG padres cuando:Han recibido ACK de todos los miembros del

GL.Han recibido HACK de los GL hijos

jerárquicos.

Supresión en el envío. Se envían por Multicast con un alcance

del GL y de los GLs padres.

TPDU HACKTPDU HACK

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31








Semiasentimiento Positivo (HSACK)Semiasentimiento Positivo (HSACK)

Enviados por los CG a los CG padres para indicar que al menos un miembro del GL lo ha recibido. Así evitamos retransmisiónAsí evitamos retransmisión

Supresión en el envío.Se envían por Multicast con un

alcance del GL y de los GLs padres.

TPDU HSACKTPDU HSACK

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31








Asentimientos PositivosAsentimientos Positivos

Tiempos De Espera Y Rtx.Tiempos De Espera Y Rtx.

Si transcurre un tiempo sin recibir los asentimientos positivos los CG rtx. el último por el que están esperando asentimiento.

En la rtx. indica de quién no ha recibido asentimiento positivo.

Si agota las oportunidades máximas de espera, entiende que se han caído todos los que no lo hayan asentido.

Asentimientos Negativos Asentimientos Negativos

En ellos se solicitan los TPDUs que no se han recibido.

Supresión en el envío.Multicast o Unicast.Tipos:

NACKHNACK MulticastHNACK Unicast

NACKNACK

Enviado por Multicast al GL (TTL de 1). El CG retransmitirá los TPDUs solicitados por

Multicast. Si el que los solicita es el CG, cualquier miembro

del GL lo rtx. tras una supresión. Espera un tiempo aleatorio y rtx. los TPDUs solicitados,

si no lo ha rtx. otro.

Rtx. los Datos solicitados

NACK

CG

R

R

R

R

TPDU NACKTPDU NACK0 1 2 3 4 5 6 7 8 9 1

011

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31





Dirección IP 1

Puerto Unicast 1 Número de secuencia 1 (2 bytes primeros)

Número de secuencia 1 (2 bytes últimos) Dirección IP 2 (2 bytes primeros)

Dirección IP 2 (2 bytes últimos) Puerto Unicast 2

Número de secuencia 2

...

HNACK MulticastHNACK Multicast

Enviado por Multicast al GL y a los GL padres jerárquicos.

El CG del GL o de los GL padres retransmitirá los TPDUs solicitados.

HNACK UnicastHNACK Unicast

Enviados por Unicast directamente al emisor.

El emisor reenviará los TPDUs solicitados por Unicast a quién los ha solicitado.

TPDU HNACKTPDU HNACK0 1 2 3 4 5 6 7 8 9 1

011

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31





Dirección IP 1

Puerto Unicast 1 Número de secuencia 1 (2 bytes primeros)

Número de secuencia 1 (2 bytes últimos) Dirección IP 2 (2 bytes primeros)

Dirección IP 2 (2 bytes últimos) Puerto Unicast 2

Número de secuencia 2

...

InactividadInactividad

Emisor: tiene que enviar periódicamente un TPDU de datos para que los receptores sepan que sigue emitiendo.

Receptor: si transcurre un tiempo sin recibir nuevos TPDUs de datos de un emisor considera que ha dejado de emitir.

Soluciona el hecho de que un emisor deje de emitir sin avisar.

Control De FlujoControl De Flujo

Ventana: limita el número de TPDUs que se pueden enviar sin haber recibido asentimiento.

En cada TPDU datos el emisor indica el tamaño actual de su ventana de emisión.

Control De FlujoControl De Flujo

Emisor:Lo detecta al recibir asentimientos negativos.Lo corrige disminuyendo el tamaño de la

ventana de emisión y aumentando el tiempo de espera.

Receptor:Lo detecta al solicitar TPDUs y no recibir

contestación.Lo corrige disminuyendo el envío de

asentimientos negativos.

Control De La CongestiónControl De La Congestión

Se detecta si no se reciben asentimientos positivos ni negativos.

Se corrige disminuyendo el número de retransmisiones.

Los emisores disminuyen el tamaño de su ventana de emisión.

Fiable RetrasadoFiable Retrasado

Objetivo: que nuevos miembros puedan incorporarse a un grupo cuando ya ha iniciado la comunicación.

Los nuevos miembros tienen que sincronizarse con los CG.

SincronizaciónSincronización

Encuentra, para cada emisor fuente, el TPDU de datos a partir del cual comienza a recibir los TPDUs de dicho emisor fuente de forma fiable.

Se realiza en el ámbito local con el CG. Se sincroniza cuando recibe un TPDU

datos retransmitido en el que figura en su lista de no asentidos.

SeguridadSeguridad

PTMF permite codificar todos los TPDUs enviados al grupo.

Si sólo se codifican los datos en el nivel de aplicación:

Los receptores con clave diferente o que no descodifiquen pasarán datos ilegibles a la aplicación.

Procesan TPDUs innecesariamente, cargando la comunicación Multicast sin necesidad.

SeguridadSeguridad

PTMF proporciona soporte para la codificación de los TPDUs utilizando algoritmos de clave secreta y codificando en el modo ECB (Electronic Code Book).

En la implementación se ha utilizado RC2, generando la clave secreta siguiendo el estándar PKCS5.





IV. FTPMulticast

V. ChatMulticast

ImplementaciónImplementación

Cumple al 100 % la especificación de PTMF.

Desarrollado en JAVA.Clases recogidas en el paquete

PTMF, que está formado por 87 clases.

Modos De FiabilidadModos De Fiabilidad

Fiable.Fiable Retrasado.No Fiable. No Fiable Ordenado.

Modos No FiableModos No Fiable

No Fiable:No se crea la jerarquía de GL.No hay retransmisiones.No se envía ningún tipo de

asentimiento.Los datos pueden perderse o

entregarse al nivel de aplicación en desorden o duplicados.

Modo Fiable No OrdenadoModo Fiable No Ordenado

No Fiable ordenado:Es igual al NO FIABLE, con la única

diferencia de que se garantiza que los datos no se entregan al nivel de aplicación en desorden ni duplicados, aunque sí se pueden producir pérdidas de datos.

Compatibilidad De ModosCompatibilidad De Modos

Modo Recibe de miembros en modo

Fiable Fiable y Fiable Retrasado

Fiable Retrasado

Fiable y Fiable Retrasado

No FiableFiable, Fiable Retrasado, No Fiable y No Fiable Ordenado

No Fiable Ordenado

Fiable, Fiable Retrasado, No Fiable y No Fiable Ordenado

Interfaz De AplicaciónInterfaz De Aplicación

Conjunto de clases que permiten a la aplicación utilizar PTMF de forma transparente.

Utiliza una notación similar a la utilizada en java para acceder a los servicios de TCP (Socket) y de UDP (DatagramSocket).

Interfaz De AplicaciónInterfaz De Aplicación

Aplicación

Fiable Fiable

Retrasado No

Fiable No Fiable Ordenado

SocketPTMF DatagramSocketPTMF

IP

PTMF

Threads En PTMFThreads En PTMFBLOQUE SocketPTMF BLOQUES

DATOS Y CGL

Diagrama de Flujo de Datos. Modos Fiable y Fiable Retrasado

Multicast

DATOSTPDUs THREAD

IP

THREADUSUARIO

PTMFDATOS

THREAD

COLA EMISIÓN

COLA RECEPCIÓN

VECTOR TPDUs

VECTOR TPDUs CGL

VECTOR TPDUs DATOS

THREAD CGL

THREAD RECEPCIÓ

N MULTICAS

T

THREAD RECEPCIÓN UNICAST

Multicast / Unicast

BLOQUES CanalMulticast y

CanalUnicast

Enviar DatosEnviar Datos

Flujo de salida Multicast: MulticastOutputStream.

Es un flujo síncrono.

SocketPTMF

MulticastOutputStream ColaEmisión

Eventos PTMF

THREADUSUARI

O

Flujo de datos Flujo de Eventos PTMF

Recibir Datos Recibir Datos

Gestor de flujos de entrada: MulticastInputStream

SocketPTMF

THREAD

USUARIO

MulticastInputStream ColaRecepción

Eventos PTMF

ID_SocketInputStream

ID_SocketInputStream

...

Eventos PTMF

Eventos PTMF

Flujo de datos Flujo de Eventos PTMF

Averiguar Nuevos EmisoresAveriguar Nuevos Emisores

Sondear a MulticastInputStream si hay algún ID_SocketInputStream con datos para leer.

Notificación asíncrona mediante el evento PTMFEventID_SocketInputStream.

Leer Datos De Un EmisorLeer Datos De Un Emisor

A cada emisor se asocia un flujo de entrada ID_SocketInputStream.

El thread de la aplicación puede leer los datos de dos modos posibles:Modo síncrono.Modo asíncrono.

Modos De LecturaModos De Lectura

Clase: ID_SocketInputStream

Leer datos del flujo ID_SocketInputStream

SÍNCRONO

ASÍNCRONO

SONDEO

TIME-OUT

EVENTO PTMFEventDatosRecibidos

Modo SíncronoModo Síncrono

En este modo en el momento que no haya datos disponibles para leer del flujo el thread que realice la lectura quedará bloqueado hasta que haya nuevos datos o se alcance el final de transmisión para ese flujo.

Modo AsíncronoModo Asíncrono

Si no existen datos listos para ser leídos el thread que intenta leer no se bloquea.

Tres modos de operar:Sondeo.Time-out.Notificación mediante Evento

PTMFEventDatosRecibidos.




III. Implementación IV. FTPMulticast

V. ChatMulticast

Cabecera FTPMulticastCabecera FTPMulticast0 1 2 3 4 5 6 7 8 9 1

011

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

ID_FTPMulticast

Version FTPMulticast

Longitud Fichero (primeros 3 bytes más significativos)

Longitud Fichero (4 bytes siguientes)

Longitud Fichero (byte menos

significativos)

Longitud Nombre Fichero ( 16 bits)Nombre Fichero (byte más alto 1º

carácter

Nombre Fichero (byte más bajo 1º

carácter)

Nombre Fichero (2º carácter[2 bytes]) ....

Cabecera ChatMulticastCabecera ChatMulticast

0 1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

ID_ChatMulticast

Version ChatMulticast

Longitud Texto

Red de pruebasRed de pruebas

150.214.142.137

150.214.142.129

.140

Router Multicast

.131 .132.130

PTMF

Documents

Transcript of PTMF