Time Controlled Network Traﬃc Shaper

(1)

Time Controlled Network

Traﬃc Shaper

Kamran Yousuf

Karlskrona, January 2010

Department of Telecommunication Systems School of Engineering

(2)

(3)

Abstract

Network performance metrics such as delay variations and packet loss in-fluence the performance of the network. As a consequence, the performance of applications on the network is also affected as most of the networked applications existing today are very much sensitive to the network performance. Therefore it is of utmost importance to test the intensity of such network level disturbances on the performance of applications. A network traffic shaper/emulator shapes the network traffic in terms of these performance metrics to test such applications in a controlled environment. Most of the traffic shapers existing today give the instantaneous step transition in delay and packet loss on network. In this work, we present time-controlled network traffic shaper, a tool that facilitates testing and experimentation of network traffic through emulation. It focuses on time variant behavior of the traffic shaper. A linear transition of delay and packet loss that is varying with respect to time may fits much better to the real network scenarios instead of an instantaneous step transition in delay and packet loss. This work illustrates the emulation capabilities of time-controlled network traffic shaper and presents its design architecture. Several approaches are analyzed to do the task and one of them is followed to develop the desired architecture of the shaper. The shaper is implemented in a small scenario and is tested to see whether the desired output is achieved or not. The shortfalls in the design of the shaper are also discussed. Results are presented that show the output from the shaper in graphical form. Although the current implementation of the shaper does not provide linear or exponential output but this can be achieved by im-plementing a configuration setting that is comprised of small transition values that are varying with respect to very small step sizes of time e.g. transitions on milli seconds or micro seconds. The current implementation of the shaper configuration provides the output with a transition of one milli second on every next second.

Keywords

(4)

(5)

Acknowledgements

First of all I would like to thank Almighty Allah who made me able to work. I would like to express my deepest gratitude to my supervisor, Dr. Arlos for his untiring support, guidance, supervision, motivations and deepest interest in my work. Your approach towards your students is really appreciating. I found you a good friend, a good supervisor and even like a guardian when I needed. I am thankful to the department of Telecommunication at Blekinge institute of technology for allowing me to use of its equipements that was required for the whole work.

I would like to thank Mr. Junaid Shaikh (PhD student at Blekinge institute of technology) for his advices and motivation. Thanks to you for your moral support on each step of my failure approach. I am grateful to Mr. Tahir Nawaz Minhas as well for his motivations.

I Would like to thank my parents and other family members for the kind support. Without their support I was not able to stand where I am today.

I thank to everybody including my collegues and friends who helped me by any means.

Kamran Yousuf

(6)

(7)

Introduction

The ability of the traffic shaper to change its behaviour with respect to time can provide better output results to test the applications that are very sensitive to network performance metrics. This thesis aims on the time variant behaviour of the shaper. It works on two performance metrices that are delay and packet loss. It applies a varying amount of delay on incoming packets and follows a certain pattern for packet loss. A predefined pattern is followed to add increasing amount of delay on each incoming packet. The implementation of varying amount of delay is comprised of set of values that increases with a step change of one milli second. This pattern follows till an hour and then the shaper resets the amount of added delay to zero and the process goes on. To implement packet loss, number of incoming packets at a specific second are dropped by reading the system clock and a same pattern is followed.

A network traffic shaper is a software application that is used to create an artificial disturbance in the network traffic by increasing delay, packet loss and/or other performance metrics. This artificial disturbance by means of delay or packet loss is predefined. When the shaper is set to these parameters to impose delay and packet loss, either on incoming interface or on outgoing interface, all the traffic passing through the shaper will be effected. So an artificial behaviour of Internet is created in a controlled environment. Later, the applications that have performance issues are tested in such controlled environment and the degree of degradation of the application can be analyzed in a controlled environment.

Traffic shaping is an action which imposes a required amount of any of the network performance metrics (such as delay, packet loss) on a set of packets (often called stream), such that to comply with some predetermined constraints. Traffic shaping provides a away to control the volume of traffic being sent into a network in a specified period (bandwidth throttling), or maximum rate at which the traffic is sent (rate limiting) [1]. Traffic shaping is commonly applied on the incoming or outgoing traffic to the traffic shaper.

(10)

architec-ture or the code (such as jitter buﬀers in multimedia applications) that deals with such situations (delay variations, packet loss) in many appications is diaganosed and solved, the application is pushed back to WAN.

There are many network performance metrics that are commonly used to characterize the performance of a network or some part of the network. Some of these metrics are one-way delay (OWD) [2], round-trip time (RTT) [3][4], delay variation or jitter [5], packet loss [6][7][8], packet reordering [9] and maximum transmission unit (MTU) [10]. These metrics have a great impact on the net-work performance and they influence the end-to-end netnet-work performance (per-formance of a network between two ends). A network traffic shaper or a network emulator is a software that allows to generate these metrics (known as shaper settings or emulation options) in the network and to build a scenario to check the performance of the real-time applications. Next paragraphs discusses these metrics, their impact on the real-time applications, how they influence the end-to-end network performance and how these metrics can be gained in a network using traffic shaper.

One-way delay is always present in the network links or paths. It is the time that a packet takes from the source to the destination [2]. RTT and Delay variation are two metrics that are derived from One-way delay. While studying end-to-end performance, RTT and delay variation are interesting metrics to look at. Delay variation is also known as jitter. It represents variations in one way delay and it is important for real-time applications. RTT is the total time taken by a packet sent by a node A to reach its destination B, and the response sent by destination B to reach A. Delay variation describes the level of disturbance of packet arrival times with respect to an ideal pattern, typically the pattern in which the packets were sent. Such disturbances can be caused by competing traffic (i.e. queuing), or by contention on processing resources in the network [5]. Packet loss is the probability of a packet to be lost in transit from source to desti-nation [6]. Packet loss can also happen due to corruption. In corruption, parts of packet are modified in-transit. Such corruptions comes due to noisy links and it is usually detected by the checksum field at destination. If it is found at the des-tination that the packet is corrupted then that packet is discarded. The internet protocol (IP) [11] does not guarantee that packets are delivered in the order in which they were sent. This was a deliberate design choice that distinguishes IP from protocols such as, for instance, asynchronous transfer mode (ATM) [12][13] and Ethernet[14]. Applications that use transport protocol, like transmission control protocol (TCP) [15], don’t worry about the packet reordering because the transport protcol is responsible for reassembling the byte stream. Packet reordering can have a severe impact on some implementations of TCP. MTU or protcol MTU (since it is different for different protocols such as 1500 bytes for ethernet or WLAN, 4470 bytes for fiber distributed data interface (FDDI) [16], 9180 bytes for ATM) is maximum size of an IP packet that can be transmitted over a network link without fragmentation.

(11)

