Universal Third-Party Testing Tools

  • Updated on Aug 12, 2024
  • Published on Jun 12, 2024
  • 8 minute(s) read
Prev Next

WHAT TO EXPECT

While xNIC installation provides you with a number of useful tools to test the functionality of your cloudSwXtch network (swxtch-perf, swxtch-tcpdump, etc.), there is also a wealth of universal third-party testing tools at your disposal.

In this article, we will take a deeper dive into these alternative options and understand their benefits and pitfalls.

Please Note: These tools should be used for testing purposes only.

VLC

VLC is a free and open-source cross-platform multimedia player and framework that plays most multimedia files, and various streaming protocols. As a highly visual tool, it can be used to demonstrate the delivery and fidelity of video streams from the cloudSwXtch to the xNIC.

Example

In the following example, a producer is streaming a .ts file using the RTP protocol to the multicast address 239.1.1.2 to port 1000 in a indefinite loop. The agent is consuming the stream.

Producer:

vlc file:////home/ubuntu/surfing.ts --sout '#rtp{dst=239.1.1.2,port=10000,mux=ts}' --loop

Consumer:

vlc rtp://@239.1.1.2:10000

vlc vs. cvlc

When using Linux, you can use cvlc instead of vlc. cvlc is an alias for “vlc -l dummy”. It is VLC without the user interface, lighter and faster to open remotely, and will show a window playing the video only. Note: cvlc does not work for Windows.

ffmpeg/ffplay

ffmpeg/ffply are command line tools to demonstrate the delivery of a stream. ffmpeg is the streamer, ffplay is the command to see the stream. While VLC requires a file to stream from the producer to the consumer, ffmpeg/ffplay can produce video test patterns. In the following example, we will use "testsrc", which will generate a test video pattern. This will display a color pattern with a scrolling gradient and a timestamp. If a stream appears, it means this was a successful delivery. Please note: Other test patterns are available for use.

Example

In this example, the user is testing a stream signal with a resolution of 640×480 at 30fps, in MPEG using labfi (Libavfilter input virtual device) for 1000 seconds to the multicast address 239.1.1.1, port 10000 using a packet size of 1316 bytes.

Producer

ffmpeg -hide_banner -f lavfi -re -i testsrc=duration=1000:size=640x480:rate=30 -f mpegts "udp://239.1.1.1:11000?pkt_size=1316"

Below is an example of ffmpeg producer output.

ffmpeg-producer

Consumer:

ffplay -hide_banner "udp://239.1..1:11000"

Below is an example ffplay consumer output. 

ffplay-consumer

A successful delivery of the stream will display the following stream in the consumer’s VM:

ffmpeg-producer-result

iPerf (v2)

Similar to swxtch-perf, iPerf is a multi-platform tool for network performance measurement and tuning. It is commonly used for bandwidth and latency measurements. However, what differs is that iPerf has additional arguments not found in swxtch-perf, our streamlined tool. Since iPerf (v3) does not support multicast, it is recommended to use iPerf (v2) for cloudSwXtch networking testing.

Example

In this example, the user is creating a UDP stream at multicast address 239.1.1.3, port 1000 for 120 seconds with a buffer length of 1000 bytes. The enhanced report will display stats for every second with enhanced reporting.

Producer:

iperf -c 239.1.1.3 -p 10000 -u -t 120 -i 1 -e -l 1000

  • Arguments Explained:

    • -c: the machine as the producer, specifying the multicast address

    • -p: the port

    • -u: the producer will be sending UDP packets

    • -t: the duration of the stream in seconds

    • -i: the time interval stats will be reported. In this case, it is every second (1).

    • -e: enhanced reporting (interval, transfer, bandwidth, write/err, PPS)

    • -l: length of buffers to read or write (1000)

This is an example of an iPerf producer output.

iperf-producer

Consumer:

iperf -s -u -B 239.1.1.3 -p 10000 -i 1

  • Arguments Explained:

    • -s: server, signifying a consumer

    • -u: consumer will be taking in UDP packets

    • -B: bind, specifying the multicast address (Note the capitalization.)

    • -p: the port

    • -i: the time interval stats will be reported (1)

This is an example of an iPerf consumer output. Note how each line item coincides with the single second interval.

iperf-consumer

No Consumer Output

On some older versions of iPerf 2, the consumer will not show any output. This can happen even when configured to do so. However, you can still check swxtch-top to see if the xNIC interface is getting traffic. To remedy this issue, ensure you have the latest version of iPerf 2.

sockperf

Another alternative to swxtch-perf is sockperf, a Linux-only network benchmarking utility over socket API that is designed for testing the latency and throughput of high-performance systems. While it is similar to both swxtch-perf and iPerf, it has far less commands than its counterparts. It is recommended to use sockperf when saturating the NIC and using the VM’s maximum amount of bandwidth.

