EL MUNDO DE LA DELINCUENCIA EN CALI, ALGUNAS TENDENCIAS

OpenSim is an open source virtual world that is compatible with the Second Life client and uses the Second Life Protocol (SLP) [53, 6, 97, 188, 102, 109]. It is written in C# using .Net or mono. The environment it provides is similar to Second Life. It has several possible physics engines, the main one being Open Dynamics Engine 7 _(ODE). The ODE physics engine is used in several games. It does not provide the same security model as Second Life.

7

(a) The relationship between the token buckets and queues. (b) The token bucket.

(c) A call graph of the throttle system.

Figure 8.14: The token bucket and queue throttle system.

An OpenSim setup can consist of one program or multiple programs. There are several services that it provides, the user service, the grid service, the inventory service, the asset service, the messaging service and the region service. In earlier versions of OpenSim if it was run as more than one program they had to be provided by a separate program for each service. In the version used the grid, inventory and asset services can be run as a single program. When OpenSim is run as several programs it is possible to have several region services running on different machines.

The user server handles the authentication of users the information about avatars. The grid server holds information about the location of islands in the grid. The inventory holds information about the user’s inventory with references to the assets. The asset server contains the assets.

8.4.1

OpenSim Packet throttle system.

The throttle system maintains compatibility with the Second Life client by using a compatible channel grouping. The channels are kept the same except the Task throttle is split into State, which contains the state of non avatar object and Task which contains all of the other packets that Second Life puts in Task. This takes the majority of the bytes of Task out of that channel leaving mostly avatar traffic. This achieves most of what the alternative channel design, described in section 8.1, was intended to achieve. In that is isolates the avatar traffic from other traffic and protects its bandwidth.

There are separate TokenBuckets [26] for each channel in each circuit, these are used to limit the amount of bandwidth used. The token buckets are emptied as packets for its channel are sent out onto the network. The token buckets work by filling at a constant rate up to the burst size value. When the bytes are to be sent out onto the network the number of tokens corresponding to the bytes sent are removed from the bucket, if there are not sufficient then the packet is queued. The LLUDPClient class handles the circuits and holds queues for the different channels. TheEnqueueOutgoingfunction finds the throttle and queue. It tries to remove the number of tokens corresponding to the packet size, if there were enough tokens the function returns false otherwise the packet is queued and the function returns true. This function is called from two other functions which send out the packet if the enqueue function returns false.

The function called to remove the token from the bucket calls the Drip function which refills the bucket by the correct amount for the length of time since the last call toDripup to the maximum burst size, which is the amount of traffic that can be sent out in one second. This happens before the attempt is made to remove the number of tokens equal to the amount of data to be sent. When there are packets being constantly sent out the burst rate limits the length of bursts in which queued packets will be sent and also the maximum amount that can be sent after a delay when no packets are being sent out. After the number of tokens has been checked the bucket checks if there is a parent bucket and then calls remove tokens on it if it exists. If there is no parent bucket or the call to remove tokens returns true, the number of tokens is reduced by the number of tokens to be removed.

TheDequeueOutgoing function loops through channels and tries to send a packet from queue. This function is periodically called by ClientOutgoingPacketHandler which is called by OutgoingPacketHandler for each circuit. This function runs a loop that sleeps for the clock granularity and then tries to send any queued packets. The function performs the sending of re-sent packets and ACK packets as well. If the packets were sent the function doesn’t sleep

Figure 8.15: The relationship between the token buckets and queues in OpenSim TR.

so the function caries on trying to send until it can’t any more and then sleeps.

Packets are either sent or added to the queue bySendPacketDataandResendUnacked. ResendUnackedis called by ClientOutgoingPacketHandler to resend reliable packets that haven’t been acknowledged and have timed out. TheSendPacketDatafunction is called by two functionsSendPacketandBroadcastPacket,BroadcastPacketsends the packet to all the clients in the scene. SendPacket is called by the functions that send ACKs and Ping packets, it is also called by the OutPacketfunctions in LLCLientView. TheOutPacketfunctions are called by the functions in LLCLientViewthat send the different types of packet. The throttle type of the packet is provided by these functions. This is illustrated by the diagram in figure 8.14.

This throttle system limits the sending rate to the correct value when there are always packets to send. If there are not packets to send for a second and then a large number of packets to send, the entire burst rate of packets will be sent out and the rest will be queued. The packets will then be sent out, this will result in almost two seconds worth of data being sent in one second. The long term average will not exceed the set value but the value for one second can be up to twice the set value.

8.4.2

Modified OpenSim server

The problem with the combination of the Mongoose client and the OpenSim server is that it limits each channel to the amount of bandwidth that the client allocates to it and the Mongoose client calculates a TCP fair total throttle value and shares this amongst the channels in a predefined way. It is desirable that the server limit its traffic to its TCP fair share and that it be able to use all of its TCP fair share when it has sufficient data to send. As the server uses the share that the client send to it, it would be possible to modify Mongoose so that it detects the OpenSim server and sends different throttle values.