as in the real-time transport protocol (RTP) [18] are stored in the jitter buffers until their playout time has arrived. By temporarily storing the packets, jitter buffers converts the delay variation into delay. As large is the jitter buffer as large delay variations can be handled at the cost of significant increase in delay. The code that manages these buffers is sometimes not written in perfect way so that such problems are dealt nicely. Although, it can be done by putting more effort on the design architecture. To research on such applications, there are different solutions that are either very expensive or there are proprietary issues. For the experiment purpose, reproducing such scenarios (with packet loss, delay vari-ations, packet reordering) in a controlled environment, different traffic shapers have been developed till now. Few of them are open source and freely available on internet. Section 1.1 briefly discusses few shapers and emulators that have already been developed.

1.1 Related work

For research purpose, to reproduce this behaviour of Internet, different software solutions have already been developed and most of them are public domains that are freely and easily available on Internet. These are available for research purpose and easy to use and user can change it according to its use. NetEm [19][20], NIST Net [21][22], DummyNet [23] and KauNet [24]are commonly known network traffic shapers. Next paragraphs of this section briefly discusses about these traffic shapers.

NetEm [19] is a Linux Kernel module to emulate network traffic. It is en-hancement in the Linux traffic control facilities (TC). Packets can be handled by NetEm by imposing delay, packet loss and other emulation options provided by NetEm. It uses queuing disciplines to handle packets to provide different treat-ment by the kernel during transmission i.e. packet delays, priorities and packet dropping etc. NetEm provides two types of queuing disciplines that are Classless queuing discipline and Class full queuing discipline [19][20].

NIST Net [21] is a Linux Kernel extension that provides complex delay, packet loss, and other emulation options. NIST Net also does the filtering mechanism at its own. NIST Net works as a router which emulates the behaviour of the whole network being a single hop and can apply packet loss and delay jitter to the traffic passing through it. NIST Net treats traffic on flow basis and thousand of packet entries can be loaded at a time. Then these packets are treated according to the matching rule set. The entries in the table can be controlled manually or programmatically during emulator operation. NIST Net consists of two parts, a loadable kernel module and a set of user interfaces. The user interface allows multiple processes to control the emulator simultaneously. Two user interfaces are provided with the code, a simple Command Line Interface (CLI) and an interactive Graphical User Interface (GUI). NIST Net is famous and has been widely used in academic and research laboratories due to its ease of installation and use [21][22].

(12)

controlled by IP Firewall (IP FW) commands [23].

KauNet [24] is a network emulator that provides control on bit error, packet loss, bandwidth, and delay changes. Using Kaunet, reproducible behaviour of network along with an exact control on network traﬃc over Internet can be pro-vided. KauNet is an extension of the DummyNet network emulator, introducing a new facility of pattern generation and management [24][25].

1.2 Contribution

Existing shapers do not deal with the transitions in delay with variation of time. A linear transition of delay can give better required results compared to an in-stantaneous step size in delay. An inin-stantaneous behaviour of delay transitions causes delay variations or jerks that can effect the performance of any applicatin which is sensitive to delay variations. While, a time variant linear increase or decrease of delay and/or packet loss can give much better results. A static or randomly generated, fixed or varying pattern of values is required to define the amount of shaping in advance for the incoming packets. Such that, it is seen for the packets coming to the shaper that during what time they arrived. When their arrival time is found, predefined shaper setting is seen for the packets arriving at this time and the packets are shaped accordingly. Compared to an instantaneous output from the shaper, the linear increase or decrease in delay and/or packet loss will provide a linear input to the applications and can better help to find out at what level of degradation, the application started performing poorly. Figure 1.1 and 1.2 shows an example of how delay and packet loss can varry with respect to time.

Figure 1.1: Delay graph varying with respect to time

Figure 1.1 Shows the time varying delay graph. The output linear or expo-nential traﬃc from the shaper varying with respect to time is supposed to be like this. Figure 1.1 represents that the shaper starts shaping the incoming traﬃc using a certain pattern at time t1 and it follows the same pattern till it reaches

(13)

The delay line shows a linear increase and decrease in the delay that is amount of delay applied to the incoming packets is varying with respect to time. In a similar fashion, packet loss is implemented as shown in the packet loss graph in figure 1.2. Here, the packets are dropped at some predefined seconds of the hour. Suppose the packets that came at multiple of five second are supposed to be dropped by the shaper. For example, all the packets that are captured by the shaper at every 5th _{micro second or any random micro second are dropped by} the shaper regardless of how many number of packets are captured during that micro second.

Figure 1.2: Packet Loss (in terms of packets) varying with respect to time The design of this tool requires to change its shaping setting (emulation op-tions) with respect to time. Such that, for a certain period of time, the shaper treats the traffic in a similar fashion. Same pattern of predefined shaped data is used to add time variant delay and packet loss to the incoming traffic. After some specific clock time, when the shaper setting needs to be changed, shaper starts shaping differently by loading some other shaper setting. During one shaper setting that will be valid for a certain period of time, shaper is having two im-portant things. One is the transition in time (after how long, in terms of minutes, seconds, milli seconds, the shaper changes the shpaed value)and the other is the step size (increment in the shaped value on each transition). Another type of transition happens when the shaper switches from one shaper setting to other shaper setting. Hence, the time this shaper setting will be valid, shaper will treat the traffic accordingly and similar pattern will be followed.

(14)

the output traﬃc and the delay variation or jerk problem will also be minimized.

1.3 Outline

(15)

Chapter 2

System Analysis

This chapter is comprised of all the issues and experiments that are undergone during the analysis of the system. Different problems like packet buffer handling and configuration of the system are identified. Different approaches are found to solve these problemes. The main challenge of this project is to develop a tool that will perform shaping with capability of applying increase or decrease in delay and packet loss, linearly, with respect to time. The main problem identified in this project is to have a time variant behaviour of the shaper that is the shaper changes its behaviour with respect to time and the selection of configuration settings for proper delay transition values.

2.1 System Design

System architecture design describes the entire sturcture of the system. It is important here to have a better analysis on the design architecture. Two types of design architecture are analyzed in this sub chapter. Both approaches can be implemented.

2.1.1 One capture and one sender process for all interfaces

(16)

Figure 2.1: One capture and one sender process for all interfaces

interface if it ﬁnds packets coming up on other interface as well. It needs to tag each packet by adding some extra information or by maintaining a table as packet are coming from more than one interfac and they need to be transmitted on diﬀerent interfaces.

2.1.2 One capture and one sender process for each interface

This approach contains two processes, that are capture process and sender pro-cess, for each interface. On each interface one capture process capture the pack-ets. After treatment, it stores the packet in the linked list. Sender process retrieves this packet and sends it on its playout time through the other interface.

Figure 2.2: One capture and sender process for each interface

(17)

process is started for each interface to capture or to send packets.

2.2 Packet buﬀer handling

Different approaches are analyzed to handle the incoming traffic to the shaper. In each approach, memory is being shared between atleast two processes. So that, these processes needs to be synchronized. Mutex locks and semaphores are good to use in such cases where memory is shared among different processes.

2.2.1 Two lists to handle the incoming traﬃc

