4th International Conference on Principles and Practices ... - MADOC

In following, we will explain in detail the architecture of the
proposed M3PS. The M3PS provides four services: Synchronous
Message Transportation (SMT); PeerRoom Administration
(PRA); PeerCommunication Support (PCS) and ApplicationSpace
Management (ASM).
3.1 Synchronous Message Transportation
The SMT of M3PS consists of two modules: a message sender
and a message receiver, as shown in Fig. 4. The message sender
includes three main functional components: a data collector, a
message encoder and a message pusher. The message receiver
includes three correspondent components, a data distributor, a
message decoder and a message listener. The pipes are
abstractions of JXTA data transmission route on the JXTA virtual
network. There are three basic pipes: insecure unicast, secure
unicast and propagate types. The propagate pipe is used in SMT
for multicasting. In addition to the pipes used for group
communication inside rooms, a peer is able to exchange messages
with any individual peer and all peers in a collaborative
community, which is a collection of peers and rooms. Therefore
SMT provides three categorized transmission modes:
• Room mode: for group message multicasting among shared
applications in a room;
• Community mode: for message broadcasting to all peers in a
community;
• One-to-One mode: for one-to-one private message exchange
between any two peers in a community.
Thus, we have built three kinds of propagate pipes corresponding
to these modes. When receiving attribute data and/or primitive
data from the service modules or shared applications, the
messages will be formed based on the format shown in Fig. 5. The
Coding ID (CID) is used to extract the primitive data as well as
other data from a message. The Application ID (AID) is used for
uniquely identifying an application for correct data dispatch. The
Object ID (OID) and the source peer name elements are optional
for being used by shared application developers according to their
actual requirements.
The following four methods to send primitive data to all peers in a
room have been provided.
Type A: sendMsg(dest., source, CID, AID, OID)
ñ to send attribute data related to an application
Type B: sendMsg(dest., source, CID, AID, OID, string[])
ñ to send a string array used for chat text
Type C: sendMsg(dest., source, CID, AID, OID, integer[])
ñ to send integer array like mouse coordinates
Type D: sendMsg(dest., source, CID, AID, OID, byte[])
ñ to send binary file, audio and video data
3.2 PeerRoom Administration
Due to no server in our system, each peer is able to administrate
groups. This is a distinctive characteristic of M3PS compared
with others centralized and hybrid collaborative systems. In our
system, such work is done by the services of PRA, which is
responsible for room creation, publication and searching under
supported by the JXTA. Any room created by a peer must have a
unique name and ID number, and its associated group
advertisement should be generated and published on the JXTA
network so that other peers can find the room by searching the
room advertisement.
PeerRoom
Administration
Field Name
Transmission
Mode
Destination
Source
Coding ID (CID)
Application ID (AID)
Object ID (OID)
Element
PeerCommunication
Support
D
Data Collector
E
Message Encoder
M
Peers
Sender
Message Pusher
Pipe_out(M)
SMT
ApplicationSpace Shared
Management Applications
Receiver
Pipe_in(M)
Data Distributor
Peers
D (Data)
E (Elements)
Message Decoder
Message Listener
Figure 4. Message sender and receiver.
M (Message)
Room Community One-to-One
Room/Peer
Peer
Integer
Integer
Integer
Value
" Community " Peer
Peer
Integer
Integer
String, integer, byte String, integer, byte
Figure 5. Message formats.
Figure 6. Presence control.
Peer
Integer
Integer
String, integer, byte
It is very important and necessary to provide prompt and
correction awareness information of peers and rooms as well as
their dynamic changes. This function is provided by the awareness
monitor, which automatically and periodically collects status
information of peers and rooms in the community using presence
control and identity control. The presence control shows the
peerís presence information. As mentioned above, it is difficult to
administrate peersí presence in real-time only using
advertisements provided by JXTA core service. To provide
correct presence information, the ping-pong detection approach is
used to manage peersí presence in real-time as shown in Fig. 6.
226