cevatbarisyilmaz/lossy

Go package to simulate bandwidth, latency and packet loss for net.PacketConn and net.Conn interfaces

lossy

Go package to simulate bandwidth, latency and packet loss for net.PacketConn and net.Conn interfaces.

Its main usage is to test robustness of applications and network protocols run over unreliable transport protocols such as UDP or IP. As a side benefit, it can also be used as outbound bandwidth limiter.

lossy only alters the writing side of the connection, reading side is kept as it is.

Example

package main

import (
	"fmt"
	"github.com/cevatbarisyilmaz/lossy"
	"log"
	"math/rand"
	"net"
	"time"
)

const packetSize = 64

func main() {
	// Create two connection endpoints over UDP
	packetConn, conn := createConnections()

	// Create a lossy packet connection
	bandwidth := 1048 // 8 Kbit/s
	minLatency := 100 * time.Millisecond
	maxLatency := time.Second
	packetLossRate := 0.33
	headerOverhead := lossy.UDPv4MinHeaderOverhead
	lossyPacketConn := lossy.NewPacketConn(packetConn, bandwidth, minLatency, maxLatency, packetLossRate, headerOverhead)

	// Write some packets via lossy
	var bytesWritten int
	const packetCount = 32
	go func() {
		for i := 0; i < packetCount; i++ {
			packet := createPacket()
			_, err := lossyPacketConn.WriteTo(packet, conn.LocalAddr())
			if err != nil {
				log.Fatal(err)
			}
			bytesWritten += len(packet) + headerOverhead
		}
		fmt.Println("Sent", packetCount, "packets with total size of", bytesWritten, "bytes")
		baseTransmissionDuration := time.Duration(float64(bytesWritten * int(time.Second)) / float64(bandwidth))
		earliestCompletion := baseTransmissionDuration + minLatency
		latestCompletion := baseTransmissionDuration + maxLatency
		fmt.Println("Expected transmission duration is between", earliestCompletion, "and", latestCompletion)
	}()

	// Read packets at the other side
	const timeout = 3 * time.Second
	var packets, bytesRead int
	startTime := time.Now()
	for {
		_ = conn.SetReadDeadline(time.Now().Add(timeout))
		buffer := make([]byte, packetSize)
		n, err := conn.Read(buffer)
		if err != nil {
			break
		}
		bytesRead += n + headerOverhead
		packets++
	}
	dur := time.Now().Sub(startTime) - timeout
	fmt.Println("Received", packets, "packets with total size of", bytesRead, "bytes in", dur)

	// Close the connections
	_ = lossyPacketConn.Close()
	_ = conn.Close()
}

func createConnections() (net.PacketConn, net.Conn) {
	packetConn, err := net.ListenUDP("udp", &net.UDPAddr{
		IP:   net.IPv4(127, 0, 0, 1),
		Port: 0,
	})
	if err != nil {
		log.Fatal(err)
	}
	conn, err := net.DialUDP("udp", nil, packetConn.LocalAddr().(*net.UDPAddr))
	if err != nil {
		log.Fatal(err)
	}
	return packetConn, conn
}

func createPacket() []byte {
	packet := make([]byte, packetSize)
	rand.Read(packet)
	return packet
}

Output

Sent 32 packets with total size of 2944 bytes
Expected transmission duration is between 2.909160305s and 3.809160305s
Received 23 packets with total size of 2116 bytes in 3.2507523s

lossy's Issues

Reordering of packets for PacketConn

Since UDP does not promise anything about ordered delivery, it would be nice to be able to test protocols to make sure they don't rely on packets order.

Though, I am not sure how this would work with bandwidth limitations and latency.

Background info to header overhead constants?

RE the current constant values in https://github.com/cevatbarisyilmaz/lossy/blob/master/lossy.go, it would be nice if there was some documentation that explained the derivation of these constant values.

Buffer garbling on write

Since you spawn a goroutine for each send, if the buffers are reused by the application after sending (like in KCP library we use), they will get garbled potentially before sending. I suggest either noting in the documentation that one needs to copy buffers before calling WriteTo() or adding an explicit copy before making a goroutine:

func (c *packetConn) WriteTo(bts []byte, addr net.Addr) (int, error) {
...
  p := make([]byte, len(bts))
  copy(p, bts)
  go func() {
...

https://github.com/cevatbarisyilmaz/lossy/blob/master/packet_conn.go#L69

conn.go has the same issue.