In this approach, two linked lists are required. Figure 2.3 represents that the first list takes the packets in FIFO order and releases accordingly. Second list stores the packet after the treatment. Such that, FIFO list is only used by the capture process and the other list is shared between capture and sender buffer. FIFO list is useful when the shaper allows filtering of the packets. When packets reach to the shaper, it stores them in the order they are arrived. Filter process reads this list and does filtering of packets by reading protocol bytes of the headers in the packet. If the packet needs to be treated then that packet is treated and stroed in the second list.

(18)

a time. Although, capture process can wait here to write to the second list but it does not effect the functionality of the packet capturing. Instead, handling of two lists by capture process takes time as the first list is continuously filling by the incoming traffic and the second list is storing the packets after filtering and treatment. So, continuously retrieving the packets from the FIFO list, filtering them, applying shaping or dropping and storing in the other list increases the processing time of the capture process.

2.2.2 Several lists to hold the treated packets

This approach contains multiple lists, as shown in the ﬁgure 2.4, to temporarily store the treated packets. In this approach, capture process uses one list to continuously stores the captured packets in a FIFO order.

Figure 2.4: Several lists to hold the treated packets

After the treatment, the packets are stored in the diﬀerent lists according the their play out time. Such that, there are multiple lists for the treated pack-ets. Each list has a certain bound, of the play out time, for the packets to be transmitted. Such that, ﬁrst list store the packets having play out time less than 250 ms, second list store the packets having play out time less than 500 ms and so on. The sender process reads these lists accordningly. It reads each list by smallest to biggest and sees the play out time of the packet and does the sending operation. This approach takes more time as the capture and sender process keeps on accessing multiple lists. Although, this approach increases the packet capturing functionality of the capture process but the synchronization of cap-ture and sender prcoesses to access these multiple lists becomes complex and it decreases the overall performance.

2.2.3 One list shared between two process

(19)

Figure 2.5: Synchronization of the two processes to access same memory

Figure 2.6 and 2.7 seperately shows that when one process is writing to the memory, the other process is locked.

This approach takes the minimal time and both the process shares the same memory eﬃciently. Some of the incoming packets can be dropped, if the capture process receives a new packet and it does not get access to the list. In other words, sender is sending the packets and new packets comes to the interface and capture process does not get a chance to store them and they drop. Capture process, always needs more time to write to the list as it is continuously capturing incoming packets, regardless, they are required to send or not. In this approach, when the sender retrieves a packet at its play out time, then, it deletes that memory location. This can be handled in such a way that when a memory location is being accessed by the sender process, then, a ﬂag can be used for those location that contains a packet that has already been sent. Such that no need of deleting any of the nodes of the list and new packets can be handled by over writing the previous locations. This can also be done by freeing the memory location after sending the packet on its play out time.

2.2.4 Capture process with multiple child processes

(20)

Figure 2.6: When Capture process writes the memory and Sender process is blocked

Figure 2.7: When Sender process reads/writes to the memory and capture process is blocked

child process holds a packet and waits until the lock is released and child gets time to write on the list. The child process ﬁnishes after doing its operation. This approach lets the capture process to work without waiting to get its turn to capture the packets as in other approaches. The problem

2.2.5 Creating thread pool for capture process

(21)

free ﬂag will be set to ’1’ that will show that this thread in the pool can hold a packet now.

2.3 Conﬁguration of the system

This subchapter discusses different configuration approaches that can be useful to use as different shaper settings. Each shaper setting is a certain pattern of values that may repeat or change itself at some specific time. Each setting can have a start time and finish time that tells that at what time, how the input traffic to the shaper will be handled. Shaper loads these settings at start up and adds an appropiate shaped value on each incoming packets.

2.3.1 Statically generated a predeﬁned conﬁguration

set-ting

This configuration is comprised of a configuration file that includes different predefined shaper settings in it. Each of these shaper settings have a start and end time and are comprised a certain pattern of shaped values. This pattern continues till the shaper setting is valid. At start up, the system reads the configuration file and sees that which shaper setting is for this time. It loads this setting and then starts treating the incoming traffic accordingly. When this shaper setting ends up, the system repeats the setting or switches to some other shaper setting by reading the configuration file. Figure 2.8 shows this configuration setting.

(22)

2.3.2 Dynamically generated conﬁguration setting

The configuration presented in figure 2.9, the system has got some pattern in-formation at startup and it generates a certain number of randomly generated shaped values. The user, at start up provides information like when to start, when to end, what transition of time to use, what pattern should be used while generating random vlaues. Later, this shaper setting is used to treat the incom-ing traffic until the shaper settincom-ing does not end up. In this approach, the shaped value can be generated at run time but it increases the processing time of the system and reduces the functionality of the capture process.

Figure 2.9: Randomly generated shaper setting

2.3.3 Changes on demand

(23)

Chapter 3

Design architecture of

TCNTS

This chapter is comprised of the overall design phase of the shaper. It includes a high level design and a low level deeper view of the whole system.

3.1 High Level Design

TCNTS works between the two network interfaces for shaping the incoming pack-ets. It requires that the Linux must be running on the computer and the it must have atleast two network interfaces. The shaper captures traﬃc on one interface, applies amount of delay and packet loss and sends the packets through the other interface and it does the same operation for the second interface. For example, packets captured at interface NIC-1 would be forwarded through NIC-2, after being treated and those captured at NIC-2 would be forwarded through NIC-1, after the treatment. Since the shaper operates between two interfaces, so that, it does not need any address table to note the incoming packets and to send them to their destination. Currently, the shaper is designed to operate between two interfaces. If it is required to operate between more than two interfaces, then, shaper would require to maintain an address table that keeps the information of source and destination addresses.

Figure 3.1: High level design of TCNTS

(24)

incoming packets by its capture process and after shaping the packets, it stores the packets using a linked list with a time stamp attached to it. Then, the sender process sends this packet to the destination upon its play out time. Later sections of this chapter describes the design of each process in details.

To handle the network traﬃc coming to the shaper, four processes are required to work together. Since, these processes shares same memory so they need to be synchronized as shown in ﬁgure 3.2.

Figure 3.2: Object diagram of the system

In figure 3.2, it is shown that two processes works together to handle the traffic of one direction and two processes handles the traffic of other direction. These two sets of processes work concurrently, such that, they share same memory. Capture1 and sender1 threads share the same memory, that is, capture1 captures packet at NIC-1 and stores in a linked list and the sender1 retrieve these packets from the linked list and sends through NIC-2. To share the same memory between these processes require to allow any of the two processes to access the memory at a time. For example, if capture1 needs a write operation on the memory, then, locking sender1 and if the sender1 needs a write operation on the memory, then, locking capture1. Same operation is done for the other direction of the traffic where capture2 and sender2 processes operate together and share same memory.

3.2 Low Level Design

(25)

The amount of delay is added to the time stamp of the packet that is noted when the packet is being captured. This amount of delay varries with respect to time and is added into the micro seconds portion of the time stamp of the packet, in milli seconds. Sender process that is working in parallel with capture process, then, continuously reads the linked list and ﬁnds out the smallest time stamped packet. It retrieves the smallest time stamped packet and sends the packet on its play out time to its destination (mentioned in the packet header) and removes the link list node that is carrying this packet, so that, next time again the same packet is not found as the smallest packet. Later sub sections of this chapter includes more details of these processes.

