Integrating Multiplexing Facilities in the Set of JRMP Subprotocols

IEEE LATIN AMERICA TRANSACTIONS, VOL. 7, NO. 1, MARCH 2009
107
Integrating Multiplexing Facilities
in the Set of JRMP Subprotocols
P. Basanta-Val, M. Garcia-Valls, I. Estévez-Ayres, J. Fernádez-González
Abstract— With the process of adaptation and redefinition of
Java Remote Method Invocation for J2ME (Java 2, Micro
Edition) environments, a reduced version of the Remote Method
Invocation (RMI) came up. In this reduced version, called
RMIOP, some heavy features such as multiplexing facility or its
capacity to go through firewalls offered by the wire protocol,
called Java Remote Method Protocol (JRMP), have been
eliminated. In the present article it is explored how the recovery
of the multiplexing facilities of JRMP, rejected during the
RMIOP definition, can be carried out maintaining the J2ME
idiosyncrasy. The article begins showing how to extend the triad
of
subprotocols
already
defined
(SingleOpProtocol,
StreamProtocol and MultiplexProtocol) with a new one
(MultiplexConnnectionLessProtocol) equipped with special
facilities to multiplex connections. It gives support for fast and
light connection connectionless virtual connections generation
and recycling. The paper ends with an empirical evaluation of
the proposed subprotocols together with the already existing
ones, in terms of end-to-end response time and the size of the
frames transmitted through the network, showing the goodness
of the protocols.
Keywords— Communication protocols, algorithms.
I. INTRODUCCIÓN
Especialmente durante estos últimos años, las aplicaciones y
los sistemas distribuidos han proliferado hasta hacerse
prácticamente indispensables en el mundo de la
telecomunicación, de la informática y de la ciencia e
ingeniería en general. Los estándares para el desarrollo de este
tipo de aplicaciones se han ido perfeccionando al mismo
tiempo que se ha conseguido que su implementación sea cada
vez más rápida, sencilla y eficiente. Este avance se ha
traducido en protocolos de comunicaciones bien definidos
como pueden ser el GIOP de CORBA ([1] y [2]), el aún
reciente SOAP [3] o el protocolo propietario de
comunicaciones JRMP, utilizado por el modelo de objetos
distribuidos RMI [4] de Java.
Si bien los sistemas se han distribuido no es menos cierto
que también ha habido, en estos últimos años, un fuerte
crecimiento en el terreno embebido. De esta manera, hemos
asistido a la aparición de una nueva generación de dispositivos
electrónicos (teléfonos móviles, PDAs o incluso
electrodomésticos) cuya característica común es la de operar
Pablo Basanta Val, Universidad Carlos III de Madrid, [email protected]
Marisol García Valls, Universidad Carlos III de Madrid, [email protected]
Iria Estévez Ayres, Universidad Carlos III de Madrid, [email protected]
Jorge
Fernández
González,
Universidad
Carlos
III
de
Madrid,
[email protected]
en escenarios donde existe algún tipo de escasez de recursos
(memoria, capacidad de cómputo o procesado, acceso a redes
de comunicación, etc.), y que comúnmente se conocen como
“dispositivos limitados”.
Ese crecimiento pasado, acompañado de unas buenas
previsiones para el futuro (algún informe relacionado [5]
habla de crecimientos situados entre el 10% y el 16% de aquí
al 2009) hace que exista un fuerte interés en adecuar los
protocolos y modelos middleware existentes para propósito
general a las restricciones impuestas por este nuevo tipo de
sistemas.
A día de hoy, se puede decir que ya se han dado algunos
pasos importantes en esa dirección. Uno de ellos es Minimum
CORBA ([6]), una versión recortada de CORBA donde han
sido eliminadas ciertas características causantes de una gran
sobrecarga tanto computacional como espacial, e introducidas
otras simplificaciones en el modelo de comunicaciones (véase
[7]). De la misma manera, en el mundo Java, en el modelo
original de RMI, se ha eliminado el soporte para el acceso
transparente a través de cortafuegos, así como las capacidades
de multiplexación proporcionadas por el subprotocolo
MultiplexProtocol, dando todo ello lugar a RMIOP [8].
Así, a fin de mostrar cómo se puede recuperar la capacidad
de multiplexación de RMI eficientemente bajo las
restricciones impuestas por J2ME, el resto de este artículo se
estructura tal y como sigue. En la sección II son introducidos
ciertos conceptos básicos de JRMP como son los diferentes
tipos de mensajes o el concepto de subprotocolo. La sección
III describe cómo los diferentes subprotocolos, diseñados
originalmente para RMI, participan en la realización de una
invocación remota RMI. La sección IV describe el protocolo
diseñado y su papel dentro de una invocación remota. En la
sección V, se comparan los tiempos de respuesta y el ancho de
banda consumido por los tres subprotocolos ya existentes con
los del protocolo propuesto, viendo su efectividad a la hora de
atender peticiones remotas. Por último, la sección VI cierra el
artículo esbozando las conclusiones y líneas futuras que se
desprenden del trabajo realizado.
II. CABECERAS, SUBPROTOCOLOS Y MENSAJES EN JRMP
Antes de adentrarnos en la definición del protocolo
propuesto, esta sección presenta de forma parcial algunos
detalles del protocolo de comunicaciones RMI también
conocido como Java Remote Method Protocol (JRMP, o
simplemente Wire Protocol, tal y como aparece descrito en el
capítulo 8 de la especificación [9]).
108
IEEE LATIN AMERICA TRANSACTIONS, VOL. 7, NO. 1, MARCH 2009
Internamente, este protocolo hace uso a su vez, de otros dos
protocolos: del de serialización de objetos Java [10] y del
popular HTTP. En cuanto al primero, su uso esta destinado a
la operación de serialización y deserialización en las llamadas
remotas así como a la devolución de datos. Por otra parte, el
protocolo HTTP puede ser empleado para realizar un POST de
una invocación a método remoto y para la obtención de
resultados.
A. Flujos de entrada y flujos de salida
Una de las primeras consideraciones a tener en cuenta en
este punto es que el contenido de la cabecera de transporte no
estará formateado mediante la serialización de objetos Java.
Por otro lado, los flujos o streams de comunicación en RMI
siempre estarán emparejados, es decir, cada flujo de salida
siempre estará relacionado con un flujo de entrada y
viceversa. De esta manera, el flujo de salida estará referido a
los mensajes salientes desde un nodo (y por tanto, hará
referencia al flujo de salida de un socket desde la perspectiva
de un cliente), mientras que los mensajes entrantes serán
aquellos que llegan hasta el nodo (y se corresponderán con el
flujo de entrada del socket).
diferenciados. En el caso de SingleOpProtocol, sólo habrá un
mensaje después de la cabecera y, por tanto, no habrá
información adicional a parte del mensaje encapsulado. En el
caso del StreamProtocol y MultiplexProtocol, el servidor
deberá responder con el octeto 0x4E a modo de asentimiento o
ACK, con lo que el cliente podrá interpretar que el protocolo a
emplear es soportado por el otro extremo de la comunicación.
La sección III incluye esquemas empíricos de la realización de
una invocación remota con cada uno de estos tres
subprotocolos.
En la figura 2 se muestran más en detalle los mensajes que
acompañan la cabecera del protocolo. En total, JRMP
distingue tres tipos de mensajes:
• Call que sirve para invocar a un método remoto.
• Ping que es un mensaje del nivel de transporte
destinado a probar la existencia o funcionamiento de
una máquina virtual remota.
• DgcAck que es un mensaje de asentimiento dirigido
al recolector de basura distribuido del servidor.
ƒ Call:
1) Flujo de salida en JRMP
Un flujo de salida RMI estará compuesto por una cabecera
de transporte seguida de una secuencia de mensajes.
Alternativamente, un flujo de salida podrá contener una
invocación encapsulada dentro del protocolo HTTP. Lo que en
la práctica nos lleva a la existencia de dos tipos de mensajes:
•
•
Mensaje encapsulado en HTTP o HttpMessage. Este tipo
de encapsulación sirve de envoltorio permitiendo que la
información pueda atravesar fácilmente, por ejemplo, un
cortafuegos. Desde el punto de vista del protocolo
diseñado este tipo de mensaje carece de gran relevancia.
Cabecera con mensajes (tal y como se muestra en la
figura 1) de gran relevancia a la hora de introducir el
nuevo subprotocolo manteniendo la compatibilidad hacia
atrás. De toda esta trama, son especialmente relevantes
tanto los campos protocolo como mensaje. El primero de
ellos permite escoger, de entre los tres subprocolos
existentes, el utilizado durante el intercambio de mensajes
mientras que el segundo permite el intercambio de
mensajes entre los dos extremos de la aplicación.
Cabecera
0x4A 0x52 0x4D
Mensajes
Versión
Mensaje
CallData
0x52
ƒ Ping:
ƒ DgcAck:
0x54
Unique Identifier
Figura 2: Formato de los principales mensajes de salida del protocolo JRMP
2) Formato de los flujos de entrada
Si en vez de considerar el conjunto de mensajes que envía
un cliente, consideramos los que recibe, observaremos la
existencia de tres tipos de mensajes:
•
•
•
HttpReturn, que se utiliza para devolver el resultado
de una invocación encapsulada mediante HTTP.
ReturnData, que será el resultado de la realización de
una invocación remota normal.
PingAck que es el asentimiento a un mensaje de tipo
Ping.
La figura 3 nos muestra el formato de los mensajes
recibidos. En primer lugar, se recibe la confirmación (con
0x4E) de la recepción de un mensaje o, por el contrario (con
0x4F), la indicación de que el protocolo utilizado no es
soportado por el servidor. En caso de que sea exitoso, el flujo
de salida se acompañará de una serie de mensajes adicionales.
ProtocolAck
Protocolo
0x50
Returns
Return
Mensaje
0x00 0x02
Men
Returns
Men
StreamProtocol (0x4B)
SingleOpProtocol (0x4C)
MultiplexProtocol (0x4D)
Figura 1: Esquema con las cabeceras y mensajes del flujo de salida del
protocolo JRMP
Como podemos observar en la figura 1, cada uno de los
mensajes será encapsulado dentro de un subprotocolo (campo
Protocolo) determinado, existiendo dos comportamientos
Return
0x4E, 0X4F
Figura 3: Formato de un ProtocolAck y lista de mensajes retornados
Estos mensajes adicionales, tal y como esquematiza la
figura 4, pueden ser de dos tipos: ReturnData o PingAck. El
primero de ellos se utiliza típicamente como respuesta a un
proceso de invocación remota y viene acompañado
VAL et al.: INTEGRATING MULTIPLEXING FACILITIES
109
(ReturnValue) de una serie de resultados de la invocación
remota. El segundo de ellos se encarga de dar fe del buen
funcionamiento del otro extremo. Por último, ha de notarse
que el DGCAck carece de mensajes de entrada asociados.
0x51
ƒ ReturnData:
ReturnValue
Return
0x53
ƒ PingAck:
Figura 4: Los diferentes tipos de mensajes de entrada definidos por JRMP
III. INVOCACIÓN REMOTA Y SUBPROTOCOLOS JRMP
A fin de ver las diferencias existentes entre los tres
subprotocolos descritos, esta sección muestra la forma en que
éstos participan durante las invocaciones remotas. En todos
los casos, las secuencias de mensajes mostradas han sido
obtenidas empíricamente tomando trazas reales con el
Ethereal [11] aplicándolo directamente sobre la
implementación de referencia de Sun Microsystems.
A. Invocación remota con SingleOpProtocol
La figura 5 muestra cómo SingleOpProtocol participa en una
invocación remota cuando la red subyacente es de tipo TCP.
En este caso, cada invocación remota requiere del
establecimiento de una nueva conexión TCP, con su
correspondiente señalización del canal de comunicaciones
mediante mensajes SYN y SYN-ACK. Tras ello, el cliente
podrá enviar, ya en el siguiente mensaje, una petición de tipo
Call que será contestada de inmediato, en el caso de que la
invocación remota haya sido exitosa con un mensaje de tipo
ReturnData. Tras ello, se procede a cerrar la conexión
mediante los mensajes de FIN y ACK descritos en TCP.
CLIENTE
relevante en condiciones normales, es que al coste de enviar
los datos necesarios para realizar la invocación remota hay
que añadirle el de introducir, enviar y procesar, tanto en
cliente como en el servidor, las cabeceras específicas del
subprotocolo SingleOpProtocol.
B. Invocación remota con StreamProtocol
El protocolo StreamProtocol se puede entender como un
protocolo que ataca estos dos problemas, proponiendo, al
igual que el modelo orientado a conexión de TCP, la
negociación previa de un canal de comunicaciones.
La figura 6 muestra cómo StreamProtocol colabora a la
hora de realizar una invocación remota. En primer lugar, al
igual que en el caso precedente se establece el canal TCP de
comunicaciones. Tras ello, y de forma distinta a lo que ocurría
antes, se establece la conexión del StreamProtocol, enviando
desde el servidor al cliente el EndPointIdentifier recibido.
Tras esta primera fase de comunicaciones el canal ya puede
ser utilizado para enviar y recibir datos.
CLIENTE
SERVIDOR
SYN
Establecimiento
de la conexión
TCP
Establecimiento
de la conexión
RMI
SYN, ACK
ACK
Cabecera (con protocolo StreamProtocol 0x4B)
ProtocolAck (0x4E) con EndPointIdentifier
Mensaje Continuation de la fase de negociación en
que el cliente puede indicar otro EndPointIdentifier
Invocación
remota RMI
Call (0x50) con su correspondiente CallData para la
serialización de datos
ReturnData (0x51) con su correspondiente
ReturnValue para la serialización de datos
SERVIDOR
SYN
Establecimiento
de la conexión
TCP
SYN, ACK
ACK
FIN
Invocación
remota en
RMI
Cabecera (con protocolo SingleOpProtocol
(0x4C) + Call con la correspondiente serialización
de datos
ReturnData (0x51) con su correspondiente
ReturnValue para la serialización de datos
ACK
Cierre de
la conexión
TCP
FIN, ACK
ACK
Cierre de
la conexión
TCP
FIN
Figura 6: Invocación remota con StreamProtocol. Esquema de mensajes
ACK
A diferencia de lo que ocurría con SingleOpProtocol, ya no
es necesario que en cada mensaje aparezca encapsulado con el
tipo de protocolo utilizado sino que se puede enviar sin el
envoltorio, ganando eficiencia durante las invocaciones
remotas.
Otra diferencia relevante es que tras la primera invocación
remota ya no es necesario cerrar el canal sino que éste puede
reutilizarse para otras invocaciones remotas. Lo que se traduce
en unos tiempos de respuesta menores en aquellas
aplicaciones capaces de reaprovechar el canal de
comunicaciones ya establecido.
FIN, ACK
ACK
Figura 5: Invocación remota con SingleOpProtocol. Esquema de mensajes
El subprotocolo descrito adolece, al menos, de dos
inconvenientes. El primero de ellos es la alta sobrecarga que
supone abrir y cerrar una conexión TCP cada vez que se
quiere realizar una invocación remota. El segundo, menos
110
IEEE LATIN AMERICA TRANSACTIONS, VOL. 7, NO. 1, MARCH 2009
Una limitación que presenta este protocolo es la carencia de
un soporte nativo para la concurrencia: dos clientes que
quieran acceder de forma independiente a un mismo objeto
remoto habrán de abrir, cada uno, su propia conexión de tipo
StreamProtocol. Consciente de esta limitación, JRMP define
un tercer subprotocolo: MultiplexProtocol.
C. Invocación remota con MultiplexProtocol
El protocolo MultiplexProtocol, replica varios de los
mecanismos presentes en TCP, como por ejemplo el control
de flujo o el propio mecanismo de establecimiento de
conexiones, en el nivel middleware, definiendo para ello
soporte a subconexiones. A fin de comprender cómo funciona,
la figura 7 muestra la manera en que MultiplexProtocol es
utilizado a la hora de realizar una invocación remota.
CLIENTE
SERVIDOR
SYN
Establecimiento
de la conexión
TCP
Establecimiento
de la conexión
RMI
SYN, ACK
ACK
Cabecera (con protocolo
MultiplexProtocol 0x4D)
ProtocolAck (0x4E) con EndPointIdentifier
Mensaje Continuation de la fase de negociación en
que el cliente puede indicar otro EndPointIdentifier
OPEN + Identificador de conexión
Establecimiento
de la subconexión
multiplexada
REQUEST + Identificador de conexión
TRANSMIT + Identificador de conexión +
Call (0x50) con su correspondiente
CallData
para
la serialización
datos
REQUEST
+ Identificador
de de
conexión
Invocación
remota RMI
TRANSMIT + Identificador de conexión +
Return (0x51) con su correspondiente
ReturnValue para la serialización de datos
Figura 7: Invocación remota con MultiplexProtocol. Esquema de mensajes
Al igual que en los dos casos precedentes, se comienza por
la apertura de la conexión TCP. Tras haber abierto la conexión
TCP, y al igual que ocurre en StreamProtocol, se negocia el
tipo de protocolo utilizado. Tras esta negociación inicial hay
que abrir una conexión virtual con el otro extremo. Eso se
consigue mediante la primitiva OPEN que una vez confirmada
con un REQUEST permite el envío de datos. REQUEST es
una primitiva especial que indica al otro extremo el número de
octetos que puede recibir un extremo sirviendo, por tanto, para
controlar el flujo de la comunicación. Tras abrir la conexión y
ya mediante una primitiva TRANSMIT se puede transmitir el
mensaje de Call que es contestado con otro TRANSMIT que
encapsula el correspondiente Return. A partir de esta primera
comunicación, el esfuerzo se reduce ya que no es necesario
proceder a la apertura de ningún tipo de conexión virtual.
Por tanto, la gran ventaja proporcionada por el
MultiplexProtocol, en contraste con lo que ocurre en
SingleOpProtocol y StreamProtocol, es que posibilita que por
una única conexión TCP viajen mensajes de diferentes
comunicaciones mediante el concepto de conexión virtual.
Sin embargo el coste del mecanismo multiplexor descrito
por MultiplexProtocol puede ser, a veces, demasiado costoso
para ser ejecutado de una forma mucho más dinámica. Al
coste extra de tener que procesar los diferentes paquetes del
subprotocolo MultiplexProtocol (y que no aparecen en
StreamProtocol ni en SingleOpProtocol) hay que añadirle que
el mecanismo de control del flujo propuesto (basado en
mensajes REQUEST y TRANSMIT) consume recursos que
no tienen por qué estar siempre disponibles en entornos J2ME.
Es por ello, que en el paquete RMIOP, se elimina el soporte
ofrecido para MultiplexProtocol, dejando sólo el de
SingleOpProtocol y el de StreamProtocol. Pero sin embargo,
la capacidad de multiplexación sigue siendo interesante pues
hay entornos que limitan el número de conexiones que pueden
ser aceptadas.
IV. MULTIPLEXCONNECTIONLESSPROTOCOL
El nuevo subprotocolo que se ha propuesto, i.e.
MultiplexConnectionLessProtocol, puede entender se como un
subprotocolo de tipo StreamProtocol dotado de un mecanismo
ligero de multiplexación. En vez de un modelo orientado a
conexión con control del flujo, como el que es incorporado
por el MultiplexProtocol, el protocolo en su diseño opta por
un modelo de multiplexación no orientada a conexión de bajo
coste, capaz de gestionar conexiones virtuales de forma ágil y
dinámica.
A. Cambios introducidos en JRMP
En primer lugar es necesario integrar el nuevo subprotocolo
dentro de JRMP. Esto se puede conseguir de forma sencilla
asignándole, tal y como se expresa gráficamente en la figura
8, un identificador libre (se ha escogido arbitrariamente el
identificador 0x60, en principio libre) para el subprotocolo
MultiplexConnectionLessProtocol.
Magic
0x4A 0x52 0x4D 0x49
Versión
0x00 0x02
Protocolo
StreamProtocol (0x4B)
SingleOpProtocol (0x4C)
MultiplexProtocol (0x4D)
MultiplexConnectionLessProtocol (0x60)
Figura 8: Cambios introducidos por MultiplexConnectionLessProtocol
La negociación del protocolo así como el establecimiento de
la conexión no requiere de cambios en las tramas. El esquema
de MultiplexProtocol y de StreamProtocol puede ser utilizado
sin cambios sustanciales. De esta manera, en los tres casos se
VAL et al.: INTEGRATING MULTIPLEXING FACILITIES
111
procede al intercambio de los identificadores entre los dos
extremos de la comunicación.
No ocurre lo mismo con el conjunto de mensajes
intercambiados, donde existe la necesidad (no presente en las
soluciones previas) de indicar la conexión virtual a la que
pertenecen los mensajes. MultiplexConnectionLessProtocol
solventa el problema introduciendo una cabecera corta (de 2
octetos) con el identificador de conexión virtual a la que
pertenece el mensaje.
Tal y como se puede ver en la figura 9, en la cabecera, se
añade a dos de los tres mensajes de salida: Call y Ping (y no a
DGCAck) y a todos los de entrada: PingAck y Return.
Identificador de
conexión virtual
(2 octetos)
Call
(0x50)
Identificador de
conexión virtual
(2 octetos)
Ping
(0x52)
Identificador de
conexión virtual
(2 octetos)
Return
(0x51)
Identificador de
conexión virtual
(2 octetos)
PingAck
(0x53)
Serialization Data
(CallData)
Serialization Data
(Return)
Figura 9: Cabeceras ligeras de conexión virtual introducidas por
MultiplexConnectionLessProtocol
B. Participación en la invocación remota
A fin de comprender un poco mejor cómo funciona una
invocación remota con este nuevo subprotocolo, la figura 10
muestra cómo el protocolo participa en una invocación
remota.
CLIENTE
SERVIDOR
SYN
Establecimiento
de la conexión
TCP
SYN, ACK
Establecimiento
de conexión RMI
Cabecera (con protocolo
MultiplexConnectionLessProtocol 0x60)
ACK
ProtocolAck (0x4E) con EndPointIdentifier
Mensaje Continuation de la fase de negociación en
que el cliente puede indicar otro EndPointIdentifier
Invocación
remota RMI
Identificador de conexión virtual + Call
(0x50) con su correspondiente CallData para
la serialización de datos
conexiones virtuales, sino que se trata de una característica
dinámica.
De la misma manera, también se observa que, al igual que
en StreamProtocol, para la realización de una invocación
remota es suficiente con dos mensajes. Se puede entender, por
tanto, que el protocolo diseñado aúna por un lado la eficiencia
de diseño de StreamProtocol con, por otro lado, la capacidad
de multiplexación de MultiplexProtocol.
V. COSTES Y VENTAJAS ASOCIADAS A
MULTIPLEXCONNECTIONLESSPROTOCOL
A fin de evaluar, de una forma empírica, las ventajas, así
como las sobrecargas introducidas por el nuevo protocolo
propuesto, se ha realizado una implementación del mismo. Se
ha partido de la implementación de RMIOP disponible en la
página Web de Sun Microsystems para J2ME [8] y se la ha
dotado de soporte adecuado para el protocolo
MultiplexConnectionLessProtocol descrito, así como para
SingleOpProtocol y MultiplexProtocol (por defecto, la
implementación tan sólo ofrece soporte para StreamProtocol),
tomados de la implementación tradicional para J2SE.
Las pruebas han sido realizadas en un escenario donde los
costes de procesado del protocolo JRMP se hacen más
visibles. Este escenario es aquél formado por un cliente y un
servidor en ejecución sobre un mismo ordenador y donde el
método remoto invocado es de tipo void doNothing().
Todos los resultados que se mencionan han sido obtenidos
utilizando una maquina virtual comercial de tipo CVM
llamada JTime [12], dotada de soporte para la especificación
RTSJ de tiempo real [13], en un entorno de ejecución Redhat
9.0, sobre un procesador Pentium IV a 2400 Mhz dotado de
512 Mb de memoria. A fin de eliminar interferencias, cada
medida temporal ha sido realizada 150 veces, comprobándose
que la distribución resultante es modelable por una gaussiana
y procediéndose a la estimación de su media y desviación
típica.
A. Tiempos de respuesta extremo a extremo
La tabla 1 contiene los resultados obtenidos en este
escenario de pruebas relativos a lo que es la latencia extremo a
extremo. Se presentan dos casos, la primera invocación
(donde es necesario establecer la conexión TCP) y el resto
(donde dependiendo del protocolo utilizado, la conexión,
podrá ser reutilizada o no), reduciéndose, en consecuencia, los
tiempos de respuesta observados.
TABLA I:
TIEMPO DE RESPUESTA MEDIO (EN MICROSEGUNDOS) Y DESVIACIÓN TÍPICA EN
UN PROCESADOR A 2400 MHZ
Identificador de conexión virtual +
ReturnData (0x51) con su correspondiente
ReturnValue para la serialización de datos
Primera
Media
Desv
1836,75
6,036
Resto
Media
Desv
1830,03
8,62
StreamProtocol
1848,07
5,174
444,773
3,63
MultiplexProtocol
79887,0
21,38
673,5
8,03
MultiplexConnectionLessPr
otocol
3840,11
10,82
544,24
4,51
SingleOpProtocol
Figura 10: Invocación
Esquema de mensajes
remota
con MultiplexConnectionLessProtocol.
En ella se puede observar, a diferencia de lo que ocurría en
MultiplexProtocol, que el envío de la llamada de Call no
requiere la utilización de ningún tipo de establecimiento de
Los resultados para la primera invocación muestran que
MultiplexConnectionLessProtocol es capaz de ofrecer un
rendimiento (3840 μs) superior al del protocolo de
112
IEEE LATIN AMERICA TRANSACTIONS, VOL. 7, NO. 1, MARCH 2009
multiplexado de RMI (79887 μs), ligeramente peor que el de
los protocolos SingleOpProtocol (1836 μs) y StreamProtocol
(1848,7 μs). Porcentualmente, la mejora obtenida al sustituir
MultiplexProtocol por el protocolo sin conexión es del 95 %.
Esta mejora inicial se reduce tras la primera invocación
remota (dado que la conexión TCP y la negociación de la
conexión iniciales se pueden reutilizar). Se obtienen tiempos
medios de 544,24 μs en el caso del protocolo diseñado y de
673,5 μs en el caso multiplexado, lo que porcentualmente hace
que pasemos de reducciones de un 95 % a un 19,22 %.
Se puede concluir, por tanto, que el protocolo propuesto es
capaz de recuperar las capacidades de multiplexación
introduciendo unas latencias inferiores a las de
MultiplexProtocol,
cercanas
a
las
ofertadas
por
StreamProtocol.
B. Ancho de banda consumido
Por último, si en vez de medir la latencia extremo a extremo
tenemos en cuenta lo que es el ancho de banda consumido
(véase ahora la tabla de resultados 2), se puede observar que el
protocolo diseñado se encuentra, en términos de rendimiento,
también entre MultiplexProtocol y StreamProtocol.
Si se compara con StreamProtocol, se puede comprobar la
existencia de un coste fijo adicional de cuatro octetos (de la
cabecera de comunicaciones y su identificador de conexión
virtual), lo que porcentualmente, en el peor de los casos hace
que el tamaño de la trama transmitida aumente como mucho
en un 6,34 %.
TABLA II:
TAMAÑO (EN OCTETOS) DE LAS TRAMAS TRANSMITIDAS EN UNA INVOCACIÓN
REMOTA
SingleOpProtocol
StreamProtocol
MultiplexProtocol
MultiplexConnectionLessProtocol
extensión ofrecidas por JRMP, de una forma sencilla y
conservando la compatibilidad hacia atrás mediante
conexiones virtuales ligeras, no orientadas a conexión.
Los resultados de la implementación nos sugieren, con
notables reducciones en lo que es el tiempo de respuesta y una
baja sobrecarga en el tamaño de trama, que la capacidad de
multiplexación propuesta puede resultar altamente interesante.
Por el momento se han identificado ya algunas líneas de
trabajo futuro. Una de ellas consiste en la realización de un
mayor número de pruebas empíricas, en diferentes escenarios
(como los descritos en [14]) y con diferentes cargas de
aplicación, con el fin de determinar de forma más precisa el
dominio de aplicabilidad del protocolo propuesto. Otra de
ellas consiste en la adecuación del protocolo no sólo a las
necesidades de los sistemas embebidos, sino a las de los
sistemas de tiempo real (como los descritos en [15] y [16]), lo
que requerirá, entre otras tareas, la readaptación del protocolo
propuesto y su sensibilización con las necesidades impuestas
por tales aplicaciones.
REFERENCIAS
[1]
[2]
[3]
[4]
[5]
[6]
[7]
Primera
Resto
70
101
135
105
70
63
88
67
[8]
[9]
En cambio, las reducciones que se pueden experimentar (si
lo comparamos con su competidor MultiplexProtocol) son de
un 22,5 %, para la primera invocación remota, y de un 23 %,
en adelante.
Si tomamos los resultados obtenidos y hacemos un balance
conjunto veremos que en el caso de estudio propuesto, tanto el
tamaño de trama como los tiempos obtenidos para la respuesta
extremo a extremo se encuentran entre los de StreamProtocol
y los de MultiplexProtocol.
[10]
[11]
[12]
[13]
[14]
[15]
VI. CONCLUSIONES
[16]
Los protocolos de comunicaciones actualmente existentes
para sistemas de propósito general han de ser adecuadamente
armonizados con las restricciones impuestas por los sistemas
embebidos. En este artículo se ha revisado el protocolo JRMP
de RMI y se ha visto cómo optimizarlo de tal manera que
incorpore facilidades de multiplexación en entornos J2ME. La
adaptación se ha hecho utilizando las posibilidades de
Vinoski, S. New features for CORBA 3.0. Commun. ACM 41, 10 (Oct.
1998), 44-52.
Object Management Group. Common Object Request Broker
Architecture. July, 1995.
W3C. SOAP v 1.2. Available on-line at http://www.w3.org/TR/soap12/
Waldo, J. Remote Procedure Calls and Java Remote Method
Invocation. IEEE Concurrency 6, 3 (Jul. 1998), 5-7
Ravi Krishnan. Future of embedded systems technology. Technical
report, BCC, Inc. June 2005
Object Management Group. Minimum CORBA - Joint Revised
Submission. OMG Document orbos/98-08-04 ed., August 1998.
Andy Gokhale and Douglas C. Schmidt. Optimizing a CORBA IIOP
Protocol Engine for Minimal Footprint Multimedia Systems. IEEE
Journal on Selected Areas in Communications special issue on Service
Enabling Platforms for Networked Multimedia Systems, September,
1999.
Sun Microsystems. J2ME RMI Optional Package (RMI OP). On-line,
http://www.sun.com/software/communitysource/j2me/rmiop/index.xml
Sun Microsystems. Java remote method invocation RMI v1.5. 2004.
Available on-line at http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf
Sun Microsystems. Java serialization v1.5. 2004. Available on-line at
http://java.sun.com/j2se/1.5/pdf/serial-spec.pdf
Ethereal, Inc. Ethereal: The world's most popular network protocol
analyzer. Available on line at http://www.ethereal.com/
Timesys.
JTime
virtual
machine.
Available
on-line
at
http://www.timesys.com/java/
Bollella, G. and Gosling, J. 2000. The Real-Time Specification for Java.
Computer 33, 6 (Jun. 2000), 47-54.
Reyna Ballesteros, A., and Gama Moreno, L. A. Embedded file
manager for mobile devices design and implementation. IEEE Latin
America Transactions, 5,8, (Dec. 2007). 638-643.
Basanta-Val, P., Almeida, L., Garcia-Valls, M., and Estevez-Ayres, I.
2007. Towards a Synchronous Scheduling Service on Top of a Unicast
Distributed Real-Time Java. In Proceedings of the 13th IEEE Real Time
and Embedded Technology and Applications Symposium (April 03 - 06,
2007). 123-132.
Estévez-Ayres, I., García-Valls, M., Almeida, L., and Basanta-Val, P.
2008. Solutions for Supporting Composition of Service-Based RealTime Applications. In Proceedings of the 2008 11th IEEE Symposium
on Object Oriented Real-Time Distributed Computing (May 05 - 07,
2008). 42-49.
VAL et al.: INTEGRATING MULTIPLEXING FACILITIES
Pablo Basanta Val nació en O Valadouro,
provincia de Lugo (España) en 1978. Obtuvo su
título de Ingeniero de Telecomunicación en la
Universidad de Vigo en el año 2001 y el de doctor
por la Universidad Carlos III de Madrid en el año
2007. Actualmente trabaja en el departamento de
Ingeniería Telemática de la Universidad Carlos III
de Madrid dentro del grupo de aplicaciones
telemáticas (GAST) en el laboratorio de tiempo real.
Su investigación gira alrededor del mundo de los
sistemas distribuidos de tiempo real Java, donde
recientemente completó su tesis doctoral: “Técnicas
y Extensiones para Java de tiempo real distribuido”.
Marisol García Valls nació en Castellón de la
Plana, provincia de Castellón (España) en 1973.
Obtuvo su título de Ingeniera en Informática en la
Universitat Jaume I de Castellón en el año 1996 y el
de doctora por la Universidad Politécnica de Madrid
en el año 2001. Actualmente es Profesora Titular de
Universidad en el Departamento de Ingeniería
Telemática de la Universidad Carlos III de Madrid.
Es la coordinadora del Laboratorio de Sistemas
Distribuidos y de Tiempo Real que pertenece al
Grupo de Aplicaciones Telemáticas (GAST) de esta
universidad. Su investigación se centra en la gestión de recursos y calidad de
servicio en plataformas middleware para sistemas embarcados de tiempo real
distribuidos.
Iria Estévez Ayres nació en Vigo, provincia de
Pontevedra (España) en 1978. Obtuvo su título de
Ingeniera de Telecomunicación en la Universidad de
Vigo en el año 2001 y el de doctora por la
Universidad Carlos III de Madrid en el año 2007.
Actualmente trabaja en el departamento de Ingeniería
Telemática de la Universidad Carlos III de Madrid
dentro del grupo de aplicaciones telemáticas (GAST)
en el laboratorio de tiempo real. Su investigación
gira alrededor de la composición dinámica de
servicios de tiempo real, donde recientemente completó su tesis doctoral:
“Técnicas de soporte a la flexibilidad funcional en sistemas embarcados
distribuidos de tiempo real”.
Jorge Fernández González nació en Madrid,
provincia de Madrid (España) en 1984. Obtuvo su
título de Ingeniero Técnico de Telecomunicación en
la especialidad de Telemática en la Universidad
Carlos III de Madrid en el año 2007. Actualmente
realiza los estudios conducentes a la obtención del
título de Ingeniero de Telecomunicación.
113