# Lab 4
[TOC]

## Complete the tasks of [Lab 1](https://hackmd.io/@AlinaYezhkova/SkBrgV6xC/edit), using the methods of the WEBSocket protocol.
1. Create a client-server application in javascript using the HTTP protocol that tests the total request to server and back (RTT) travel time with the calculation of **minimum, maximum, median and average RTT, standard deviation and skewness ratio** for client-to-server request frequencies 16Hz, 8Hz, 4Hz, 2Hz, 1Hz, and for client request sizes 128, 256, 512, 1024, 2048 bytes.
Present the results in the form of tables
2. Test the operation of your client-server application on a personal area network (PAN) and on a wide area network (WAN on replit.com hosting).
3. Estimate the distance to the server and the characteristics of the client-server channel that can be obtained from this data
4. Compare the obtained data with the data of the system network utility ping.
## General information

### WebSocket Protocol

WebSocket is a communication protocol that provides full-duplex communication channels over a single, persistent TCP connection. It enables real-time, bidirectional communication between clients and servers, allowing for efficient data exchange without the overhead of traditional HTTP connections.

#### Key Features:

- **Full-Duplex Communication**: WebSocket allows both the client and server to send and receive messages simultaneously, enabling real-time interaction.
- **Persistent Connection**: Unlike HTTP, which follows a request-response model where each request initiates a new connection, WebSocket maintains a persistent connection between the client and server, reducing latency and overhead.
- **Efficient**: WebSocket headers are smaller compared to HTTP, resulting in reduced overhead and improved performance, especially for applications requiring frequent data exchange.
- **Low Latency**: With its persistent connection and minimal overhead, WebSocket facilitates low-latency communication, making it suitable for interactive applications such as online gaming, chat applications, and financial trading platforms.

#### Usage:

- **Web Applications**: WebSocket is commonly used in web applications that require real-time data updates, such as live chat, collaborative editing, and online gaming.
- **APIs and Services**: WebSocket can be utilized in APIs and services to enable real-time notifications, data synchronization, and event-driven architectures.

#### Implementation:

- **Client-Side**: Most modern web browsers support WebSocket through JavaScript APIs, allowing developers to establish WebSocket connections from client-side scripts.
- **Server-Side**: Various server-side frameworks and libraries provide WebSocket support, enabling developers to implement WebSocket servers in languages such as Node.js, Python, Java, and Ruby.

#### Security:

- **Encryption**: WebSocket connections can be secured using Transport Layer Security (TLS) to encrypt data transmitted between the client and server, ensuring confidentiality and integrity.
- **Authentication**: WebSocket connections can be authenticated using various mechanisms, such as API keys, tokens, or session cookies, to verify the identity of clients and enforce access control policies.

WebSocket offers a versatile and efficient solution for real-time communication between clients and servers, facilitating the development of interactive and responsive web applications.

### Socket.IO
Socket.IO is a JavaScript library for real-time web applications. It enables real-time, bidirectional and event-based communication between web clients and servers. It consists of two parts: a client-side library that runs in the browser and a server-side library for Node.js.

The Socket.IO connection can be established with different low-level transports:

- HTTP long-polling
- WebSocket
- WebTransport

Socket.IO will automatically pick the best available option, depending on the capabilities of the browser and the network.

Socket.IO is NOT a WebSocket implementation. Although Socket.IO indeed uses WebSocket for transport when possible, it adds additional metadata to each packet. That is why a WebSocket client will not be able to successfully connect to a Socket.IO server, and a Socket.IO client will not be able to connect to a plain WebSocket server either.

### Comparison of WebSocket and Socket.IO