If a modified client were used it would have to change the share of the bandwidth that each channel is given. This would mean that the Texture channel would be given more bandwidth. The other channels are however still used so, the options are to remove bandwidth from other channels to give to the Texture channel in which case they would be more limited in their bandwidth usage than intended. The alternative is to increase the Texture channel without changing the others this would result in the server sometimes using more than its TCP fair share of the bandwidth.

The alternative to modifying the Mongoose client further is to modify the OpenSim server so that it can share out unused bandwidth to the channel that have more data to send. This allows the total value to be sent from the server to be limited to the TCP fair value sent from the client and to uses as much of that bandwidth as it has data to use. There are different ways in which the OpenSim server could have been modified. The token buckets could have been replaced with another type of traffic limiting system, this would require more changes to the server than modifying the token bucket system. The token bucket system works well to limit the bandwidth used so it is reasonable to keep it. It would be possible to limit the bandwidth for each channel to there allocated bandwidth when the bandwidth usage reaches the maximum or to change the bandwidth share to allow the channels with more bandwidth to use the unused bandwidth.

The design of the throttle system is a token bucket for each channel and parent bucket for all of those buckets that limits the overall bandwidth for the circuit. The overall bucket does not limit the bandwidth in the unmodified OpenSim server unless it is configured to. The OpenSim server’s throttle system is good at limiting to what the client requests, if the per channel throttles are to be enforced rather than the total throttle value. This is not the behaviour that Second Life has and it is not important to the network that the share between OpenSim’s channels is maintained. The behaviour of guaranteeing that a channel can get the amount of bandwidth that is allocated to it is important and stopping the total bandwidth usage exceeding the total throttle value is important. The behaviour of not using the spare bandwidth that channels are not using is not desirable as it reduces the utility the system gets from the network and reduces the bandwidth usage below the correct value.

It is therefore desirable to modify the throttle system so that it limits the total bandwidth usage to the total throttle value. It should also not limit the channels to their throttle value unless this will result in another channel

not being able to use up to its throttle value. The design of the new throttle system is such that when packets are to be sent and there is sufficient throttle left they are sent out and otherwise they are queued. This results in a two layer throttle system. The queued packets are then sent out through a round robin system that goes through the channels and sends out a packet from each channel that has one to send each time round. The design of the modified system will not queue packets until sending is stopped by the total throttle and then the sending from the queues is limited by the per channel throttles.

The design of the new throttle system is that there is a top level throttle system to limit the total bandwidth and channel level throttle to distribute the bandwidth between the channels in the desired proportions, this is illustrated by figure 8.15. At both levels of this system token buckets are used where the tokens fill up at a constant rate and there is a burst rate value that limits that number of tokens that can accumulate. The token buckets at both levels are the same but the channel level ones do not limit transmission so long as there is unused bandwidth. There is limitation by the channel token buckets when the there is not spare bandwidth, the token buckets then distribute the bandwidth between channels. When the bandwidth runs out the packets are queued and the system iterates through the queues and token buckets. The system moves through the channels in a round robin system until no packets can be sent.

The throttle system has been modified so that the total bucket limited the bandwidth usage to the maximum value. The channel buckets were modified to not limit the amount of bandwidth usage of packets that haven’t been queued. This was achieved by setting the total buckets burst rate to, initially, the total bandwidth and creating a new function inTokenBuckets. The new function calls the parent bucket’s remove tokens function if there is one and the bucket doesn’t have sufficient tokens and returns true if this function returns true.

This should mean that when there is data to send the bandwidth reaches the global throttle value and that each channel gets at least its throttle value of bandwidth sent. So traffic from one channel should not be able to interfere with the traffic from other channels. The design of the OpenSim channels is that the non-avatar objects are separated from the Task channel they should not interfere with avatar traffic.

With a burst rate of one second of data the modified server is able to send at the rate sent from the client. The rate however spikes up to twice the rate for the reason described in section 8.4.1. The server was further modified to use a burst rate that is a fraction of a second’s worth of data. When the value is too small the server is unable to achieve the specified sending rate, though the sending rate that it does achieve is more stable. This modified version of OpenSim will be called OpenSim TR (Throttle Redistributing).

8.4.3

Summary

The OpenSim server provides environment that is similar to that provided by Second Life. It uses the same protocol and responds to the throttle packets sent from the client. The throttle system used by OpenSim is different from the one used by Second Life and it splits up the task channel packets into two channels, Task and State. This throttle system is more strict than the one used by Second Life. The modifications made to the throttle system maintain the strictness of the overall throttle but remove the strictness of the per channel throttles and allows unused throttle to be redistributed.