Bi-Weekly Updates

Part 1 (February 21)

Find and Research Related Papers

For the comparison between UDP and TCP, the following paper utilizes NS2, a network simulation tool. It evaluates the performance of both protocols in two scenarios:

1. Changing the speed while keeping the data size constant.
   
   

2. Changing the data size while keeping the speed constant.
   
   

Reference:

[1] F. T. Al-Dhief et al., “Performance Comparison between TCP and UDP Protocols in Different Simulation Scenarios,” International Journal of Engineering & Technology, vol. 7, no. 4.36, pp. 172–176, 2018. [Online]. Available: https://www.sciencepubco.com/index.php/ijet/article/view/23739

Determine Which Network Emulator to Adopt

Currently considering NS3 or Mininet for future simulations. The final choice may depend on upcoming changes in test scenarios or requirements.

Adapt Project into a Monitorable Client/Server Facilitator

The project will evolve toward using a tool to monitor and analyze real-time TCP and UDP communication behavior. However, since the concrete implementation plan is not finalized, this task will be discussed and scheduled for next week.

Part 2 (March 7)

Research Focus and Methodology Update

Over the past two weeks, we have refined our research direction to ensure consistent and measurable comparisons between the TCP and UDP protocols. To this end, we have identified the following key performance metrics:

• Throughput – Measures how fast a file can be transferred between peers.
  
  

• Packet Loss – Tracks the number of packets lost during transmission.
  
  

• Average Latency – Measures the round-trip time from one peer to another.
  
  

• Efficiency – Assesses how effectively each protocol utilizes available network resources, with a focus on TCP’s overhead and reliability features versus UDP’s simplicity.
  
  

Test Scenarios and Environments

For the real network scenario, we have chosen to use a typical Wi-Fi network (e.g., home or campus Wi-Fi) to represent practical, everyday usage conditions.

In parallel, we have established an emulated network environment using GNS3 to allow controlled and repeatable experiments under various simulated conditions. We will conduct tests in the following environments:

• Perfect Network – No packet loss; stable and consistent conditions.
  
  

• Dense Network – High traffic and congestion to simulate network saturation.
  
  

• Unstable Network – Introduces random packet drops and latency spikes.
  
  

• Real Network – Deployed on physical hardware to capture real-world behavior.
  
  

System Development

We have also begun designing a monitorable peer-to-peer (P2P) facilitator, which will be developed using Python and Flask. This tool will enable real-time observation and analysis of communication patterns and performance between peers.

Part 3 (March 21)

Progress Update

1. Emulation and Data Collection

We planned to run tests in the GNS3-emulated environments (Perfect, Dense, Unstable, and Real Network scenarios) to collect performance data for both TCP and UDP.

Status: It is taking a while to build the environment. Cannot find instructions on how to set up the latest GNS-3. Data collection will begin once the environment is fully operational.

2. GNS3 Topology Setup

We agreed that the simulation is designed to approach the experimental topology of the real-world experiment

Status: Setup incomplete. Work is ongoing, with the goal of having a functional setup by the next update.

3. Real-World Experiment (Server/Client Setup)

For the real-world test, we plan to use one server and eight client devices (including laptops, smartphones, and iPads). A basic Python proof-of-concept has been developed for server-client communication.

Status: Preliminary phase. Further development is required to support the full-scale experiment.

Challenges

• Technical Difficulties: GNS3 configuration issues have slowed progress on the emulation setup.
  
  

• Time Constraints: Limited time has delayed work on the P2P facilitator and expansion of the server-client communication system.
  
  

Next Steps

Short-Term (Next Week)

• Finalize the GNS3 topology setup.
  
  

• Complete initial implementation of the P2P facilitator.
  
  

Mid-Term (Next Two Weeks)

• Run emulations across all planned test scenarios.
  
  

• Collect data on throughput, packet loss, latency, and efficiency.
  
  

• Expand the Python server-client code to support the full eight-device real-world test.
  
  

Ongoing

• Continue troubleshooting technical issues.
  
  

• Allocate additional time and resources to ensure steady and timely progress.

Part 4 (April 4)

Progress Update

• Developed Server and Client Code

We have written and implemented the server-side and client-side programs:

• server.py:
  
  Contains a ServerConnection class that:

  • Initializes protocol settings, socket, and address/port details

  • Handles data reception.

  • Manages connection states (e.g., WAITING, COLLECTING).

• The main function supports both TCP and UDP protocols, establishes connections, and includes timeout handling for inactive sessions.
  
  

• client.py:
  Implements the client-side logic to connect to the server using the selected protocol and send data accordingly.

This implementation serves as the foundation for our controlled experiments and real-world testing.

2. Environment setup on Windows

We attempted to download VMware and run GNS3. However, due to the limited performance of the machine, installing and launching virtual machines takes a long time. Frequent issues occur, often requiring us to shut down the machine entirely to recover.

Due to these issues, our data collection has been significantly delayed. We have decided to further explore alternative ways to set up the simulation environment.

Part 5 (April 18)

Progress Update

Real-world experiment: Although the initial plan involved eight devices, only four were used in the end, as iPad and iPhone Apps did not support command-line input.

Setup:

• Client/Server (C/S): The server was started and its IP address, port number, and a list of available files were shared. Coordination ensured that no file was requested more than once. Each participant used client.py to connect to the server and retrieve their assigned file.

• Peer-to-Peer (P2P): A peer network was manually configured. Files were distributed across the network, and a number of peers (4) were tasked with retrieving the files.

In both cases, log files were generated to capture connection statistics—multiple logs in the case of the P2P setup. 

Test Result: File transfers were successfully completed in both the C/S and P2P setups. However, data collection and compilation were not completed as intended.

Simulations: 

• The setup on Windows has been completed. However, the system is extremely slow—just connecting to the VM and executing commands is about the limit of what it can handle. Verifying ping responses across all topologies takes over an hour as well as sudden unknown error appeared.

• All available methods for using GNS3 on macOS have been tried, but none were successful. So, decided to try alternative approaches for running the simulation.

Since it was not possible to run simulations using virtual machines on GNS3 with the ARM version of the VM on macOS, the simulator was switched to ns-3.

 And Wi-Fi-based peer-to-peer network topology was constructed. A simulation was implemented using either TCP or UDP to perform file transfers, and export performance metrics—throughput, latency, jitter, and packet loss—to a CSV file.

The data collected through GNS3 was analyzed using Wireshark, but the analysis took much longer than anticipated due to the computational load.

In the real-world experiment, the code was adjusted to ensure valid test results. The retest was conducted in a local environment where all devices were connected to the same network.