Month: April 2023

TURN/STUN Servers

TURN (Traversal Using Relay NAT) and STUN (Session Traversal Utilities for NAT) servers are used to help establish and maintain real-time communications, such as VoIP calls, video conferencing, and online gaming, between devices on different networks.

When two devices attempt to communicate with each other, they first need to exchange information about their IP addresses and network settings. However, when devices are located behind a NAT (Network Address Translation) router, this information may not be directly available, making it difficult to establish a direct connection between the devices.

This is where TURN and STUN servers come in.

STUN servers provide a way for devices to discover their public IP address and port number, which can be used to establish a direct connection between the devices. When a device sends a request to a STUN server, the server responds with the device’s public IP address and port number. This information can then be used to establish a direct connection between the devices, if possible.

However, in some cases, a direct connection may not be possible due to firewalls or other network restrictions. This is where TURN servers come in. A TURN server acts as a relay, allowing devices to communicate with each other even if they are unable to establish a direct connection. When a direct connection is not possible, devices can send their data to the TURN server, which relays it to the other device.

In summary, STUN servers help devices discover their public IP addresses and port numbers, which can be used to establish a direct connection between devices when possible. TURN servers act as relays when a direct connection is not possible, allowing devices to communicate with each other even if they are located behind firewalls or other network restrictions.

Here is a basic configuration for a TURN server using the open-source software Coturn:

Install Coturn:

sudo apt-get install coturn

Configure Coturn by editing the turnserver.conf file:

sudo nano /etc/turnserver.conf

Set the listening IP address and port number for the TURN server:

listening-ip=
listening-port=

Configure authentication by setting a username and password:

user=:

Set the realm for the TURN server, which is used to identify the domain:

realm=

Set the type of relay to be used by the server:

relay-type=

Common values for include udp, tcp, and tls.

Set the maximum transmission unit (MTU) size for the relay packets:

mtu=

Enable verbose logging for debugging purposes:

verbose

Save and close the turnserver.conf file, and then start the TURN server:

sudo systemctl start coturn

Using FFMPEG to convert file types

FFmpeg is a powerful command-line tool that can be used to convert media files from one format to another. Here’s how FFmpeg works to convert a picture to a different format:

  1. Input file: The first step is to specify the input file using the -i option, followed by the file path of the picture you want to convert.
  2. Codec: Next, you need to specify the codec to use for the output file. FFmpeg supports a wide range of codecs for different media formats. For example, to convert a PNG image to a JPEG image, you can use the -c:v option followed by the codec name “libjpeg”.
  3. Output file: Finally, you need to specify the output file using the -o option, followed by the file path of the new image you want to create. You can also specify additional options such as the output file format using the -f option.

Here’s an example command to convert a PNG image to a JPEG image using FFmpeg:

ffmpeg -i input.png -c:v libjpeg output.jpg

In this example, FFmpeg reads the input file “input.png”, uses the “libjpeg” codec to convert the image to a JPEG format, and saves the output file as “output.jpg”.

The Fyro File Converter provides a handy web interface to do a lot of common file type conversions. But it doesn’t just do image file conversions – you can also do video conversions as well!

In the example below, FFmpeg is used to convert an input video file “input.mp4” to an output video file “output.mkv” using the H.264 video codec (libx264) and the AAC audio codec (-c:v and -c:a options, respectively). The options -preset and -crf are used to control the quality of the output video: “slow” is the encoding preset, and “22” is the Constant Rate Factor (CRF) value, which controls the trade-off between quality and file size.

ffmpeg -i input.mp4 -c:v libx264 -preset slow -crf 22 -c:a aac -b:a 128k output.mkv

Here’s a breakdown of the options used in this example:

  • -i input.mp4: Specifies the input video file.
  • -c:v libx264: Specifies the H.264 video codec for the output file.
  • -preset slow: Specifies the encoding preset to use for the output file.
  • -crf 22: Specifies the CRF value for the output file (lower values result in higher quality but larger file sizes).
  • -c:a aac: Specifies the AAC audio codec for the output file.
  • -b:a 128k: Specifies the audio bitrate for the output file.
  • output.mkv: Specifies the output file name and format.

Basically, this command would convert the input video file from MP4 format to Matroska (MKV) format using the specified video and audio codecs, with a slow encoding preset and a CRF value of 22 for the video.

Video streaming protocols

We’ve recently been developing applications for streaming live video, and experimenting with different streaming protocols. We started off with HLS, but since the use case required extremely low latency, we eventually moved on to other protocols. In our testing, we found that MJPEG was able to provide near-instantaneous results, but with the obvious drawback that it does not support audio, and there is really no defined protocols for MJPEG streams, which means that applications support it in wildly different ways. Eventually we started using SRT, which has been working extremely well for our use case. Here we’ll go over some basics about the differences between these common streaming protocols.

