HTTP Gateway and Modifications to WiFiCS

The HTTP Gateway manages the HTTP requests from Second Life to the WiFiCS. Each scenario in WiFiVL I and II were described using a URL only and this design choice has been followed through in WiFiSL, as such HTTP requests are required to gather the results of the simulation. The WiFiCS has been extended to facilitate the prohibitive environments of coding in Second Life.

There are strict limitations imposed on the amount of data that can be imported to Second Life. Second Life scripting allows for several ways to call out including Email, HTTP and XML-RPC (see section 4.11.2). The maximum payload of a HTTP call is set at 2048 characters. Both the XML and NAM version of a network trace are too large to import a sufficient number of events to enable a smooth playback of the simulation. This severe limit on the number of characters requires a new way of describing the network simulation in a compact and efficient way. Therefore a new library was developed and added to the WiFiCS to convert NAM into a compressed comma and colon delimited format. + -t 2.073511123 -s 1 -d 0 -p DSR –e 44 -c 2 -a 0 -i 51 -k RTR - -t 2.073511123 -s 1 -d 0 -p DSR -e 44 -c 2 -a 0 -i 51 -k RTR h -t 2.073511123 -s 1 -d 0 -p DSR -e 44 -c 2 -a 0 -i 51 -k RTR + -t 2.073986123 -s 1 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC - -t 2.073986123 -s 1 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC h -t 2.073986123 -s 1 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC r -t 2.074626312 -s 0 -d -1 -p ARP -e 28 -c 2 -a 0 -i 0 -k MAC + -t 2.074701312 -s 0 -d -1 -p RTS -e 44 -c 2 -a 0 -i 0 -k MAC - -t 2.074701312 -s 0 -d -1 -p RTS -e 44 -c 2 -a 0 -i 0 -k MAC h -t 2.074701312 -s 0 -d -1 -p RTS -e 44 -c 2 -a 0 -i 0 -k MAC r -t 2.075053500 -s 1 -d -1 -p RTS -e 44 -c 2 -a 0 -i 0 -k MAC + -t 2.075063500 -s 1 -d -1 -p CTS -e 38 -c 2 -a 0 -i 0 -k MAC - -t 2.075063500 -s 1 -d -1 -p CTS -e 38 -c 2 -a 0 -i 0 -k MAC h -t 2.075063500 -s 1 -d -1 -p CTS -e 38 -c 2 -a 0 -i 0 -k MAC r -t 2.075367689 -s 0 -d -1 -p CTS -e 38 -c 2 -a 0 -i 0 -k MAC + -t 2.075377689 -s 0 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC - -t 2.075377689 -s 0 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC h -t 2.075377689 -s 0 -d -1 -p ARP -e 80 -c 2 -a 0 -i 0 -k MAC r -t 2.075793877 -s 1 -d -1 -p ARP -e 28 -c 2 -a 0 -i 0 -k MAC

Figure 76: Typical NAM sample, 1202 characters

7,1,0,2.072511:2,1,-1,2.073986:0,0,-1,2.074701:1,1,-1,2.075063:2,0,-1,2.075377 Figure 77: Compressed scenario trace from NAM, 79 characters

integer RTS = 0; integer CTS = 1; integer ARP = 2; integer ack = 3; integer ACK = 4; integer TCP = 5; integer UDP = 6; integer DSR = 7; integer MOV=8; integer unknown = 9; integer CM8=10; integer AODV=11; integer TORA=12; integer packetTypeIndex=0; integer sourceNodeIndex=1; integer destinationNodeIndex=2; integer timeIndex=3;

Figure 78: LSL scripting constants used to access information from the compressed scenario trace in Figure 77

128

Figure 76 shows a sample output from an ns-2 simulation in the NAM format which details network events. The compression service strips out events that will not be shown to the user such as the enqueue and de-queuing of packets and looks only at events that are transmitted on the network. Each packet type is given a single lower or uppercase alpha or numeric code, allowing for 61 packet types to be described. The time value is shortened, losing two of the least significant values. This loss of precision in the time value does not affect the way the simulation is viewed as the time difference is negligible. Source and destination are put in a pre-defined position and the text and packet size is ignored. A generic description of the protocol is: [Packet_Type],[Source_Node],[Destination Node],[Time Of Event] as is demonstrated in Figure 77. Using this compression method, the network trace in Figure 76 is compressed to 15% of its original size. This compression service was the only addition to the WiFiCS. The construction of scenarios into a URL followed the same structure as WiFiVL I & II.

An additional helper filter was created that would allow indexing into the results of a simulation. Since Second Life was incapable of accepting large HTTP responses and storing these in variables, the starting result number and result size could be specified. This allows polling from the resource limited scripts in Second Life, allowing large simulations to be shown in Second Life.

Due to the small amount of size available per request, the Gateway must perform multiple HTTP requests. If the number of network events available to the Execution Scheduler is less than the threshold value of 10 (line 3), then a linked message is sent to the Scenario Collector (line 6). A flag is set so that when the script receives a HTTP response it will know that a simulation is in progress and that the results are related to the current simulation and are to be appended to the network events string (line 5).

When the Scenario Collector receives the link message, the offset into the simulation results is increased by a set size. This is increased until no more results are available from the WiFiCS Servlet, with the result size set to 25. The modified request is sent to the WiFiCS Servlet and the response is provided as a registered event. Once the results of the HTTP request are received, it is then passed back to the Execution Scheduler using a link message.

1. integer requestingMoreSimResults = 5;

2. if(noMoreResults!=1&&llGetListLength(eventList)<10){ 3. llOwnerSay("Requesting more results");

4. noMoreResults = 1;

5. llMessageLinked(LINK_THIS,requestingMoreSimResults,"",NULL_KEY); 6. }

Figure 79: LSL sample showing the Execution Scheduler and Scenario Collector in the Gateway communications to gather more simulation results from the WiFiCS Servlet

Access to advanced settings is held in a Notecard [281] which is part of the inventory of the All Seeing Orb. The Notecard is a text file held in an objects inventory and contains settings for the MAC protocol and sensing range of the nodes. The Notecard, its settings and comments are shown in Figure 80. Users can easily edit these advanced settings using the Second Life inbuilt editor. The comments provide alternative settings and the format they should be entered in.

129 dsr

11 75

//1st line is routing protocol, other options are: aodv, dsdv,flooding,tora

//2nd line is MAC protocol, other options are: 11, aloha,tdma - 11 is 802.11 protocol //3rd line is the sensing range

Figure 80: Advanced settings available to the user in Second Life