Figure 3.3: Low level design of TCNTS

3.2.1 Packet capturing

Capture thread reads the network interface and captures the raw packets coming at that interface. By default network interface card is not in promiscuous mode but if it is turned to promiscuous mode, it captures all the packets coming on the interface whether they are intended for that interface or not. In non promiscuous mode the interface captures only those packets that are intended to that device. After setting the device to promiscuous mode a socket is created and opened and is bind to that interface. Different Protocols and options are there to use to capture specific traffic. Since. we are intended to capture all the traffic so any kind of packet that is coming to the network interface is captured. Here, time when the packet is captured is noted that is later used during the treatment phase.

(26)

3.2.2 Packet treatment

Packet treatment is part of capture process and it contains set of rules that how a packet that is being captured on the NIC should be treated. Figure 3.5 and 3.6 shows data flow diagram of how packets are being treated. Packet treatment phase of TCNTS contains two characteristics that are a time variant behaviour of the shaper and generation of a linear output traffic. These two characteristics together generates a time variant linear output traffic from the shaper. For this purpose, a pattern of values is generated before the program execution. This pattern is based on three things that are the time interval during which a certain type of shaper setting is required, the transition of time after which a certain amount of delay and/or packet loss is added to the packets and the step size by which the amount of delay is changed on each transition.

Before the execution of the shaper, a configuration file is being generated. This configuration file contains diferent shaper settings. Each of these settings has a start time and end time that tells the shaper when to start shaping the packets according to what criteria. This shaper setting is loaded at the start up and when the shaper starts capturing packets using its capture process, it notes down the time of each packet using the Linux ioctl system call, as given below.

ioctl(sd, SIOCGST AM P, &T IM E),

Where ’sd’ is the socket descriptor that carries the socket id. This socket descriptor is used to capture the packets. SIOCGSTAMP returns a struct timeval with the received timestamp of the last packet captured. TIME is a struct timeval that holds the time in seconds and micro seconds.

gettimeof day(CurrentT ime, N U LL),

gettimeofday() function gives the current time in hour, minutes, seconds of the current system clock. If Tmrepresents the current minutes and Tsrepresents the current seconds, then, the which second (Ts′) of the hour can be found as shown in equation 3.1.

T_s′= (Tm× 60) + Ts (3.1)

When second or milli second (in case of small transitions in time) of the hour is found then the predeﬁned shaper setting (delay and/or packet loss) for this second or milli second is retrieved. This amount of delay is then added to the incoming packets. In current design of the shaper, amount of shaping is added with respect to seconds.

To add this amount of delay in milli seconds (∆ms) to the incoming packets, the delay value is first converted to micro seconds (∆usec) as shown in the equa-tion 3.2 and then added to the micro seconds of the time of the captured packet as given in equation 3.3. Later, It is checked that the micro seconds field of the time of the captured packet does not exceed one million. To get it less than one million, the quotient of micro seconds by one million is added to the seconds por-tion of the timestamp and a remainder of one million is taken as micro seconds of the timestamp as shown in equations 3.4- 3.6. Figure 3.5 and 3.6 shows the flow of how the packets are being treated.

(27)

Here, T_s′ is the which second of the hour and ShapedV alue[T_s′] is the prede-fined array value ((∆ms)) that is for the time when the packet is captured and it is added in the micro second portion of the timestamp of the packet as shown in figure 3.7. Each T_s′ is an integer value that is used as an index to the predefined array that contains the values to add in the time stamp of the packets.

Pusec= Pusec+ ∆usec (3.3) If, Pusec>= 1000000 (3.4) Then, Psec= Psec+ Pusec 1000000 (3.5) Pusec= Pusec%1000000 (3.6) In a similar fashion packet loss (Pl) is implemented. If the current time in micro seconds (Tusec) is multiple of ﬁve, as shown in equation 3.7, the packet(s) received at this time are droped by not storing them into the list.

Tusec%5 = 0 (3.7)

Now, the timestamp that was noted during the capture process is seen to find out during which second of the clock hour the packet arrived. After finding out the correct time, the appropriate amount of delay that refers to that second of the clock hour is added to the timestamp and packet is stored in a circular linked list as shown in figure 3.7.

3.2.3 Storing the treated packets using Linked List

Storing the packets using a linked list is also part of capture process. When the packets are treated and a certain amount of delay is added to them, they are stored in a circular linked list. These packets are later retrieved by reading the time stamps.

Since, the memory is shared between two processes, so it is required not to allow both processes to access the same memory at the same time. For this reason, when the capture process reads/writes the same memory, sender process is blocked to use memory locations and when the sender needs to read/write, capture is not allowed to do any operation on it. Figure 2.6 and ﬁgure 2.7 shows this process.

3.2.4 Packet Sending

(28)

(29)

(30)

(31)

(32)

(33)

(34)

(35)

Chapter 4

Implementation and Testing

This chapter includes the implementation and testing phase of the project. Later section of this chapter includes the implementation of the tool and testing of the tool. Black box testing is used to see the entire system functionality and white box testing is used for checking the functionality of the diﬀerent parts of the system seperately.

4.1 Implementation

Implementation phase of TCNTS has some hardware and software requirements under that it works. Later sections of this chapter are comprised of non-functional and functional requirements.

4.1.1 Non-functional requirements

The shaper can operate only in the environment for which it is being developed. There are few hardware nad software requirement that should be fulﬁlled for the shaper to work.

Hardware requirements

Althought the condition to use the tool varies with respect to the traffic arriving to the shaper but the current configuration of the computer is quite enough to deal with two way traffic arriving to the shaper. Currently the tool is implemented on AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ with 1GB memory. There are two NICs installed on the computer to handle two way network traffic. Since the design of the tool is hard coded, so that, this tool can operate on maximum two NICs.

Operating system requirement

(36)

Figure 4.1: System implementation and black box testing

4.1.2 Functional requirements

As functional requirement, the shaper requires to operate on any kind of traffic that is coming to it. Since, the packets are not filtered in this work before being treated, so that, it shapes all type of traffic coming to it. Other than filtering, the shaper is supposed to do a time variant shaping. Traffic that is coming on both the NICs must be shaped. The capture process should capture each packet on coming on the NICs. It should apply shaping (delay and packet loss) with a changed increase or decrease with respect to time. The sender process must send all the packets other than those that come in the packet loss criteria. It should send the packet with original header as the packet is coming from the original source and is not being altered by any intermediate source.

4.2 Testing

This sub chapter includes an empirical investigation that is conducted to find the quality of the TCNTS, with respect to the context in which it is intended to operate. This investigation looks at the objectives of the development of TCNTS, the requirements mentioned in the specification document and the shortfalls in the software. It also includes different test cases to check the functionality of the entire system and the functionality of individual processes and functions to verify that each part of the system works as intended. It also validates and verifies that TCNTS meets the technical requirements that guided its design and development, so that it functions as expected and can provide the same characteristics after implementation.