HLS, MJPEG, SRT, and NDI are all different streaming protocols used for video transmission over the internet. Here’s a brief overview of each protocol:

  1. HLS (HTTP Live Streaming): HLS is a streaming protocol developed by Apple that breaks a video into small chunks and sends them over HTTP. The video is divided into multiple bitrate versions, allowing for adaptive streaming based on the viewer’s internet connection. HLS is widely supported on different devices and platforms, and is commonly used for live streaming.
  2. MJPEG (Motion JPEG): MJPEG is a video compression format that compresses each frame of video as a separate JPEG image. It is not a streaming protocol in itself, but can be used with other protocols such as HTTP or RTSP to stream video. MJPEG is a simple format that is easy to implement and is often used in security cameras and webcams.
  3. SRT (Secure Reliable Transport): SRT is an open-source streaming protocol that provides low-latency video transmission with secure encryption and error correction. It is designed to handle poor network conditions and maintain the quality of the video stream.
  4. NDI (Network Device Interface): NDI is a protocol developed by NewTek that allows for low-latency video transmission over a local network. It is designed for use with professional video production equipment and software and provides high-quality, low-latency video with low CPU usage.

In summary, HLS is a widely supported streaming protocol commonly used for live streaming, MJPEG is a video compression format that can be used for streaming, SRT is an open-source streaming protocol designed for reliability, and NDI is a protocol designed for professional video production equipment and software. The choice of protocol depends on the specific use case and requirements of the video streaming application.

DNS over TCP

We recently ran into a problem where a DNS query was failing because the response was too large. The maximum size of a DNS response that can be sent over UDP (User Datagram Protocol) is 512 bytes. This is because the original DNS protocol was designed to fit within a single UDP datagram of this size. However, modern DNS implementations often support an extension called EDNS0 (Extension Mechanisms for DNS 0) that allows for larger DNS messages. The problem that we ran into was that our platform didn’t support DNS over TCP!

If a DNS response exceeds the 512-byte limit, the DNS server will set the “truncated” (TC) bit in the response message header and indicate that the client should retry the request using TCP (Transmission Control Protocol). TCP is a reliable, connection-oriented protocol that can handle larger data payloads than UDP.

In practice, most DNS queries and responses fit within the 512-byte limit, and TCP is rarely used for DNS traffic. However, certain DNS applications, such as DNSSEC (DNS Security Extensions) and large DNS zone transfers, may require the use of TCP due to the size of the response data.

Single-threaded vs. multi-threaded file transfers

Single-threaded and multi-threaded file transfers refer to the method by which files are transferred over a network. Here’s a brief overview of each approach:

  1. Single-threaded file transfer: In a single-threaded file transfer, the file is transferred over the network using a single network connection and a single thread. This means that the file is sent in a linear fashion, with each byte being sent one at a time. While single-threaded transfers are simple and easy to implement, they can be slower and less efficient than multi-threaded transfers, especially for larger files and over slower networks.
  2. Multi-threaded file transfer: In a multi-threaded file transfer, the file is split into smaller parts and each part is sent over a separate network connection using multiple threads. This allows for parallel transfer of the file, which can result in faster transfer times and better efficiency, especially over high-speed networks. However, multi-threaded transfers can be more complex to implement and can require more resources on both the sender and receiver sides.

In summary, single-threaded file transfers are simpler but can be slower and less efficient, while multi-threaded file transfers can be faster and more efficient but require more resources and complexity to implement. The choice of approach depends on the specific requirements and constraints of the file transfer application.

The Fyro Speed Test is single-threaded, so you should not expect to be able to max out your internet connection’s throughput capabilities, but since typical file downloads over the internet are also single-threaded, this provides for a good baseline for the speed you can generally expect.

Configuring OSPF

OSPF (Open Shortest Path First) is a popular interior gateway protocol (IGP) used for routing within an autonomous system (AS) in large enterprise networks and service provider networks. OSPF is a link-state protocol that allows routers to exchange information about the topology of the network and to compute the shortest path to each destination network based on this information.

OSPF uses a hierarchical network design with areas to reduce the size of the routing table and to improve scalability and performance. Each area is assigned a unique identifier and routers within an area only need to maintain a summary of the networks outside the area, which reduces the amount of routing information that needs to be exchanged.

OSPF also supports multiple paths to the same destination network, which allows for load balancing and redundancy. OSPF path selection is based on a metric called cost, which is calculated based on the bandwidth of the link. OSPF also supports authentication to ensure the security of the routing information.

