MD-ECI (Mobility and Disconnection Support for the Event-Based
Communication Interface)
Overview
The MD-ECI (Mobility and
Disconnection Support for the Event-Based Communication Interface) is an
extension of the ECI
publish/subscribe system. It handles the mobility of devices, implementing a
solution for Mobility Management at the application layer using the SIP
protocol. In addition, the system also implements mechanisms for handling
disconnection of event producers and consumers, and also firewall and NAT
traversal techniques, allowing the publish/subscribe system to be used on the
Internet, and not only on local networks.
The existing work on the literature about
mobility in publish/subscribe systems such as, (Caporuscio,
Carzaniga et al., 2003), (Cugola, Di
Nitto et al., 2001), (Fiege, Gartner
et al., 2003), (Mühl, Ulbrich
et al., 2004), (Zeidler e
Fiege, 2003) consider the mobility of a device,
used by a user registered on the system, as a sequence of move-in and move-out
operations between different event brokers which belong to a distributed
publish/subscribe infrastructure, established at different network locations.
Thus, the existing work has its main focus of research on algorithms for the
synchronization of subscriptions and routing of notifications between different
event brokers on which the device (executing an event producer or consumer)
attaches or detaches while moving. On the other hand, on the present work, the
mobility of a device is interpreted as a change (predicted or not) of is IP
address, considering that the device keeps registered on the same event broker.
Figure 1 – Mobility on the MD-ECI.
This kind of mobility support is
interesting because there is no need for the device to predict network changes
and at the same time, enabling it to have mobility awareness. This type of
mobility does not prohibit the MD-ECI, in future work, to be extended to or
incorporated at, a distributed publish/subscribe architecture with many event
brokers interconnected by an overlay network.
The M-SIP-UserAgent API. The MD-ECI uses a mobility
management solution on the application layer with the SIP protocol. This
solution was developed as an API called MSIPUA (Mobility SIP User
Agent). With this API the MD-ECI can provide support for the mobility of event
consumers and producers. The M-SIPUA API is coupled with the ECIAgent and
ECIBroker, allowing them to establish SIP communication sessions with each
other.
Figure 2 – M-SIP-UserAgent use by ECIAgent
and ECIBroker
When instancing ECIAgent or ECIBroker, the user
URI which is using the system must be informed (on the ECIBroker a URI of a
user representing the event broker must be created, such as sip:broker@domain).
The M-SIP-UserAgent API so sends a REGISTER message to the SIP Server at the
user´s domestic network (which must be configurable) with the mapping of the
user´s URI to the real network address of the User Agent he is using.
Figure
3 – Registering on the SIP Server of
the user´s domestic network
The URI of the event broker (the
ECIBroker instance) also must be configured on the ECIAgent, because when the
ECIAgent is initialized it has to establish a SIP session with the
M-SIP-UserAgent of the ECIBroker, session which will be kept during the whole
lifetime of both entities (see step 1 on Figure 4).
Figure 4 – Session establishment between
ECIAgent and ECIBroker
Established the session between the
ECIAgent and ECIBroker (see step 2 on Figure 4), the ECIBroker stores the session
on the ECI Session Manager (described below), in order to use it when
necessary. The ECIAgent only needs to keep the single established session with
the ECIBroker. Both sides of the communication can then use the data contained
in the SDP descriptions of the sessions to send and receive data, such as
subscriptions, notifications or any other type of message (see step 3 of Figure 4).
SIP Sessions management and use. On the original ECI, the user was
identified by its IP address and port. On the MD-EDI, the ECIBroker uses the
user´s location-independent identifier (for instance, the URI). The SIP
Sessions are used as the logical entity for organizing and managing the
interaction with the users.
Figure 5 – SIP Sessions management on the ECIBroker
The ECI Session Manager, is the component of
the ECIBroker responsible for managing all sessions established with the
ECIAgents. When a user using an ECIAgent establishes a session with the
ECIBroker´s M-SIP-UserAgent, the ECIBroker stores this session on the ECI
Session Manager (on the ECIAgent it is stored just one session, the one
established with the ECIBroker). The Figure 5 shows the ECIBroker´s ECI Session
Manager with many sessions for different users.
One of ECI´s main logical entities is the
Subscription, which contains the expression of interest (i.e. a filter over the
content) of events which the client wishes to receive. On the original ECI, a
Subscription was identified by the IP address and port of the device that sent
that Subscription, and these data was used for the sending of notifications.
With the use of the M-SIP-UserAgent as the Mobility Management solution, each
Subscription is identified by the URI of the user it belongs. Thus, for sending
a notification to the user, the ECIBroker uses the URI contained in the
Subscription to find the user´s SIP Session, and to send the notifications to
the real network address contained inside the SDP description which the user
has specified on the session.
The Figure 6 shows an example of a Subscription
identified by the user´s URI (user1@lac.inf.puc-rio.br). The subject
“StockExchange” indicates a hypothetical subject about events related to data
of the Stock Exchange. The subscription also contains a hypothetical expression
of interest “(Stock == PETR4) and (Price < 25)”, on which is specified that
the user is interested on events with the property “StockName” equals to
“PETR4” and the property “Price” with value lower than 25.
Figure 6 – Subscription identified by the
user´s URI
Terminal Mobility. The M-SIP-UserAgent API provides support for
terminal mobility for the MD-ECI. The Figure 7 shows how this functionality is
implemented using the SIP protocol. The RegistrationManager
has a thread which monitors the device´s current IP address. When this module
detects the change of the device´s address (possibly because of mobility), is
dispatches the sending of a new REGISTER message to the Registrar on the user´s
domestic network, in order to allow the user´s device to be located on its new
network address (step 1 on Figure 7). Any existing active SIP Session
is updated by the sending of a REINVITE message to the other participant (step
2 on Figure 7). Thus, the SIP and SDP data,
together with media data are updated with the new IP address on both User
Agents which are participants of the session. When the REINVITE is processed,
both the SIP Communication Status and the Media Communication Status states are
defined as CONNECTED, because it is assumed that after a session renegotiation,
both participants have their media descriptions compatible with the IP
addresses and ports on which they desire to change data (step 3 on Figure 7). Finally, both session
participants can restore the normal exchange of data (step 4 on Figure 7).
Figure 7 – Session restore after the mobility of a
publisher/subscriber
Disconnection Support. As all steps involved on the session
renegotiation caused by mobility require some time, on which ECI event
notifications cannot be delivered to the consumer, the service must also
provide support to the temporary disconnection of clients (event publishers and
subscribers). To handle disconnection, first it is necessary to define how this
state is detected by the system´s components.
As explained in the M-SIP-UserAgent page, the
Media Communication State (Remote Media State) contained inside the SIP Session,
indicates whether the other participant can be contacted on the addresses it
has specified on his SDP description. For example, a communication participant
A, to send data to other participant B, gets the remote SDP description from
the SIP Session (Remote SDP field), which contains the address on which the
participant B is waiting to receive data. If the communication protocol to be
used was TCP (which offers reliable data delivery), an exception thrown by the
Socket during the sending of data would mean that the participant B is
disconnected, because it cannot receive data on the address specified on the
session description. However, for publish/subscribe systems the use of the TCP
protocol would considerably increase the overhead on the communication between
system´s components. The UDP protocol does not provide reliable data delivery,
so in order to combine performance with reliability, an implementation of a
reliable UDP protocol has been adapted for the MD-ECI (an for the MoCA) called
RUDP (Reliable UDP) (Stevens e
Narten, 1990; Pitt, 2006), this API can be found here.
This protocol gives to each datagram packet
sent by a RUDP client a sequence number, which is used by the receiver (RUDP
server) to detect an eventual loss of some UDP packet. The RUDP server sends an
acknowledgement (ACK) packet for each packet it receives back to the client.
The client has an expiration time to wait for ACKs before a retry on the
sending of the packet. This expiration time is periodically tuned by a
roundtrip time, a timer that calculates the time a packet takes to be
transmitted and to be returned to the client as an ACK. Each sent and
successfully confirmed packed is used by the roundtrip timer to define ACK the
expiration time.
When a packet is sent and the client does not
receive an ACK packet on time, if the maximum number of retries has not been
achieved, the expiration time is exponentially increased (with a configurable
exponential factor) to avoid overcharging the network with packets. If the
maximum number of sending retries is achieved and a no ACK packet is received,
an exception is thrown to the upper software layer which is using the RUDP
protocol. Specifically to this work, when the publish/subscribe system tries to
send data through the network with a RUDP client and catches a sending
exception, this means that the receiver of the message cannot be contacted and,
thus, its
Figure 8 – Disconnection detection by the
ECIAgent and ECIBroker
It is assumed that the event broker (ECIBroker)
is always connected, on a node on the fixed network, when an ECIAgent can´t
send data to the ECIBroker, the ECIAgent implicitly infers that there is some
problem with it own connectivity. Therefore, it is defined that the ECIAgent
can detect is own disconnection when the Remote Media Status of its SIP Session
with the ECIBroker changes to DISCONNECTED.
The ECIAgent contains an auxiliary indicator
(just for organizing purposes) which indicates its connectivity state with the
ECIBroker, called ECIAgent Status. This indicator is actually always equal to
the current state of the Remote Media Status indicator of the established
session with the ECIBroker.
The ECIBroker can detect the disconnection of
an ECIAgent when some data can’t be sent to the ECIAgent. When this happens the
ECIBroker changes the Remote Media Status of the session with the correspondent
ECIAgent to DISCONNECTED). The ECIBroker also contains an auxiliary state
indicator for each user, which indicates the state of the ECIAgent´s
connectivity with the system, called User Status. Therefore, for the ECIBroker,
a session with the
When a new session is established between the an
ECIAgent and a ECIBroker, the Remote Media State inside the Session is defined
as CONNECTED for both sides of the communication, since it is assumed that on
the conclusion of a Session renegotiation both participants are ready to
exchange data through the addresses specified on their Session´s SDP
descriptions. This means that when a Session is updated, both participants
become immediately reconnected (until some interruption occurs on the data
exchange, which would define the state of the side which cannot be contacted as
DISCONNECTED).
Subscriptions
Expiration Time and Query of Subscriptions by the Client
The subscriptions are kept on the ECIBroker for
some time, event for disconnected users. They contain an attribute which
specified the limit of time they remain valid.
Figure 9 – Subscription with a defined expiration time
When the specified time of a subscription
expires, the subscription is removed from the ECIBroker. This verification
doesn’t need to be executed with a high periodicity, because the system doesn’t
generate notifications for expired subscriptions. Therefore, the ECIBroker
performs this verification every time it does the matching of events with
subscriptions. If there are queued notifications for a disconnected user,
correspondent to a cancelled subscription, they are not removed but are
delivered normally when the user reconnects, because they have been generated
when the subscription was still valid.
On a mobility scenario, a device could be
disconnected because it is not on the range of the wireless network or because
it has been turned off. On the case of the device being turned off, an ECIAgent
running on it would lose all its state (e.g. awareness of subscriptions it has
on the ECIBroker), so it would be necessary some persistent storage of
subscriptions on the ECIAgent. A mechanism that resolves such question is the
capacity of the ECIAgent to query the ECIBroker when needed (e.g. on
initialization) to get the list of existing subscriptions.
Persistent Notifications. When a
user is disconnected from the system and a published event matches with the a
user´s subscription, or when the user is still not defined as disconnected, but
it is not possible to deliver the generated notification (on this case the user
is defined as disconnected when the sending of the notification fails), the
notification is stored to be delivered when the user reconnects. This storage
is performed on queues inside the ECIBroker, indexed by the users´ URI. The
ECIBroker´s configuration properties allow the definition of notifications
queues maximum size.
Download
The Agent API can be found here and the Broker API can be found here.
Dependencies
The MSIPUA API can be found here.
Deploying
and Configuring
A sample configuration file for the Agent API
which can be customized for use can be found here.
A sample configuration file for the Broker API
which can be customized for use can be found here.
Using
MD-ECI
A test application which can be used to
illustrate the MDECI´s use and functionality can be found here.
The MDECI´s javadoc can be found here.
References
CAPORUSCIO, M.
et al. Design and Evaluation of a Support Service for Mobile, Wireless
Publish/Subscribe Applications. IEEE
TRANSACTIONS ON SOFTWARE ENGINEERING [S.I.], p. 1059-1071, 2003.
CUGOLA, G. et al. The JEDI Event-Based Infrastructure and Its Application to
the Development of the OPSS WFMS. IEEE
TRANSACTIONS ON SOFTWARE ENGINEERING [S.I.], p. 827-850, 2001.
FIEGE, L. et al. Supporting Mobility in Content-Based Publish/Subscribe
Middleware. LECTURE NOTES IN COMPUTER
SCIENCE [S.I.], p. 103-122, 2003.
MÜHL, G. et al. Disseminating Information to Mobile Clients Using
Publish-Subscribe. IEEE INTERNET
COMPUTING [S.I.], p. 46-53, 2004.
PITT, E. Fundamental Networking in Java. Springer, 2006.
STEVENS, W.; NARTEN, T. Unix
network programming. ACM SIGCOMM Computer
Communication Review [S.I.], v. 20, n. 2, p. 8-9, 1990.
ZEIDLER, A.; FIEGE, L.
Mobility support with REBECA. 2003. p.354-360.