(37)

4.2.1 Black box testing

In black box testing, specification based testing method is used that aims to test the functionality of the entire system according to the applicable requirements. For testing purpose, to check whether shaper applies delay on the incoming traffic or not, ICMP traffic is used. When ICMP packets passed through the shaper, it added delay to them and when the packets reached at the destination, one-way network delay along with shaper added delay can be seen. Since, shaper applies delay in both directions, so that, when the same packet travels back through the shaper to the source, shaper again applied delay on it. Figure 4.1 shows this process.

If T(p,i) is the time stamp of the packet ’p’ at location ’i’ and T(p,j)is the time

stamp of the packet ’p’ when it reached at location ’j’ If,

T(p,i)= T1,

Then,

T(p,j)= T1+ ∆1+ N etworkDelay (4.1)

And One-way travel time (OWTT) of the packet ’p’ from ’i’ to ’j’ will be as shown in the equation 4.1.

OW T Ti→j= T(p,j)− T(p,i),

≡ T1+ ∆1+ N etworkDelay− T1,

≡ ∆1+ N etwork Delay (4.2)

While,

∆1= ∆usec,

This ∆usec is same as in equation 3.3, that is, the amount of delay that is added to the packet.

And,

∆usec≈ ∆1+ N etwork Delay (4.3)

For the back travel from ’j’ to ’i’, in case of ICMP packet, the OWTT will be as in equation 4.2

OW T T(j_→i)= T(p,i)− T(p,j)≡ ∆2+ N etwork Delay (4.4)

And, the total time the packet took to come back to its source will become as shown in equation 4.3

T otaltraveltime = OW T T(i→j)+ OW T T(j→i),

≡ ∆1+ ∆2+ N etwork Delay (4.5)

If these equations are transformed in terms of the added delay to the packet and If T1 is the timestamp when the packet is captured, then, the amount of

(38)

One− way delay(i→j)= T1′= (T1+ ∆1+ N etwork Delay)− T1 (4.6)

Or,

One− way delay(i→j)= T1′= (∆1+ N etwork Delay) (4.7)

While, for the back travel of the packet passing through the shaper, it becomes the sum of the shaper added delay (’j’ to ’i’) and the delay present in the network. Equation can be written as,

One− way delay(j_→i)= T2′= (T1′+ ∆2+ N etwork Delay)− T1′ (4.8)

Or,

One− way delay(ji)= T2′= (∆2+ N etwork Delay) (4.9)

And, the total amount of delay added to the ICMP packet becomes the sum of shaper added delay to the request (’i’ to ’j’) and shaper added delay to the response(’j’ to ’i’) and network delay.

DelayT otal= T1′+ T2′ (4.10)

Or,

DelayT otal= (∆1+ ∆2+ N etwork Delay) (4.11)

Or, DelayT otal = 2 ∑ i=1 ∆i+ N etwork Delay) (4.12)

4.2.2 White box testing

White box testing is comprised of several test cases that tests each part of the tool seperately and verifies and validates the functionality of these part. Since the whole system is comprised of different sub processes, so that, separate testing of each part of TCNTS validates that the specific part is functioning properly.

Test cases

(39)

Table 4.1: Storing the captured packets Test Case 1

Test case id 1

Unit to test Circular Linked list

Assumptions Does system implement a circular linked list Test data ﬂow of the list

Steps to be executed 1- List creation

2- predeﬁned memory allocation 3- writing to the list

4-reading from the list

Expected result Successful writing and reading to the list Actual result The ﬂow of the list is correct and the list store

each incoming packet. Pass/Fail Pass

Comments Although the ﬂow of the list is correct and it stores each incoming packet to the shaper but it, sometimes, drop packet due to improper synchronization of the processes that are ac-cessing the list at the same time.

Test Case 1

In this test case, temporarily storage of the packets is tested. Linked list is imple-mented for this purpose. A circular list is impleimple-mented. Packets are temporarily stored for a small amount of time and are released when their play out time reaches.This memory is shared between two processes. Both of these processes needs to be sychronized such that memory is not being violated and both the processes perform their job on the memory. Table 5.1 contains the steps executed and the problems faced.

Test Case 2

For testing purpose, a shaper setting is generated for an hour time and the shaper setting resets itself on each clock hour. A transition period of one second is taken such that the shaper trasits to a new state after each second. This way, 3600 values of delay are pre generated for an hour. Step size taken to change the delay value on each trasition is one milli second, so that, shaper adds one milli second delay after each second until it reaches 3600th value. A remainder by 1000 of each delay value is taken, such that the imposed delay value does not exceed 1 second So, the maximum amount of delay applied on the packet is one second. Although, processing time is also present but it is not removed from the shaped value. Such that, the shaped graph now is sum of both imposed delay and processing delay. After reaching to the last delay value that is 3600th_{value, the} shaper ﬁnds that the next clock hour has been started and it resets its counter. In a similar fashion packet loss is applied. Every ﬁfth packet is dropped by not storing and sending.

(40)

Shaper[] is a predeﬁned integer array that contains amount of delays DELAY AND TIME are timeval structures

i = 1 to 3600 Shaper[i]← i

ioctl(sd,SIOCGSTAMP,TIME);

Where, sd is the socket descriptor and TIME carries the current time at which the packet is captured.

gettimeof day(CurrentT ime, N U LL)

W hichSecondOf Hour = (M inutes∗ 60) + Seconds

DELAYmicrosec= 1000× Shaper[W hichSecondOfHour]%1000

CurrentP acketmicrosec= CurrentP acketmicrosec+DELAYmicrousec

CurrentP acketmicrosec≥ 10000000

CurrentP acketsec+ = CurrentP acketmicrosec/10000000

CurrentP acketmicrosec= CurrentP acketmicrosec%10000000

Test Case 3

To implement a packet loss capability of the shaper, the tool handle the packets in a way that it drops every packet that is coming at each ﬁfth micro second of the current system clock time.

Test Case 4

Time variant shaping behaviour of the system is tested in this test case. Table 4.4 shows the expected and actual results. It also contains the steps that are followed to gain a time variant behaviour of the shaper. Since delay and packet loss is implemented by the shaper, the shaper applies a varying amount of delay on each incoming packet and drops all packets that are coming during every ﬁfth micro second. Since ﬁltering is not included in this work, so that the rules are applied on each type of packet captured by the shaper.

Test Case 5

(41)

Table 4.2: Applying Delay Test Case 2 Test case id 2

Unit to test Linearly increasing amount of delay Assumptions Does system implement delay? Test data Network traﬃc

Steps to be executed 1- Get the Time stamp of the packet

2- Take appropriate delay value from a prede-ﬁned array

3- convert it to microsecond, check if the mi-croseconds are less than one million

4- if greater or equal to one million than divide the micro seconds with one million and add to second portion of the time stamp and add the remainder portion in the micro second portion of the time stamp