Hhere’s an example configuration for OSPF on a network:

Determine the network topology and assign each router a unique Router ID (RID). In this example, we’ll use the following topology:

            +---[R2]---+
            |          |
[R1]--------+          +--------[R4]
            |          |
            +---[R3]---+

We’ll assign the following RIDs:

R1: 1.1.1.1
R2: 2.2.2.2
R3: 3.3.3.3
R4: 4.4.4.4

Enable OSPF on each router by configuring the router ID and the networks to be advertised. For example, on R1:

router ospf 1
ospf router-id 1.1.1.1
network 10.0.12.0 0.0.0.255 area 0
network 10.0.13.0 0.0.0.255 area 0

This configures OSPF for process ID 1, sets the router ID to 1.1.1.1, and advertises the networks 10.0.12.0/24 and 10.0.13.0/24 in area 0.

Repeat step 2 for each router, changing the router ID and the networks to be advertised as appropriate.

Verify that OSPF is running correctly by checking the OSPF neighbor table on each router:

show ip ospf neighbor

This should show the neighboring routers and their state.

(Optional) Fine-tune the OSPF configuration by adjusting parameters such as the hello and dead intervals, the OSPF network type (e.g., broadcast, point-to-point), and the cost of interfaces.

This is just a basic example, and there are many other options and considerations when configuring OSPF on a network.

Types of DNS records

There are several types of DNS (Domain Name System) records, each serving a different purpose. Here are some of the most common types:

  1. A (Address) Record: This record maps a domain name to an IPv4 address.
  2. AAAA (IPv6 Address) Record: This record maps a domain name to an IPv6 address.
  3. CNAME (Canonical Name) Record: This record creates an alias for an existing domain name, allowing it to be accessed under a different name.
  4. MX (Mail Exchange) Record: This record specifies the mail server responsible for accepting email messages for a particular domain.
  5. TXT (Text) Record: This record allows for the addition of arbitrary text to a domain name. It is often used for domain verification, spam prevention, and other administrative purposes.
  6. NS (Name Server) Record: This record identifies the authoritative name servers for a particular domain.
  7. SRV (Service) Record: This record specifies the location of a service, such as a SIP or XMPP server, on a domain.
  8. SOA (Start of Authority) Record: This record provides information about the domain name, such as the primary name server, the email address of the domain administrator, and the domain’s serial number.

These records are essential for the functioning of the DNS system and are used by various internet services to provide functionality such as email delivery, web browsing, and other network communication protocols.

Animated Picture Filetypes

The Fyro File Converter supports most common animated picture files, like GIF (Graphics Interchange Format) and APNG (Animated Portable Network Graphics).

The main difference between these two formats is the way they store the animation frames. GIF files use a lossless compression technique, which means that every frame is stored as a full image with no loss of quality. This results in larger file sizes but ensures that the animation looks crisp and clear. In contrast, APNG files use a combination of lossless and lossy compression techniques to store the animation frames, resulting in smaller file sizes but potentially lower quality.

Another important difference is that APNG files support alpha transparency, which means that they can have transparent backgrounds, while GIF files only support a binary transparency which means that each pixel is either fully transparent or fully opaque.

Overall, GIF files are more widely supported across various software and platforms, while APNG files are generally considered to be a higher-quality alternative with more advanced features.

CIDR Notation

CIDR (Classless Inter-Domain Routing) notation is a compact representation of an IP address and subnet mask. It is used to express the number of bits that make up the network portion of the IP address. CIDR notation is written using a forward slash (/) followed by the number of bits in the network portion of the address. For example, a CIDR notation of /24 means that the first 24 bits of the IP address are the network portion, and the remaining bits are the host portion.

There are several common CIDR subnet notations, each of which represents a different range of IP addresses:

/32: This notation represents a single IPv4 address. It is often used to specify a particular host on a network.

/24: This notation represents a Class C network with 256 addresses. It is often used in small-to-medium-sized networks.

/16: This notation represents a Class B network with 65,536 addresses. It is often used in larger networks.

/8: This notation represents a Class A network with 16,777,216 addresses. It is typically used for very large networks.

/0: This notation represents the entire IPv4 address space. It is rarely used in practice, as it allows any IP address to be used.

CIDR notation is also used for IPv6 addresses. The same principles apply, but the notation uses a colon instead of a period to separate the parts of the address. For example, a CIDR notation of /64 means that the first 64 bits of the IPv6 address are the network portion. IPv6 addresses typically use larger subnet sizes than IPv4 addresses, as the address space is much larger.

© 2024 fyro.net