![](bg2.png)
(Bauset et al., 2011). The system configuration con-
sists of this server and a certain amount of mobile de-
vices that are scanning the visual space of their video
camera looking for a marker that will be converted
into a 3D object in their display. After each updating
of the object location, the mobile device sends a loca-
tion update message (containing the new location) to
each of its neighbor devices. The neighbor devicesare
those who participate in the same collaborative task,
and we have denoted this set of neighbor devices as
a working group. The messages are sent through the
server (that is, it sends the location update message to
the server, and then the server re-sends the message to
the appropriate clients). For performance evaluation
purposes, the destination clients return an acknowl-
edgment message (ACK) to the server, which, in turn,
forwards it to the source client.
The system latency provided for each location up-
date is computed by recording a timestamp when the
first message is sent to the server. Next, a second
timestamp is recorded with the last ACK message for
that location update received from the server. The sys-
tem response time is computed by subtracting these
two timestamps. The server response time is com-
puted by timestamping both each message forwarded
from each client and the reception of the correspond-
ing ACK message from the destination client. Also,
the percentage of CPU utilization is measured both in
the server and the mobile devices every half second.
2.1 TCP Implementation
The simulator starts generating a Server Process, and
for every 50 clients it generates a Client Process. Fig-
ure 2 illustrates the general scheme of the Server Pro-
cess. This process starts listening connections, and
for each connection it generates a new array of X TCP
sockets, where X is the number of clients that will be
within a given working group. When all the clients
have connected to the Server Process (the population
size is a simulation parameter) then the Server Process
generates as many Server Threads as needed. Each
Server Thread is in charge of managing all the clients
within a working group. Concretely, it starts the simu-
lation by sending a welcome message to all the client
sockets. When the simulation finishes, it collects
statistics from all the clients in its working group. But
the most important task performed by server threads
is the generation of two threads for each of the clients
in the working group: the Server Receiver Thread
(SRT) and the Server Processor Thread (SPT). The
SRT associated to client i receives the location up-
date messages from the client i. Next, it computes
the correct destination clients (the neighbor clients,
that is, the clients within the same working group)
and it generates messages that will be stored in the
queues of the Server threads managing these neigh-
bor clients. The SPT associated to client i extracts the
queued messages that the SRTs associated to other
clients may have generated for client i, and it sends
them to this client. Additionally, the server process
collects and processes the statistics generated by the
server threads, and it also measures the percentage of
CPU utilization.
Figure 2: General scheme of the server process in the TCP
implementation.
Figure 3 illustrates the general scheme of the
Client Process. This process generates 50 client
threads (we have assumed a maximum population
size of 1000 client devices), and it also computes
the percentage of CPU utilization, client latencies,
etc.. Each Client Thread generates two threads for
each client: the Client Receiver Thread (CRT) and
the Client Processor Thread (CPT), and when the
welcome message from the Server Thread arrives to
the associated socket, then the Client Thread starts
the simulation, that consists of sending a given num-
ber of position update messages and receiving the
corresponding acknowledgments from the neighbor
clients.
Also, we developed another version where each
Server Thread has a single SRT and a single SPT for
managing all the clients in each working group, in-
stead of one SRT and one SPT for each client. Us-
ing the
Select
function, the SRT receives messages
from all the clients and it processes them. As it could
be expected, we obtained better performance results
with the Select version of the TCP implementation.
2.2 UDP Implementation
Finally, we have considered a connectionless oriented
implementation for the CAR system, in order to study
the effectiveness of TCP connections in a distributed
GRAPP2013-InternationalConferenceonComputerGraphicsTheoryandApplications
382