Expected result Proper delay value to be added in the time stamp

Actual result The test code adds delay to the time stamp of the packets as required. Since, the test code adds maximum of 999 ms delay to the incom-ing packets, so that, amount of delay between 0 ms to 999 ms plus one-way delay in network can be observed on the output traﬃc.

(42)

Table 4.3: Apply Packet Loss Test Case 3

Test case id 3

Unit to test Packet loss

Assumptions Does system implement packet loss Test data Network traﬃc

Steps to be executed 1- Read the current system clock

2- Check If the current micro seconds are mul-tiple of 5

3- If True, then, Don’t store the packets in the linked list that are coming at this time 4- Otherwise, Store the packets in the list for the sender process to send them at their play out times

Expected result Drop every packet that is coming at the time (in micro seconds) multiple of 5

Actual result Send operation is not done on every ﬁfth packet

Pass/Fail Pass Comments

Test Case 6

(43)

Table 4.4: Time variant shaping Test Case 4

Test case id 4

Unit to test Delay and Packet Loss

Assumptions Linear increase/decrease in delay and packet loss.

Test data ICMP traﬃc

Steps to be executed 1- Load shaper setting in an array from a pre generated conﬁguration ﬁle containing values equal to seconds in one clock hour

2- Read the packet

3- Get the time at which packet is captured 4- Get current system clock hour (convert it to which second of hour)

5- Take out an appropriate value from the ar-ray that refers to this second of the hour 6- Make it millisecond and add in the micro seconds portion of the packet captured time 7- Continuously read the buﬀer for smallest time stamp

8- Get the smallest time stamp packet 9- If this packet time stamp is greater than the currrent system clock and the packet ID is not multiple of 5, then, send the packet Expected result Shaper must have a time variant behaviour

and it must apply a changed amount of de-lay and packet loss on incoming traﬃc with respect to time.

Actual result Shaper works ﬁne till a certain period but starts dropping packets after some time. Till the time, the shaper is working ﬁne, it is hav-ing a time variant behaviour

Pass/Fail Pass

(44)

Table 4.5: Generating conﬁguration ﬁles Test Case 5

Test case id 5

Unit to test Are the conﬁguration ﬁles created with desired pattern?

Assumptions A ﬁle is generated following the desired pat-tern

Test data

Steps to be executed 1- Static or Dynamic pattern

2- Transition on seconds or milli seconds 3- Enter the start value

4- Enter the step size

Expected result A ﬁle should be generated containing stati-cally generated a pattern of values or dynam-ically generated set of random values

Actual result The code works ﬁne and generates a ﬁle of the desired pattern

Pass/Fail Pass

(45)

Table 4.6: Reading and loading the conﬁguration ﬁles Test Case 6

Test case id 6

Unit to test Does the system loads the required file? Assumptions A configuration file of desired pattern of values

is loaded in an array Test data

Steps to be executed 1- Static or Dynamic pattern

2- Transition on seconds or milli seconds 3- Open the ﬁle

4- Read the ﬁle line by line

Load each line that is containing an integer value into an array

Expected result All the values contained in the conﬁguration ﬁle has loaded into an array

Actual result The code reads and loads the desired ﬁle Pass/Fail Pass

(46)

(47)

Chapter 5

Results

This chapter dicusses the results obtained from the shaper. It shows that the shaper applies delay on the incoming traffic, regardless of its direction. Since, the shaper is working between two interfaces, so that, the traffic coming on eth0 is transmitted through eth1 and vice versa. Before, transmitting in either direction, the shaper applies delay on it. The graphs in figure 5.2-5.5 show this behaviour of the shaper. The graphs show that the delay values applied by the shaper, adding network delay and the processing time of the code, are increasing as the shaper applies different amount of delay on each new packet. This amount of delay is increasing till 1000 ms and then it resets to 0 ms. Although, the current output from the shaper is not purely linear in nature because the transitions are made on seconds. It can be observed from the current output that if these transitions are done on milli seconds or on micro seconds, the shaper might generate a linear output traffic. That is, the shaper adds delay on packets by seeing that at what milli second or micro second of the second, the packet is being captured. For example, if there are 1000 ms in a second and on each milli second an increasing amount of delay is added to the incoming packets by the shaper. This may also be seen more close to linear, if the increasing amount of delay is reduced from 1 ms to more small value. The current implementation of the shaper is giving more a like step increase in the output traffic, that is, stepping of one second with a change of 1 ms of delay.

Figure 5.1: Experiment setup to test the shaper

(48)

than the shaped amount can be observed.

The graphs in figure 5.2 - 5.5 are drawn between the packet number or the sequence number and the packet travel time (in milli seconds). Here the packet travel time is the time a packet is taking from source to destination and then back to source. The graphs in figure 5.3 and 5.6 are drwan between time (in seconds) and packet travel time (in milli seconds). While the graphs in figure 5.4 and 5.7 are drawn between time (in epoch seconds) and packet travel time (in milli seconds). Packet travel time can also be interpreted as the amount of delay that is added by shaper on the packet when it travelled from source to destination and passed through shaper and when it travelled from destination to source and again passed through shaper. It can be said that the total amount of time taken by the packet to reach back to the source or the total amount of delay added to the packet by shaper plus the network delay are same.

To minimize the time values, a diffrence of first time stamp from each time stamp is considered in figure 5.3 and 5.5. It gives a zoomed view of the graphs that are drawn for the epoch seconds and packet travel time. Graphs in figure 5.4 and figure 5.7 are drawn between current system clock that is in epoch seconds and the total travel time of a packet that is in milli seconds. From the graphs in figure 5.2 and 5.5 that are between packet number and packet travel time and the graphs in figure 5.3 and 5.6 that are between seconds and packet travel time, it can be observed that the output is similar. It shows that the delay added to the packets with respect to time is increasing and for all packets that are coming in the same second of the clock are applied same amount of delay.

(49)

Figure 5.4: Experiment 1: Current system clock (epoch seconds) and Total travel time of the packets

(50)

Figure 5.6: Experiment 2: Time in seconds and Total travel time of the packets

(51)

Chapter 6

Conclusions and Future

Work

This chapter concludes the overall proposed design on the basis of the results obtained. It also includes the future work for the researchers who intend to work in the same ﬁeld and are investigating on the behaviour of real-time applications and data.

6.1 Conclusion

The graphs in figures 5.2 - 5.7 in reuslts represent that the output traffic from the shaper is somewhat linear. Although these graphs does not show the full hour statistics but a linear pattern can be observed for an hour time (in case of test code). These graphs are drawn for about five to ten minutes data. This linear traffic continues until the shaper setting remains valid. Shaper setting can be set according to the need. It can be set for minutes, hours or days. Shaper setting that is being generated for the current design is having one hour duration. At each new hour, shaper resets the setting. During this time period, it applies an increasing amount of delay on incoming traffic. The delay graph shows that the output traffic from the shaper is increasing with respect to time. Unlike, previously discussed shapers, TCNTS applies a different amount of delay on each incoming packet depending on what configuration (one-way delay and packet loss) to treat packets is being used at the start up. Since, shaper is applying one-way delay and packet loss on traffic in both directions. So, while testing applications that requires acknowledgement of the packets would be observing the imposed delay and packet loss in both the directions. If the shaper is used to test a client/server application, then, it is required by the tester whether to apply shaping in both directions (from server to client and vice versa) or in one direction (to/from the server or to/from the client). Shaper applies packet loss on the incoming packets that are coming at every fifth micro second of second. It drops those packets that are coming during this time by not storing them to the memory.