#### Advantages of Socket.IO
- Unlike raw WebSockets, Socket.IO allows broadcasting messages to all connected clients. For example, in a chat application, if you want to notify all users about a new user joining, you can easily accomplish this with a single operation. With raw WebSockets, you would need to maintain a list of connected clients and send messages individually.
- Using proxies and load balancers with raw WebSockets can be challenging. Socket.IO supports [proxying](https://socket.io/docs/v3/reverse-proxy/) and [load balancing](https://socket.io/docs/v4/using-multiple-nodes/) out of the box.
- Socket.IO supports graceful degradation of channel functionality in case of uncontrolled network state changes.
- Socket.IO automatically reconnects when the connection is lost.
- Socket.IO library allows writing shorter code.

#### Advantages of WebSocket

- WebSocket is a standard modern internet protocol, and its API is supported by all modern browsers.
- Shorter network traffic during connection establishment phase.

## Code
[**Full code on replit**](https://replit.com/@AlinaYezhkova/csn-4)

### File: server.js

io.on('connection', socket => {
  console.log('A user connected');

   socket.on('measureRTT', (data, clientCounter) => {
     console.log('Received measureRTT data with clientCounter=', clientCounter);
      const socketName = 'RTTMeasured' + clientCounter;
       socket.emit(socketName, data, clientCounter);
  });

   socket.on('disconnect', () => {
    console.log('User disconnected');
  });
});

This code sets up a real-time communication system using Socket.IO in a Node.js application. It listens for connections from clients and logs when users connect or disconnect. When a client sends a message with the event name 'measureRTT', the server logs the received data and sends a confirmation message back to the client with the same data.

### File: script.js

function requestToServer(requestSize) {
  const localCounter = counter;
   counter++;
   const data = generateData(requestSize);
   const socketName = 'RTTMeasured' + localCounter;
    const startTime = Date.now();

     socket.on(socketName, (responseData, recievedCounter) => {
      const rtt = Date.now() - startTime;
       console.log("OFF! Current amount of requests:", currentAmountOfRequests,
      "lc=", localCounter,
      "rc=", recievedCounter)
       socket.off(socketName);
        console.log('Response time:', rtt, 'ms');

        const sizeInBytes = responseData.length;
         console.log('Response size:', sizeInBytes, 'bytes');
          calculateMetrics(rtt);
  });
    
      console.log("ON! Current amount of requests:", currentAmountOfRequests)
       socket.emit('measureRTT', data, localCounter);
        console.log("Request sent!", currentAmountOfRequests);
}

This client-side code defines a function `requestToServer(requestSize)` that sends a message to the server to measure round-trip time (RTT) with the specified request size. It generates data based on the provided request size, records the start time, and sends the data to the server with the event name `'measureRTT'`. It also listens for a response event named `'RTTMeasured'` from the server. Upon receiving the response, it calculates the RTT, logs it along with the response size, and then proceeds to calculate metrics based on the RTT.

The main logic remains the same:

function calculateMetrics(rtt) {

    rttValues.push(rtt);
    
     minRTT = calculateMinimum(rttValues);
     maxRTT = calculateMaximum(rttValues);
     medianRTT = calculateMedian(rttValues);
     avgRTT = calculateAverage(rttValues);
      stdDevRTT = calculateStandardDeviation(rttValues);
       skewnessRatio = calculateSkewnessRatio(rttValues);

        myConsole.innerText =
           "Current frequency: " + frequenciesHz[currentFrequencyIndex] + "\n" +
            "Amount of requests: " + rttValues.length + "\n" +
             "RTT: " + rtt + " ms\n" +
              "Minimum RTT: " + minRTT + " ms\n" +
               "Maximum RTT: " + maxRTT + " ms\n" +
                "Median RTT: " + medianRTT + " ms\n" +
                 "Average RTT: " + avgRTT + " ms\n" +
                  "Standard Deviation RTT: " + stdDevRTT + " ms\n" +
                   "Skewness Ratio: " + skewnessRatio + "\n";

        updateLoadingBar();
}

The following statistics are based on **100 requests** per round.

## Results of the test on a personal area network (PAN)
Technical characteristics of the computer on which the experiment was conducted:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         39 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  12
  On-line CPU(s) list:   0-11
Vendor ID:               GenuineIntel
  Model name:            Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    CPU family:          6
    Model:               158
    Thread(s) per core:  2
    Core(s) per socket:  6
    Socket(s):           1
    Stepping:            10
    CPU max MHz:         4500.0000
    CPU min MHz:         800.0000

***Firefox*** browser was used to run the client part of the application.

<table id="results-table">
<thead>
<tr>
<th>Freq (Hz)</th>
<th>Request size</th>
<th>Total Requests</th>
<th>Min RTT (ms)</th>
<th>Max RTT (ms)</th>
<th>Med RTT (ms)</th>
<th>Avg RTT (ms)</th>
<th>STD RTT (ms)</th>
<th>Skewness Ratio</th>
</tr>
</thead>
<tbody>
<tr>
<td>16</td>
<td>128</td>
<td>100</td>
<td>1</td>
<td>10</td>
<td>3</td>
<td>3.87</td>
<td>4.19</td>
<td>0.0783</td>
</tr><tr>
<td>8</td>
<td>128</td>
<td>100</td>
<td>1</td>
<td>9</td>
<td>4</td>
<td>3.61</td>
<td>1.09</td>
<td>0.0128</td>
</tr><tr>
<td>4</td>
<td>128</td>
<td>100</td>
<td>0</td>
<td>7</td>
<td>4</td>
<td>3.71</td>
<td>2.25</td>
<td>0.0401</td>
</tr><tr>
<td>2</td>
<td>128</td>
<td>100</td>
<td>1</td>
<td>8</td>
<td>4</td>
<td>3.60</td>
<td>0.91</td>
<td>0.0040</td>
</tr><tr>
<td>1</td>
<td>128</td>
<td>100</td>
<td>1</td>
<td>3</td>
<td>4</td>
<td>3.84</td>
<td>1.14</td>
<td>0.0516</td>
</tr><tr>
<td>16</td>
<td>256</td>
<td>100</td>
<td>1</td>
<td>5</td>
<td>3</td>
<td>2.82</td>
<td>0.91</td>
<td>0.0029</td>
</tr><tr>
<td>8</td>
<td>256</td>
<td>100</td>
<td>0</td>
<td>5</td>
<td>4</td>
<td>3.53</td>
<td>0.87</td>
<td>-0.0138</td>
</tr><tr>
<td>4</td>
<td>256</td>
<td>100</td>
<td>1</td>
<td>5</td>
<td>4</td>
<td>3.58</td>
<td>0.76</td>
<td>-0.0104</td>
</tr><tr>
<td>2</td>
<td>256</td>
<td>100</td>
<td>1</td>
<td>8</td>
<td>4</td>
<td>3.81</td>
<td>1.00</td>
<td>0.0096</td>
</tr><tr>
<td>1</td>
<td>256</td>
<td>100</td>
<td>1</td>
<td>9</td>
<td>4</td>
<td>3.75</td>
<td>0.98</td>
<td>0.0183</td>
</tr><tr>
<td>16</td>
<td>512</td>
<td>100</td>
<td>1</td>
<td>5</td>
<td>2</td>
<td>2.65</td>
<td>0.98</td>
<td>0.0031</td>
</tr><tr>
<td>8</td>
<td>512</td>
<td>100</td>
<td>1</td>
<td>8</td>
<td>3</td>
<td>3.05</td>
<td>0.98</td>
<td>0.0107</td>
</tr><tr>
<td>4</td>
<td>512</td>
<td>100</td>
<td>1</td>
<td>8</td>
<td>4</td>
<td>3.48</td>
<td>1.10</td>
<td>0.0089</td>
</tr><tr>
<td>2</td>
<td>512</td>
<td>100</td>
<td>1</td>
<td>7</td>
<td>4</td>
<td>3.60</td>
<td>0.73</td>
<td>0.0019</td>
</tr><tr>
<td>1</td>
<td>512</td>
<td>100</td>
<td>1</td>
<td>6</td>
<td>3.5</td>
<td>3.47</td>
<td>0.81</td>
<td>-0.0025</td>
</tr><tr>
<td>16</td>
<td>1024</td>
<td>100</td>
<td>1</td>
<td>6</td>
<td>2.5</td>
<td>2.68</td>
<td>1.11</td>
<td>0.0032</td>
</tr><tr>
<td>8</td>
<td>1024</td>
<td>100</td>
<td>1</td>
<td>11</td>
<td>3</td>
<td>3.24</td>
<td>3.88</td>
<td>0.0949</td>
</tr><tr>
<td>4</td>
<td>1024</td>
<td>100</td>
<td>1</td>
<td>12</td>
<td>4</td>
<td>3.81</td>
<td>2.97</td>
<td>0.0880</td>
</tr><tr>
<td>2</td>
<td>1024</td>
<td>100</td>
<td>1</td>
<td>7</td>
<td>4</td>
<td>3.57</td>
<td>0.79</td>
<td>0.0095</td>
</tr><tr>
<td>1</td>
<td>1024</td>
<td>100</td>
<td>1</td>
<td>5</td>
<td>4</td>
<td>3.59</td>
<td>0.78</td>
<td>-0.0097</td>
</tr><tr>
<td>16</td>
<td>2048</td>
<td>100</td>
<td>1</td>
<td>7</td>
<td>3</td>
<td>2.92</td>
<td>1.32</td>
<td>0.0064</td>
</tr><tr>
<td>8</td>
<td>2048</td>
<td>100</td>
<td>1</td>
<td>9</td>
<td>2</td>
<td>2.57</td>
<td>1.11</td>
<td>0.0244</td>
</tr><tr>
<td>4</td>
<td>2048</td>
<td>100</td>
<td>1</td>
<td>7</td>
<td>4</td>
<td>3.63</td>
<td>0.98</td>
<td>0.0042</td>
</tr><tr>
<td>2</td>
<td>2048</td>
<td>100</td>
<td>1</td>
<td>8</td>
<td>4</td>
<td>3.67</td>
<td>1.13</td>
<td>0.0308</td>
</tr><tr>
<td>1</td>
<td>2048</td>
<td>100</td>
<td>1</td>
<td>9</td>
<td>4</td>
<td>3.74</td>
<td>1.00</td>
<td>0.0237</td>
</tr></tbody>
</table>

### Summary and Conclusions

The table presents the results of a test conducted on a personal area network (PAN) under varying frequencies and request sizes. Here's a summary of the findings:

- **Frequency (Hz)**: Ranged from 1 Hz to 16 Hz, indicating the rate at which requests were sent to the server.
- **Request Size**: Varied from 128 bytes to 2048 bytes, representing the size of each request sent.
- **Total Requests**: Consisted of 100 requests for each combination of frequency and request size.

#### Observations:

- **RTT Metrics**:
- **Min RTT (ms)**: Ranged from 0 ms to 1 ms, indicating the shortest round-trip time observed.
- **Max RTT (ms)**: Spanned from 3 ms to 12 ms, representing the longest round-trip time observed.
- **Median RTT (ms)**: Varied between 2 ms and 4 ms, reflecting the middle value of the round-trip time distribution.
- **Avg RTT (ms)**: Ranged from 2.57 ms to 3.84 ms, representing the average round-trip time observed.
- **STD RTT (ms)**: Showcased standard deviations ranging from 0.81 ms to 4.19 ms, indicating the spread of round-trip times around the mean.
- **Skewness Ratio**: Spanned from -0.0138 to 0.0783, reflecting the symmetry or asymmetry of the round-trip time distribution.

#### Conclusions:

- **Impact of Frequency**: Higher frequencies generally resulted in shorter round-trip times, as evidenced by the decreasing trend in average and median RTT with increasing frequency.
- **Effect of Request Size**: Larger request sizes tended to lead to longer round-trip times, possibly due to increased processing overhead or network congestion.
- **RTT Distribution**: The skewness ratio provided insights into the shape of the RTT distribution, with values closer to zero indicating a more symmetric distribution.
- **Optimization Opportunities**: Based on the observed metrics, optimizations such as tuning the request size or adjusting the frequency can be explored to improve overall system performance and reduce latency.

## Results of the test on a wide area network (WAN on replit.com hosting).

<table id="results-table">
<thead>
<tr>
<th>Freq (Hz)</th>
<th>Request size</th>
<th>Total Requests</th>
<th>Min RTT (ms)</th>
<th>Max RTT (ms)</th>
<th>Med RTT (ms)</th>
<th>Avg RTT (ms)</th>
<th>STD RTT (ms)</th>
<th>Skewness Ratio</th>
</tr>
</thead>
<tbody>
<tr>
<td>16</td>
<td>128</td>
<td>100</td>
<td>137</td>
<td>230</td>
<td>149.5</td>
<td>161.00</td>
<td>27.16</td>
<td>0.0106</td>
</tr><tr>
<td>8</td>
<td>128</td>
<td>100</td>
<td>137</td>
<td>218</td>
<td>138</td>
<td>141.46</td>
<td>12.05</td>
<td>0.0495</td>
</tr><tr>
<td>4</td>
<td>128</td>
<td>100</td>
<td>137</td>
<td>150</td>
<td>138</td>
<td>138.82</td>
<td>1.91</td>
<td>0.0370</td>
</tr><tr>
<td>2</td>
<td>128</td>
<td>100</td>
<td>137</td>
<td>202</td>
<td>138</td>
<td>139.25</td>
<td>6.41</td>
<td>0.0967</td>
</tr><tr>
<td>1</td>
<td>128</td>
<td>100</td>
<td>137</td>
<td>162</td>
<td>139</td>
<td>143.78</td>
<td>7.62</td>
<td>0.0095</td>
</tr><tr>
<td>16</td>
<td>256</td>
<td>100</td>
<td>137</td>
<td>146</td>
<td>139</td>
<td>139.07</td>
<td>1.69</td>
<td>0.0189</td>
</tr><tr>
<td>8</td>
<td>256</td>
<td>100</td>
<td>137</td>
<td>205</td>
<td>139</td>
<td>140.13</td>
<td>8.20</td>
<td>0.0650</td>
</tr><tr>
<td>4</td>
<td>256</td>
<td>100</td>
<td>137</td>
<td>237</td>
<td>139</td>
<td>140.79</td>
<td>10.59</td>
<td>0.0791</td>
</tr><tr>
<td>2</td>
<td>256</td>
<td>100</td>
<td>137</td>
<td>141</td>
<td>139</td>
<td>138.87</td>
<td>1.06</td>
<td>0.0052</td>
</tr><tr>
<td>1</td>
<td>256</td>
<td>100</td>
<td>137</td>
<td>158</td>
<td>139</td>
<td>141.86</td>
<td>5.79</td>
<td>0.0162</td>
</tr><tr>
<td>16</td>
<td>512</td>
<td>100</td>
<td>137</td>
<td>143</td>
<td>139</td>
<td>138.96</td>
<td>1.31</td>
<td>0.0094</td>
</tr><tr>
<td>8</td>
<td>512</td>
<td>100</td>
<td>137</td>
<td>144</td>
<td>139</td>
<td>139.18</td>
<td>1.34</td>
<td>0.0123</td>
</tr><tr>
<td>4</td>
<td>512</td>
<td>100</td>
<td>138</td>
<td>158</td>
<td>139</td>
<td>140.05</td>
<td>3.19</td>
<td>0.0356</td>
</tr><tr>
<td>2</td>
<td>512</td>
<td>100</td>
<td>137</td>
<td>159</td>
<td>139</td>
<td>141.08</td>
<td>5.21</td>
<td>0.0215</td>
</tr><tr>
<td>1</td>
<td>512</td>
<td>100</td>
<td>137</td>
<td>159</td>
<td>139</td>
<td>140.74</td>
<td>4.90</td>
<td>0.0222</td>
</tr><tr>
<td>16</td>
<td>1024</td>
<td>100</td>
<td>137</td>
<td>145</td>
<td>139</td>
<td>139.09</td>
<td>1.41</td>
<td>0.0168</td>
</tr><tr>
<td>8</td>
<td>1024</td>
<td>100</td>
<td>137</td>
<td>143</td>
<td>139</td>
<td>139.08</td>
<td>1.22</td>
<td>0.0113</td>
</tr><tr>
<td>4</td>
<td>1024</td>
<td>100</td>
<td>137</td>
<td>593</td>
<td>140</td>
<td>147.17</td>
<td>49.36</td>
<td>0.0816</td>
</tr><tr>
<td>2</td>
<td>1024</td>
<td>100</td>
<td>137</td>
<td>261</td>
<td>141</td>
<td>149.00</td>
<td>19.30</td>
<td>0.0329</td>
</tr><tr>
<td>1</td>
<td>1024</td>
<td>100</td>
<td>137</td>
<td>240</td>
<td>139</td>
<td>145.80</td>
<td>18.50</td>
<td>0.0345</td>
</tr><tr>
<td>16</td>
<td>2048</td>
<td>100</td>
<td>137</td>
<td>162</td>
<td>139</td>
<td>140.11</td>
<td>2.97</td>
<td>0.0458</td>
</tr><tr>
<td>8</td>
<td>2048</td>
<td>100</td>
<td>137</td>
<td>166</td>
<td>140</td>
<td>141.39</td>
<td>4.15</td>
<td>0.0288</td>
</tr><tr>
<td>4</td>
<td>2048</td>
<td>100</td>
<td>137</td>
<td>176</td>
<td>139</td>
<td>141.26</td>
<td>5.87</td>
<td>0.0317</td>
</tr><tr>
<td>2</td>
<td>2048</td>
<td>100</td>
<td>138</td>
<td>150</td>
<td>139</td>
<td>140.04</td>
<td>2.52</td>
<td>0.0223</td>
</tr><tr>
<td>1</td>
<td>2048</td>
<td>100</td>
<td>137</td>
<td>175</td>
<td>140</td>
<td>140.81</td>
<td>4.78</td>
<td>0.0480</td>
</tr></tbody>
</table>

### Summary and Conclusions

The table presents the results of a test conducted on a network infrastructure, focusing on various frequencies and request sizes. Here's a summary of the findings:

- **Frequency (Hz)**: Ranged from 1 Hz to 16 Hz, indicating the rate at which requests were sent to the server.
- **Request Size**: Varied from 128 bytes to 2048 bytes, representing the size of each request sent.
- **Total Requests**: Consisted of 100 requests for each combination of frequency and request size.

#### Observations:

- **RTT Metrics**:
- **Min RTT (ms)**: Ranged from 137 ms to 138 ms, indicating the shortest round-trip time observed.
- **Max RTT (ms)**: Spanned from 150 ms to 593 ms, representing the longest round-trip time observed.
- **Median RTT (ms)**: Varied between 138 ms and 149.5 ms, reflecting the middle value of the round-trip time distribution.
- **Avg RTT (ms)**: Ranged from 138.82 ms to 161 ms, representing the average round-trip time observed.
- **STD RTT (ms)**: Showcased standard deviations ranging from 1.22 ms to 49.36 ms, indicating the spread of round-trip times around the mean.
- **Skewness Ratio**: Spanned from 0.0094 to 0.0816, reflecting the symmetry or asymmetry of the round-trip time distribution.

#### Conclusions:

- **Impact of Frequency**: Generally, higher frequencies led to shorter round-trip times, as evidenced by the decreasing trend in average and median RTT with increasing frequency.
- **Effect of Request Size**: Larger request sizes tended to result in longer round-trip times, indicating potential processing overhead or network congestion. However, the impact varied across different frequencies.
- **RTT Distribution**: The skewness ratio provided insights into the shape of the RTT distribution, with values closer to zero indicating a more symmetric distribution. Higher skewness ratios suggested asymmetry in the distribution, potentially influenced by network conditions.
- **Optimization Opportunities**: Based on the observed metrics, optimizations such as adjusting request size or frequency can be explored to enhance system performance and reduce latency, especially considering the characteristics of the network infrastructure and varying workload demands.

## Comparison of Results between Personal Area Network (PAN) and Wide Area Network (WAN)

#### Round-Trip Time (RTT) Metrics:

- **Minimum RTT (ms)**:
- PAN: Ranged from 0 ms to 1 ms.
- WAN: Ranged from 137 ms to 138 ms.
- **Observation**: PAN generally exhibits significantly shorter minimum RTT compared to WAN.

- **Maximum RTT (ms)**:
- PAN: Spanned from 3 ms to 12 ms.
- WAN: Spanned from 150 ms to 593 ms.
- **Observation**: WAN generally experiences higher maximum RTT compared to PAN.

- **Median RTT (ms)**:
- PAN: Varied between 2 ms and 4 ms.
- WAN: Varied between 138 ms and 149.5 ms.
- **Observation**: PAN generally demonstrates shorter median RTT compared to WAN.

- **Average RTT (ms)**:
- PAN: Ranged from 2.57 ms to 3.84 ms.
- WAN: Ranged from 138.82 ms to 161 ms.
- **Observation**: PAN generally yields lower average RTT compared to WAN.

- **Standard Deviation (STD) RTT (ms)**:
- PAN: Ranged from 0.81 ms to 4.19 ms.
- WAN: Ranged from 1.22 ms to 49.36 ms.
- **Observation**: PAN generally exhibits lower variability in RTT compared to WAN.

- **Skewness Ratio**:
- PAN: Ranged from -0.0138 to 0.0783.
- WAN: Ranged from 0.0094 to 0.0816.
- **Observation**: PAN generally demonstrates slightly lower skewness ratios compared to WAN, indicating a more symmetric distribution of RTT.

#### General Observations:

- **Impact of Network Type**: PAN typically offers lower latency and more consistent performance compared to WAN, as it operates within a smaller, more controlled environment.
- **Variability**: WAN experiences higher variability in RTT metrics, likely due to factors such as network congestion, packet loss, and longer physical distances between nodes.
- **Optimization Opportunities**: While PAN may require less optimization due to its inherently stable environment, WAN performance can benefit significantly from optimizations targeting network efficiency, congestion management, and protocol enhancements.

## Comparison of the obtained data with the data of the system network utility ping

### Results of the ping commad from my computer to replit server:

odal@od-gr56htd:~$ ping -c 10 3eb92c6b-e84c-4e44-9407-35dce7c43ad4-00-2607akwr7pdd6.worf.replit.dev
PING 3eb92c6b-e84c-4e44-9407-35dce7c43ad4-00-2607akwr7pdd6.worf.replit.dev (34.75.151.117) 56(84) bytes of data.
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=1 ttl=105 time=138 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=2 ttl=105 time=137 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=3 ttl=105 time=138 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=4 ttl=105 time=140 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=5 ttl=105 time=138 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=6 ttl=105 time=137 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=7 ttl=105 time=137 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=8 ttl=105 time=140 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=9 ttl=105 time=137 ms
64 bytes from 117.151.75.34.bc.googleusercontent.com (34.75.151.117): icmp_seq=10 ttl=105 time=137 ms

--- 3eb92c6b-e84c-4e44-9407-35dce7c43ad4-00-2607akwr7pdd6.worf.replit.dev ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9019ms
rtt min/avg/max/mdev = 136.538/137.910/140.316/1.154 ms

Let's look at my current location and [replit](https://e0777ada-8473-4e26-b713-47854aec789c-00-20990m27funaj.picard.replit.dev/):

<table class="table">
<tbody>
<tr>
<td>Domain:</td>
<td>78.26.151.209</td>
<td>3eb92c6b-e84c-4e44-9407-35dce7c43ad4-00-2607akwr7pdd6.worf.replit.dev</td>
</tr>
<tr>
<td>Country:</td>
<td>Ukraine</td>
<td>United States Of America</td>
</tr>
<tr>
<td>Region:</td>
<td>Odeska Oblast</td>
<td>California</td>
</tr>
<tr>
<td>City:</td>
<td>Odessa</td>
<td>Mountain View</td>
</tr>
<tr>
<td>Latitude:</td>
<td>46.477274</td>
<td>37.405992</td>
</tr>
<tr>
<td>Longitude:</td>
<td>30.732597</td>
<td>-122.078515</td>
</tbody>
</table>

Distance between me and [replit](https://3eb92c6b-e84c-4e44-9407-35dce7c43ad4-00-2607akwr7pdd6.worf.replit.dev) is:

<table class="table table-striped">
<tbody>
<tr>
<td>Meters</td>
<td>10301421.39</td>
</tr>
<tr>
<td>Kilometers</td>
<td>10301.42</td>
</tr>
</tbody>
</table>

## Speed of the signal

The speed of the signal is determined by the speed of light in the medium through which the signal is being transmitted. The speed of light in a vacuum is approximately 299,792,458 meters per second (m/s). However, in most cases, signals are transmitted through cables or other mediums, which have a lower speed of light.

In the case of a digital signal being transmitted over a coaxial cable, the speed of the signal is approximately 2/3 the speed of light in the medium (coaxial cable). This is because the signal is transmitted as an electromagnetic wave, and the wave travels at 2/3 the speed of light in the medium.

For example, if the signal is being transmitted over a coaxial cable, the speed of the signal would be approximately $\frac{2}{3} \times 299,792,458 \, \text{m/s} = 199,854,742.67 \, \text{m/s} = 200 \, \text{km/ms}$.
However, the actual speed of the signal may vary depending on the specific medium and signal type.

With this speed, a signal would cover a distance of 200 km in 1 millisecond. Therefore, in 137 milliseconds the signal would travel a distance of $137 \, \text{ms} \times 200 \, \text{km/ms} = 27,400 \, \text{km}$

## Conclusions

So, an RTT of 137 ms indicates that the signal has traveled approximately 27400 kilometers round trip between the source and the destination. This means the distance between servers is twice smaller: 13700 km.

With an RTT of 150 ms, it suggests that the signal has journeyed roughly 30000 kilometers round trip between the source and the destination. Consequently, the distance between servers is halved, around 15000 km.

According to the data from 2ip.ua the distance between me and server repl.it(10301.42 km).

The frequency of the signal affects its transmission speed. High-frequency signals may have a higher transmission speed due to shorter intervals between signal pulses. However, this can lead to signal loss issues due to dispersion and other effects, especially over long distances.

Low-frequency signals may have a lower transmission speed due to longer intervals between signal pulses. However, they may be more resilient to signal loss over long distances.

Thus, differences in transmission speed depending on frequency can be attributed to both the physical characteristics of the transmission medium and the characteristics of the signal itself.