Example

In this example, the user will create a stream at multicast address 239.1.1.4, port 10000 using a message size of 1472, sending 2000 messages per second in 30 seconds.

Producer (sockperf throughput):

sockperf throughput --ip 239.1.1.4 --msg-size 1472 --port 10000 --mps 2000 --time 30

Consumer (sockperf server):

sockperf server --ip 239.1.1.4 --Activity 800 --port 10000

This will consume the traffic and print the activity for the last 800 messages processed. The consumer will continually wait for the producer until it is shut off.

Python/Go

Users may choose to also build their own tool to test their cloudSwXtch network. Below are two examples using Python or Go programming language to test multicast messaging. What is great about cloudSwXtch is that when we say it requires no code changes, the same applies for testing.

Python

As a pre-installed program on Linux-based machines, using Python is a simple way to test your xNIC.

Producer

The key object here is the socket module and the instruction used to send is sock.sendto. As you can see in the code, no modification to the code is necessary in order to make “compatible” with the xNIC/cloudSwXtch. The following code will work on any multicast-compatible environment.

  1. Create a producer.py file on the producer VM. One method is to use nano. Note: You can name the file anything.

    nano python.py

  2. Copy and paste the following script:

    import socket
import struct
import time

def send_multicast_message(ip, port, message, delay):
    # Create the socket
    multicast_group = (ip, port)
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

    # Set the time-to-live for messages to 1 so they do not go past the local network segment
    ttl = struct.pack('b', 1)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, ttl)

    try:
        while True:
            # Send the message
            print(f'Sending "{message}" to {ip}:{port}')
            sock.sendto(message.encode('utf-8'), multicast_group)

            # Delay between messages
            time.sleep(delay)
    finally:
        print('Closing socket')
        sock.close()

# Example usage
send_multicast_message('239.1.1.1', 10000, 'Hello, Multicast!', 2)Save the file and close.

  3. Save and close.

  4. Run the script:

    python3 producer.py

Below is an example of the output:

python-1

Consumer

  1. Create a receiver.py file on your consumer VM. One method is to use nano. Note: You can name the file anything.

    nano consumer.py

  2. Copy and paste the following script:

    import socket
import struct

def receive_multicast_message(ip, port):
    # Create the socket
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

    # Bind to the server address
    sock.bind(('', port))

    # Tell the operating system to add the socket to the multicast group
    group = socket.inet_aton(ip)
    mreq = struct.pack('4sL', group, socket.INADDR_ANY)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

    # Receive/respond loop
    while True:
        print('Waiting to receive')
        data, address = sock.recvfrom(1024)

        print(f'Received "{data.decode("utf-8")}" from {address}')

# Example usage
receive_multicast_message('239.1.1.1', 10000)Save and close.

  3. Save and exit.

  4. Run the script:

python3 receiver.py

Below is an example of the output on the consumer VM:

python-2

Go

Go is an alternative programming language. However, unlike Python, it must be installed manually. Use the following example scripts to test.

Producer

The producer uses the command net.Dial to send a message using multicast.

// producer.go
package main

import (
    "fmt"
    "net"
    "os"
    "time"
)

func main() {
    multicastAddr := "239.1.1.1:10000"

    conn, err := net.Dial("udp", multicastAddr)
    if err != nil {
        fmt.Println("Error connecting:", err)
        os.Exit(1)
    }
    defer conn.Close()

    for {
        message := "Hello, Multicast!"
        _, err = conn.Write([]byte(message))
        if err != nil {
            fmt.Println("Error sending message:", err)
            os.Exit(1)
        }
        fmt.Println("Message sent:", message)
        time.Sleep(2 * time.Second)
    }
}

Consumer

The receiver uses the command net.ListenMulticastUDP.

// receiver.go
package main

import (
    "fmt"
    "net"
    "os"
)

func main() {
    multicastAddr := "239.1.1.1:10000"
    addr, err := net.ResolveUDPAddr("udp", multicastAddr)
    if err != nil {
        fmt.Println("Error resolving address:", err)
        os.Exit(1)
    }

    conn, err := net.ListenMulticastUDP("udp", nil, addr)
    if err != nil {
        fmt.Println("Error listening for multicast:", err)
        os.Exit(1)
    }
    defer conn.Close()

    buf := make([]byte, 1024)
    for {
        n, src, err := conn.ReadFromUDP(buf)
        if err != nil {
            fmt.Println("Error receiving message:", err)
            os.Exit(1)
        }
        message := string(buf[:n])
        fmt.Printf("Received message from %v: %s\n", src, message)
    }
}

Other Programming Languages

As with Python or Go, you can create programs in virtually any language with the same logic for sending multicast traffic and let the xNIC + cloudSwXtch take care of the rest. For example, in Javascript, the commands will be server.send and server.on. In C++, the commands will be sendto() and recvfrom().