(52)

a certain threshold. Since, these buffers are already a solution to convert the delay variation into delay by queueing the packets temporarily. If the incoming traffic to these applications is handled lineary, then, the problem of jitter buffer overflow may reduce to some extent. Each time when a new packet will come to the shaper, an increased amount of delay will be applied on it and in a sim-ilar fashion, the packet will be released by the shaper. So, when the packet or bunch of packets that belongs to some real-time multimedia application traffic (game traffic, video/audio stream) is handled by that application (either client or server), the chances of getting jitter buffer underflow or overflow may reduce. In this way, the maximum capability of the jitter buffer will be tested by seeing that at what level of degradation, (small/big amount of delay/packet loss varying with small/big amount of transition time), the jitter buffer gets overflow or underflow. After getting the exact measurements, the problem can be removed and applica-tion can be pushed back to internet and the performance of the applicaapplica-tion can be upgraded to some extent.

It’s matter of what conﬁguration is used by the shaper to provide a linear output to the real-time application. If the shaper setting is set for very small amount of time (10th _{or 100}th_{of second) and very small step sizes in delay are} used, then, also the same traﬃc as input to the real-time application will be handled in a quite better way.

6.2 Future work

(53)

Bibliography

[1] Traﬃc shaping, http://en.wikipedia.org/wiki/Traﬃcshaping, Accessed on June 15, 2009

[2] One-way delay, RFC 2679, ftp://ftp.rfc-editor.org/in-notes/rfc2679.txt, Ac-cessed on June 15, 2009

[3] One-way delay, http://kb.pert.geant.net/PERTKB/OneWayDelay, Ac-cessed on June 15, 2009

[4] Round trip time, http://kb.pert.geant.net/PERTKB/RoundTripTime, Ac-cessed on June 15, 2009

[5] Round trip time, RFC 3393, ftp://ftp.rfc-editor.org/in-notes/rfc3393.txt, Accessed on June 15, 2009

[6] Delay Variation, http://kb.pert.geant.net/PERTKB/DelayVariation, Ac-cessed on June 15, 2009

[7] Packet loss, http://kb.pert.geant.net/PERTKB/PacketLoss, Accessed on June 15, 2009

[8] Packet loss, RFC 2680, ftp://ftp.rfc-editor.org/in-notes/rfc2680.txt, Ac-cessed on June 15, 2009

[9] Packet loss, RFC 3357, ftp://ftp.rfc-editor.org/in-notes/rfc3357.txt, Ac-cessed on June 15, 2009

[10] Packet reordering, http://kb.pert.geant.net/PERTKB/PacketReordering, Accessed on June 15, 2009

[11] Maximum transmission unit (MTU),

http://kb.pert.geant.net/PERTKB/MaximumTransmissionUnit, Accessed on June 15, 2009

[12] Asynchronous transfer mode (ATM), RFC 791, http://www.faqs.org/rfcs/rfc791.html, Accessed on June 15, 2009

[13] Asynchronous transfer mode (ATM),

http://www.networksorcery.com/enp/protocol/atm.htm, Accessed on June 15, 2009

(54)

[15] Transmission control protocol (TCP), RFC 793, http://www.faqs.org/rfcs/rfc793.html, Accessed on June 15, 2009

[16] Fiber distributed data interface (FDDI), http://en.wikipedia.org/wiki/FDDI, Accessed on June 15, 2009

[17] Voice over IP (VoIP), http://en.wikipedia.org/wiki/VoIP, Accessed on June 15, 2009

[18] Real-time transport protocol (RTP), RFC 1889, http://www.ietf.org/rfc/rfc1889.txt, Accessed on June 15, 2009

[19] Network Emulation with Netem. Author:Stephen Hemminger, Open Source Development Lab., Accessed on January 15, 2009

[20] NetEm, http://www.linuxfoundation.org/en/Net:Netem, Accessed on De-cember 15, 2009

[21] NIST Net- A Linux-based Network Emulation Tool. Author: Mark Carson, Darrin Santay, National Institute of Standards and Technology

[22] NistNet, http://snad.ncsl.nist.gov/nistnet/, Accessed on December 15, 2009 [23] DummyNet, http://info.iet.unipi.it/ luigi/ip-dummynet/ Accessed on

De-cember 15, 2009

[24] Kaunet, http://sourceforge.net/projects/kaunet, Accessed on June 15, 2009 [25] Thesis Report on Network Emulation,Pattern based traﬃc shaping and KauNET Evaluation. Author: Abdul Azim, Zafar Iqbal Awan, Blekinge In-stitute of Technology.

[26] User datagram protocol (UDP), RFC 768, http://www.faqs.org/rfcs/rfc768.html, Accessed on June 15, 2009

(55)

Appendix A

Code

A.1 Code to generate conﬁguration ﬁle

This code is to generate the configuration files. It includes four options that are to generate a configuration file of static values or a dynamic file with random values. Both of these configurations include values to operate on seconds or milliseconds. #include"stdio.h" #include"stdlib.h" #include"time.h" void main(void) { FILE *file;

int start, step, count, transition,choice, choice1,value; time_t seconds;

printf("n\n GENERATE CONFIGURATION FILE \n\n");

printf("What time of configuration file do you want to generate \n\n"); printf("Enter 1- Static, 2- Random \n\n");

scanf("%d",&choice1); switch(choice1)

