E ff ect of RTT between Mobile Device and Proxy

The experiments in this section has theRemotePrintViaProxymobile application communicate with theRemote Printing service. It is assumed that all required proxy services are available on all proxies and the CPU load on the proxies is not taken into consideration. This means that the only factor used in selecting a proxy is the proximity. This is an acceptable condition since theRemote Printingapplication occasionally involves the transmission of large files from the mobile device to the remote service and as a result the response time of the application depends on the RTT between mobile device and proxy.

RTT Simulation and Assumptions

The experimental environment is described in section 4.4.3. The challenge with experi- ments results from the use of the Western campus network for communication between the cellphone and the servers. We do not have control over network load and hence there is a need for RTT simulation.

It is assumed that the RTT affects only the file transmissions from mobile applications. This means that we assume that the RTT does not affect the call to services when:

1. no file transmission is involved in calling the service, and

2. calling the service involves file transmission, but the client and the service are running on wired machines

The assumptions are for experimental purposes. We are primarily interested in the RTT incurred by wireless communications.

Several experiments were carried out to find the approximate RTT between components of the system, i.e. mobile device, machines hosting proxies, and the server hosting Printing Service. In these experiments the result of the ping command between machines hosting prox- ies and Printing Serviceshowed that RTT values are negligible, i.e. less that 4 milliseconds. The reason is that all of these machines are connected to the same LAN. Consequently, it was decided to ignore the real RTT between wired components when gathering results during the experiments.

During the execution of RemotePrintViaProxy file transmissions occur between the Re- motePrintViaProxy mobile application and theDataTransfer proxy service on the proxy, and between theDataTransferproxy service and thePrinting Service.

Although calling the service involves file transmission between the proxy and the server running the remote service, we do not consider RTT since the proxy and the server are on the same wired network. Furthermore since the proxy machine and the server with the remote service are on the same LAN there is little variability in the time it takes to transfer a file. RTT simulation is done for file transmission from the mobile application to theDataTransferproxy service when executing theRemotePrintViaProxy. In addition, the RTT is not simulated in the call of theCodeExecproxy service from theRemotePrintViaProxysince no file transmission is involved. Likewise, no call to thePrinting Finderis done in the experiments presented in this section since no file transmission is included in calling thePrinter Finder service,.

Socket programming is used for file transmission in the implementation of theDataTransfer

proxy service. The server socket is part of theDataTransfer proxy service on the proxy, while the client socket is part of the API provided for the mobile application and resides on the mobile device. To simulate the RTT, the client socket, on the mobile device, sleeps for the simulated value for the RTT, before every write to the connection.

Experiments

The experiments presented in this section shows that impact of RTT on application perfor- mance.

The values used for the simulation of RTT are shown in the first column on table 4.4. These values are chosen based on several experiments that were performed in order to estimate the value of RTT from the mobile device to remote machines located at various locations. As expected, it was shown that RTT values between the mobile device and a remote host is not fixed over the time and fluctuates in a range. As a result, it is more realistic to generate RTT values from a range, instead of using a fixed value. Consequently, the RTT values are randomly generated from a range to simulate the fluctuations in the RTT in the real world. Based on the initial experimental results, it is assumed that in a steady state environment that the load of data transmission in communication links does not drastically change. Thus we have RTT values changing in intervals of length 5 msec. The intervals are shown in the first column of the table 4.4, and the average of the RTT values, generated from each interval, are calculated and shown in the second column of the table.

TheRemotePrintViaProxyapplication is executed five times. The time to call thePrinting Serviceis measured for each run. The result, that is averaged over five runs, is shown in the third column of table 4.4. As can be seen from table, higher RTT values resulted in higher execution times. This shows that it is beneficial to use proxies that are closer to the mobile device, i.e. have smaller RTT to the mobile device. The results show that for this application,

which involves data transmission between the mobile application and the proxy, it is beneficial to have a proxy discovery mechanism that finds a proxy with the smallest RTT.

Table 4.4: Time for Calling Printing Service with Various RTT values Simulated RTT

Range (msec)

Average Simulated RTT

(msec)

Time for Calling Printing Service (sec) [40,45] 42.18 172.01 [35,40] 36.89 151.46 [30,35] 32.40 135.12 [25,30] 26.77 113.54 [20,25] 21.88 95.23 [15,20] 16.51 73.70 [10,15] 11.71 53.30 [5,10] 7.42 35.80 [0,5] 0.84 10.21