Information Technology Reference
In-Depth Information
An overview on the structure of the network manager is shown in Fig. 8. The
network manager consists of several distinct entities, some of them are modeled
in CARML while others are specified using RSL. The RSL code composing
these entities to form the network manager is presented in Fig. 9. The RSL main
program, which is not shown here, composes the peers and the network manager
the same way.
The basic idea behind the model of the network manager is that
registrationTable
- specified in CARML - keeps track of the server registrations, notices requests
from clients and generates indices
i, j
serving as reconfiguration signals
for the dynamically changing
P2PConnection
- specified in RSL. When peer
i
sends
the key for the
-th data package (
key
) indicating the request for
data
, then the
registrationTable
is aware which of the registered servers has the requested data. If
peer
j
is the one whose server side has already registered and has the requested
data, the
registrationTable
opens a server session by sending the signal
openSignal
via
the I/O-port
openSS
j
. Moreover it sends the indices
i
and
j
via the internal ports
I
and
J
to the
P2PConnection
.The
P2PConnection
then establishes a bidirectional
connection between peer
i
and peer
j
first for the requests and then for the
answers. The requests are kept in the
request buffer
and delivered to exactly one
of the ports
RI
[0]
,RI
[1] or
RI
[2] of the
P2PConnection
using an exclusive router
component (
EXROUTER
). After the connection has been established the request
is routed through the
P2PConnection
from
RI
[
i
]to
RO
[
j
], i.e, to
exReq
of peer
j
.
When the request is answered by the server side the data is delivered through
the
P2PConnection
from
AI
[
j
]to
AO
[
i
], i.e, from port
exAns
of peer
j
to port
myAns
of peer
i
. A copy of the data package is kept in the
release buffer
. In the next
step the copy is forwarded to the
registrationTable
generating new reconfiguration
signals on the internal I/O-ports
I
and
J
disconnecting the peers. Moreover, it
sends the signal
closeSignal
via the I/O-port
closeSS
j
to close the server session.
The network manager is now back in its initial configuration, ready for a new
request-answer-cycle.
The synchronous channels (
Sync
), the buffers (
FIFO1
), and the exclusive router
(
EXROUTER
) are part of
Ve r eo fy
's built-in library. The predefined channels and
component connectors from the library can be instantiated like any other com-
ponent. The composition of channels and components is done implicitly dur-
ing the instantiation by reusing port names in the
new
statements. If a port
name is used more than once the corresponding ports are joined. E.g. we write
new
FIFO1
(
A
;
B
);
new
FIFO1
(
B
;
C
) instead of
new
FIFO
(
A
;
B
1);
new
FIFO1
(
B
2;
C
);
B
=
join
(
B
1
,B
2). If the name of a port is
source
[
i
](or
sink
[
j
]) the port will be
the
i
-th source port (
j
-th sink port, respectively) of the interface of the network
manager. I.e., the network manager provides the interface shown in Table 1.
∈{
0
,
1
,
2
}
Dynamically changing network topologies.
We now focus on the dynami-
cally changing part of the network, i.e., the
P2PConnection
. As described above the
registrationTable
triggers a reconfiguration of the network topology. A
P2PConnection
manages a bidirectional communication between peer
i
and peer
j
on the basis of
the incoming signals at the I/O-ports
I
and
J
. These signals are simultaneously