{ case 1:

printf("Do you want tranistion on seconds or milli seconds \n"); printf("Enter 1- seconds, 2- milli seconds \n");

scanf("%d",&choice);

printf("Enter the start value\n"); scanf("%d",&start);

(56)

switch(choice) {

case 1:

printf("THE CONFIGURATION FILE CONTAINS 3600 VALUES \n"); value=start; count=0; file = fopen("s_static.config","w"); while(count<3600) { //printf("%d,",count); fprintf(file,"%d\n",value); // fprintf(file,"\n");/*writes*/ value+=step; count++; } fclose(file); /*done!*/ break; case 2:

printf("THE CONFIGURATION FILE CONTAINS 3600000 VALUES \n"); value=start; count=0; file = fopen("ms_static.config","w"); while(count<3600000) { //printf("%d,",count); fprintf(file,"%d\n",value); /*writes*/ value+=step; count++; } fclose(file); /*done!*/ break; } break; case 2:

printf("Do you want tranistion on seconds or milli seconds \n"); printf("Enter 1- seconds, 2- milli seconds \n");

switch(choice) {

case 1:

printf("THE CONFIGURATION FILE CONTAINS 3600 VALUES \n");

(57)

file = fopen("s_dynamic.config","w"); while(count<3600)

{

int RAND_MAX1 =count*3600;

int j = 1 + (int)( rand() / ( RAND_MAX1 + 1.0 ) ); // printf("%d,",j); fprintf(file,"%d\n",j); /*writes*/ count++; } fclose(file); /*done!*/ break; case 2:

printf("THE CONFIGURATION FILE CONTAINS 3600000 VALUES \n"); count=0;

file = fopen("ms_dynamic.config","w"); while(count<3600000)

{

int RAND_MAX2 =count*3600000;

int j = 1 + (int)(rand() / ( RAND_MAX2 + 1.0 ) ); // printf("%d,", j); fprintf(file,"%d\n",j); /*writes*/ count++; } fclose(file); /*done!*/ break; } break; } }

A.2 Code to read and load conﬁguration ﬁle

This code is to read one of the configuration files and loads all the values in an array. Later shaper uses this pattern of values in shaping the incoming traffic to the shaper.

(58)

int main ( void )

{

int choice, choice1,choice2;

double *Shaper2; Shaper2 = malloc(sizeof(*Shaper2) * 3600000); double *Shaper3; Shaper3=malloc(sizeof(*Shaper3)*3600); int Shaper[3600]; int b;

static const char filename1[] = "s_static.config"; static const char filename2[] = "ms_static.config"; static const char filename3[] = "s_dynamic.config"; static const char filename4[] = "ms_dynamic.config";

FILE *file1,*file2,*file3,*file4;

char line [ 100 ]; /* or other suitable maximum line size */ int c1,c3;

int c2,c4; c1=c2=c3=c4=1;

printf("Generate the configuration file \n\n"); printf("Enter 1- Static, 2- Random \n\n");

switch(choice) {

case 1:

printf("Enter 1- transition in seconds, 2- transition in millisecond \n\n"); scanf("%d",&choice1);

switch(choice1) {

case 1:

file1 = fopen ( filename1, "r" ); if ( file1 != NULL )

{

while ( fgets ( line, sizeof line, file1 ) != NULL ) /* read a line */ {

Shaper[c1]=atoi(line); c1++;

(59)

} int i; for(i=0;i<3600;i++) { printf(">>>>>>>%d\n",Shaper[i]); } fclose ( file1 ); } else {

perror ( filename1 ); /* why didn’t the file open? */ }

break;

case 2:

{

Shaper2[c2]=atof(line); c2++;

// if(sizeof(c2)>=sizeof(int)){ c2=0;}

// fputs ( line, stdout ); /* write the line */ }

// free(Shaper2);

int i;

for(i=0;i<3600000;i++) {

printf(">>>>>>>%d value is %f\n",i,Shaper2[i]); }

fclose ( file2 ); }

else {

break;

}

break;

case 2:

printf("This is to get the configuration file that contains random number \n\n\n\n"); printf("Enter 1- transition on seconds, 2- transition on milliseconds\n\n");

(60)

switch(choice2) {

case 1:

{

// free(Shaper2);

int i;

for(i=0;i<3600000;i++) {

fclose ( file4 ); }

else {

break; case 2:

{

// free(Shaper2);

int i;

for(i=0;i<3600000;i++) {

fclose ( file2 ); }

(61)

perror ( filename2 ); /* why didn’t the file open? */ } break; } break; } return 0; }

A.3 Design code

This appendix is comprised of the whole code that is the design of the shaper.

(62)

union semun{ int val;

struct semid_ds *buf; ushort *array; }; struct captureProcess { int sd; char* nic; long pktCnt; int semaphore; pthread_mutex_t *lockit; };

typedef struct captureProcess capProcess;

struct senderProcess { // int nics; int Fd; char *nic; int semaphore; pthread_mutex_t *lockit; };

typedef struct senderProcess sendProcess;

struct CaptureBuffer { int pkt_id; unsigned char pkt[4092]; int pkt_len; int pkt_count; struct timeval ts;

struct CaptureBuffer *next; struct CaptureBuffer *prev; int wPos;

int rPos; int wFlag; int rFlag; };

(63)

struct CaptureBuffer *node;

struct CaptureBuffer *node1;//(struct mystruct *)malloc(sizeof(struct mystruct)); struct CaptureBuffer *tmp1;//(struct mystruct *)malloc(sizeof(struct mystruct)); struct CaptureBuffer *emptylist;

struct CaptureBuffer *pktlist; struct CaptureBuffer *senderlist;

struct CaptureBuffer *ehead,*ecurr,*enode,*etail,*phead,*pcurr,*scurr,*shead; struct CaptureBuffer *snode;

struct CaptureBuffer *pnode;

struct CaptureBuffer *ne,*n1,*n2,*n3,*n4; struct CaptureBuffer *TMPCB,*TMPNode; struct CaptureBuffer *first;

//Pcurr = NULL; //snode=NULL; struct CaptureBuffer2 { int pkt_id; unsigned char pkt[4092]; int pkt_len; int pkt_count; struct timeval ts;

struct CaptureBuffer2 *next; struct CaptureBuffer2 *prev; int wPos;

int rPos; int wFlag; int rFlag; };

//ruct mystruct *node=malloc(100000 *(sizeof(struct mystruct ))) ; //struct mystruct *node1, *tmp1;

struct CaptureBuffer2 *node2;

struct CaptureBuffer2 *node12;//(struct mystruct *)malloc(sizeof(struct mystruct)); struct CaptureBuffer2 *tmp12;//(struct mystruct *)malloc(sizeof(struct mystruct)); struct CaptureBuffer2 *emptylist2;

struct CaptureBuffer2 *pktlist2; struct CaptureBuffer2 *senderlist2;

struct CaptureBuffer2 *ehead2,*ecurr2,*enode2,*etail2,*phead2,*pcurr2,*scurr2,*shead2; struct CaptureBuffer2 *snode2;

struct CaptureBuffer2 *pnode2;

struct CaptureBuffer2 *me,*m1,*m2,*m3,*m4; struct CaptureBuffer2 *TMPCB2,TMPNode2;

(64)

capProcess myCap; sendProcess mySend; capProcess myCap2; sendProcess mySend2; //int sd; //int send_sd=-1; char *nic;

unsigned char packet_buffer_if1[2048];

unsigned char *pkt;//=(unsigned char *)malloc(sizeof(unsigned char *)); int rPos;

int wPos;

unsigned char packet_buffer_if2[2048]; //unsigned char *pkt2;

int rPos2; int wPos2;

//unsigned char packet_buffer_if2[2048]; //unsigned char *packet_buffer_if1;

pthread_t cap1; pthread_t sendPID;

pthread_t cap2; pthread_t sendPID2;

struct sockaddr_ll destAddr;

struct sockaddr_ll destAddr2;

void* capture(void*); void* sender(void*);

void* capture1(void*); void* sender1(void*);

Time Controlled Network Traﬃc Shaper