formation stores only to the visualization nodes in its
neighbor list, instead to all visualization nodes con-
nected to the system, reducing significantly network
and computing overhead.
3.2 Strategy 2: Neighbor Nodes Query
The process of reporting other nodes about the ter-
rain information stored in a given visualization node
cache may produce a significant overhead. In or-
der to avoid this overhead, we have developed a new
strategy that uses the same scheme of the strategy 1
(Figure 1), but where terrain information reporting
is avoided. In order to obtain the terrain data, a vi-
sualization node sends a message with the required
data to each node of its list of neighbor visualization
nodes. Each neighbor node answers back indicating
which required data are available in its cache. The
report also provides other parameters like the node
workload status or the network transmission latency.
These parameters are used by the visualization node
to estimate the response time of each neighbor node.
According to this information, the visualization node
selects one o more neighbor nodes in order to perform
a concurrent download of the terrain data required. If
none of the neighbor nodes stores the terrain data re-
quired or the estimated response time is too high (it
can be a serious problem for a fluid terrain visualiza-
tion in real time), the visualization node requests the
data terrain to its assigned support server.
The use of this strategy may supposes a signifi-
cant reduction in the number and size of the message
exchanged, reducing the overall processing time.
3.3 Strategy 3: Specialized Server
Cache
In a terrain visualization application, visualization
nodes usually require data about the region that they
are visualizing. In both strategies 1 and 2, a sup-
port server is assigned to each visualization node ex-
clusively using the criterion of the current workload
in the existing support servers. In order to improve
the use of the support servers, we have defined a
new strategy where the assignment of a given sup-
port server to each visualization node also takes into
account the region of the scene displayed by the visu-
alization node, selecting the support server that cur-
rently stores in its cache the greatest amount of terrain
data required by the visualization node and supports
a low workload. This support server selection is dy-
namic, changing over time in order to satisfy both cri-
teria. The scheme of this strategy is the same that the
one used in the strategies 1 and 2 (Figure 1). Obvi-
ously, this strategy makes sense when there are more
than one support server in the system.
4 PERFORMANCE EVALUATION
A remote terrain visualization system using an hybrid
P2P model can consist of a large number of clients,
requiring a lot of human and material resources that
result unaffordable for a single research team. There-
fore, we have implemented and tested an execution-
driven simulator that can measure the performance of
the hybrid P2P models when they are used in a remote
terrain interactive visualization system.
4.1 Simulator Characteristics
We have implemented a centralized, execution driven
simulator of the P2P system written in C++ which
follows a discrete event simulation methodology
(Sadoun, 2000). This simulator supports multiple
peer-to-peer networks structures and different net-
work characteristics like message transmission time,
network contention, transmission errors, network de-
lays or node saturation. In order to validate the simu-
lator, several tests have been carried out varying the
simulator configuration parameters. Some of these
parameters are: number of visualization nodes, num-
ber of support servers, cache size, request process
time, transmission time, transmission error, etc.
4.2 Simulator Validation
In order to validate a simulated model, it should be
compared with another reference model that can be
either real or simulated (Sargent, 2005). Since there
is not a comparable simulator for terrain visualization
systems in the literature, we also have implemented a
real terrain visualization system to validate it. A re-
duced number of visualization nodes has been used
(between 10 and 35), due to the limited resources
available. With this number of nodes it is not nec-
essary a large number of servers, so only one terrain
database server, one connectivity node and between 1
and 3 support servers have been used.
In a terrain visualization application, the move-
ment of the users in the virtual world can be quite
different over time. Some different initial user’s posi-
tion distribution and movement patterns distributions
are usually used to evaluate DVE systems (Morillo,
Rueda, Ordu˜na and Duato, 2007). We are going to
use similar distributions and patterns to evaluate our
new models. Initially, user’s position on the map is
NEW HYBRID P2P COMMUNICATION MODELS FOR REMOTE TERRAIN INTERACTIVE VISUALIZATION
SYSTEMS
415