# UDP Published articles for UDP. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Bringing QUIC to Seastar DevFeed: [Bringing QUIC to Seastar]() Original publisher: [Read original article]() Author: Cynthia Dunlop Published: 2026-09-14T13:02:07Z Content type: article Language: en Sources: [ScyllaDB]() Topics: [Seastar](), [networking](), [Remote Procedure Call (RPC)](), [C++](), [Latency](), [Protocol (disambiguation)]() Tags: [benchmarks](), [c-plus-plus](), [collaboration](), [engineering](), [latency](), [network](), [networking](), [rpc](), [scylladb](), [seastar](), [udp]() ### AI overview This article describes a University of Warsaw student project conducted with ScyllaDB to implement a QUIC transport for Seastar using the sans-I/O ngtcp2 library. It also adapts Seastar's RPC layer to operate over QUIC and reports benchmark results showing predictable overhead on a lossless loopback and benefits when packets are dropped. ### Source excerpt We built a QUIC transport for Seastar on top of ngtcp2's sans-I/O state machine, then adapted RPC to it twice: 1) as a one-to-one socket replacement, and 2) a QUIC-aware approach that opens a fresh stream per call. ## netcat (nc) Command in Linux, with Examples DevFeed: [netcat (nc) Command in Linux, with Examples]() Original publisher: [Read original article]() Author: Hayden James Published: 2026-08-01T10:42:27Z Content type: tutorial Language: en Sources: [Hayden James]() Topics: [networking](), [Linux](), [Tool]() Tags: [blog](), [commands](), [connectivity](), [debugging](), [examples](), [guide](), [linux](), [networking](), [port](), [security](), [server](), [sysadmins](), [tcp](), [tool](), [troubleshooting](), [udp]() ### AI overview A practical guide to the Linux nc (netcat) command, covering port testing, file transfers, banner grabbing, reverse shells, proxies, and network-service debugging over TCP and UDP. It also explains implementation differences across OpenBSD netcat, Ncat, BusyBox, and traditional netcat. ### Source excerpt The nc command (netcat) is a lightweight but surprisingly powerful networking tool for port testing, file transfers, banner grabbing, and connectivity debugging. This practical guide covers the flags and real-world usage patterns that Linux users and sysadmins actually reach for. Continue reading... ## Security Week 2624: троян в хентай-играх DevFeed: [Security Week 2624: троян в хентай-играх]() Original publisher: [Read original article]() Author: Kaspersky\_Lab ("Лаборатория Касперского") Published: 2026-06-08T17:00:51Z Content type: news Language: ru Sources: ["Лаборатория Касперского" RU]() Topics: [Security](), [FFmpeg (Fast Forward Moving Picture Experts Group)](), [PowerShell](), [Windows](), [GitHub]() Tags: [argamal](), [ffmpeg](), [github](), [ip](), [powershell](), [security](), [tag-9fe8963de219](), [trojan](), [udp](), [windows]() ### AI overview Kaspersky researchers analyzed the Argamal remote-access trojan, distributed with hentai games through file-sharing sites and torrent trackers. Modified ffmpeg.dll files trigger a PowerShell-based infection chain that retrieves an encrypted payload from GitHub and establishes persistence on Windows. The trojan can collect system information, execute commands, manipulate files, capture screenshots, and control the keyboard and mouse. ### Source excerpt Исследователи "Лаборатории Касперского" опубликовали подробный разбор вредоносного ПО Argamal, распространяемого на специализированных ресурсах вместе с хентай-играми. Данная вредоносная кампания была обнаружена в этом году, хотя некоторые связанные с ней DLL-файлы существовали как минимум с 2024 года. Игры с вредоносным довеском, как правило, заливались на публичный файлообменник, ссылки на который публиковались на тематических веб-сайтах. Распространялись они и через торрент-трекеры. Во всех случаях это был архив с полностью функциональной игрой, которая дополнялась модифицированной библиотекой ffmpeg.dll. Читать далее ## Connecting an ESP32 to the Cloud DevFeed: [Connecting an ESP32 to the Cloud]() Original publisher: [Read original article]() Author: John Lee Published: 2026-04-14T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32](), [Tutorial](), [data](), [Internet of things](), [Cloud](), [HTTP](), [JSON](), [TLS (Transport Layer Security)]() Tags: [blog](), [cloud](), [data](), [esp32](), [http](), [iot](), [json](), [protocol](), [tls](), [tutorial](), [udp]() ### AI overview This tutorial explains how to connect an ESP32 sensor to a cloud platform using a compact UDP datagram instead of the usual HTTP, JSON, and TLS approach. It presents TagoTiP, an open specification for structured IoT data, and describes frames of about 130 bytes with typed variables, units, device identification, and authorization information. ### Source excerpt Connecting an ESP32 to a cloud platform usually means HTTP libraries, JSON parsers, and TLS handshakes. This tutorial shows a different approach: a single UDP datagram, built with snprintf, carrying structured sensor data in about 130 bytes. The TagoTiP open specification makes it possible by defining the data structure so you don't have to. ## Adding a Syslog Server to a netlab Lab Topology DevFeed: [Adding a Syslog Server to a netlab Lab Topology]() Original publisher: [Read original article]() Published: 2025-10-27T06:23:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Logging](), [Containers](), [Ansible](), [Open Source]() Tags: [ansible](), [configuration](), [container](), [containers](), [github](), [json](), [logging](), [logs](), [netlab](), [ospf](), [router](), [server](), [storage](), [tcp](), [udp]() ### AI overview A tutorial shows how to add an Rsyslog-based Syslog server to a netlab lab topology. It configures a collector container to receive logs over TCP and UDP, adds Arista cEOS router nodes, applies logging configuration through templates, and verifies the resulting log files. ### Source excerpt netlab does not support a Syslog server (yet), but it's really easy to add one to your lab topology, primarily thanks to the Rsyslog team publishing a ready-to-run container. Let's do it ;) Adding a Syslog Server Rsyslog is an open-source implementation of a Syslog server (with many bells and whistles, most of which we won't use) that can (among other things) log incoming messages to a file. Even better (for our use case), the Rsyslog team regularly publishes Rsyslog containers; we'll use the rsyslog/rsyslog-collector container because it can "receive logs via UDP, TCP, and optionally RELP, and can send them to storage backends or files." Read more ... ## Using the OSI Model for Effective Production Issue Debugging DevFeed: [Using the OSI Model for Effective Production Issue Debugging]() Original publisher: [Read original article]() Author: Kamal Kumar Published: 2025-08-28T17:37:45Z Content type: tutorial Language: en Sources: [Housing.com]() Topics: [debugging](), [networking](), [Network](), [Routing (disambiguation)](), [Server](), [Authentication](), [Encryption](), [configuration](), [business logic](), [Framework]() Tags: [analysis](), [apis](), [authentication](), [configuration](), [debugging](), [devops](), [errors](), [firewalls](), [load](), [mapping](), [network](), [osi-model](), [production-debugging](), [production-issue](), [rca](), [root-cause-analysis](), [routing](), [servers](), [sre](), [tcp](), [troubleshooting](), [udp](), [web]() ### AI overview This tutorial explains how to use the seven-layer OSI model to structure root cause analysis for production alerts. It recommends checking lower layers for network and gateway errors, and higher layers for application and client errors, including connectivity, routing, logs, APIs, authentication, and configuration. ### Source excerpt In production environments, debugging alerts can sometimes feel like finding a needle in a haystack. Over the years, I've found the OSI (Open Systems Interconnection) model to be a reliable guide during Root Cause Analysis (RCA) of production issues. What is the OSI Model? The OSI model is a conceptual framework that standardizes the functions of a telecommunication or computing system into seven layers: Physical Layer -- Hardware, cables, switches Data Link Layer -- MAC addresses, switches, network topology Network Layer -- IP addressing, routing Transport Layer -- TCP/UDP, ports, session reliability Session Layer -- Session management, authentication Presentation Layer -- Data translation, encryption Application Layer -- APIs, web servers, applications How I Use OSI Layers in RCA: When I debug production alerts, I follow different approaches depending on the type of error: Network / Gateway Errors (e.g., 502, 504): These errors usually indicate communication issues between services. I start from the bottom layers (Physical -> Network -> Transport) to check connectivity, firewalls, routing, or load balancers. Application / Client Errors (e.g., 500, 503, 404): These errors generally originate from the application or business logic. I start from the top layers (Application -> Presentation -> Session) to check service logs, APIs, authentication issues, or configuration problems. Why this approach works: Following the OSI model provides a structured, layer-by-layer method for troubleshooting, ensuring that we don't miss low-level network issues or high-level application errors. It helps reduce mean time to resolution (MTTR) and improves the quality of RCA reports. Takeaway: The OSI model is not just a theoretical concept -- it's a practical tool that can guide engineers through complex production debugging. Next time you face a tricky alert, try mapping it to the OSI layers, and you might find the root cause faster than you think. Using the OSI Model for Effective Production Issue ## Ultra Ethernet: Reinventing X.25 DevFeed: [Ultra Ethernet: Reinventing X.25]() Original publisher: [Read original article]() Published: 2025-07-23T06:06:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [Ethernet](), [ibm]() Tags: [data-center](), [ethernet](), [ibm](), [ip](), [receiver](), [recovery](), [technical](), [udp]() ### AI overview The article examines reported features of Broadcom's Tomahawk Ultra ASIC and emerging Ultra Ethernet specifications, including a modified header, hop-by-hop retransmission, lossless Ethernet, and credit-based flow control. It argues that these ideas resemble mechanisms from Fibre Channel, IEEE 802.1 LLC2, and X.25, while expressing skepticism about the industry press coverage. ### Source excerpt One should never trust the technical details published by the industry press, but assuming the Tomahawk Ultra puff piece isn't too far off the mark, the new Broadcom ASIC (supposedly loosely based on emerging Ultra Ethernet specs): Uses Optimized Ethernet Header, replacing IP/UDP header with a 10-byte something (let's call it session identifier) Makes Ethernet lossless with hop-by-hop retransmission/error recovery Uses credit-based flow control (the receiver continuously updates the sender about the amount of available space) If you're ancient enough, you might recognize #3 as part of Fibre Channel, #2 and #3 as part of IEEE 802.1 LLC2 (used by IBM to implement SNA over Token Ring and Ethernet), and all three as the fundamental ideas of X.25 that Broadcom obviously reinvented at 800 Gbps speeds, proving (yet again) RFC 1925 Rule 11. ## Rock and Rollback: Realtime multiplayer in the browser, with rust and bevy DevFeed: [Rock and Rollback: Realtime multiplayer in the browser, with rust and bevy]() Original publisher: [Read original article]() Author: {"image"=\>"rj-headshot.jpg", "greetings"=\>nil} Published: 2024-12-08T06:00:00Z Content type: tutorial Language: en Sources: [Richard Jones]() Topics: [browser](), [browser-game](), [realtime](), [Bevy](), [Rust](), [QUIC](), [WebRTC](), [HTTP](), [Streaming]() Tags: [bevy](), [bevygap](), [browser](), [gamedev](), [http-3](), [multiplayer](), [netcode](), [quic](), [realtime](), [rust](), [snapshots](), [udp](), [webrtc]() ### AI overview This article discusses building a realtime multiplayer browser game with Rust and Bevy. It explains why TCP can delay updates, considers WebRTC and WebTransport over HTTP/3 and QUIC for unreliable data channels, and introduces snapshot interpolation as a multiplayer networking model. ### Source excerpt How hard it is to build a realtime multiplayer browser game? Like asteroids, but multiplayer. Retro vibes with modern netcode 🚀. ## The "simple" 38 step journey to getting an RFC DevFeed: [The "simple" 38 step journey to getting an RFC]() Original publisher: [Read original article]() Author: ben@benjojo.co.uk Published: 2024-12-05T10:43:41Z Content type: opinion Language: en Sources: [benjojo blog]() Topics: [Internet Engineering Task Force (IETF)](), [protocols](), [networking](), [routing-system](), [Internet]() Tags: [ietf](), [network](), [protocols](), [rfc](), [routing](), [routing-system](), [tcp](), [tcp-ip](), [udp]() ### AI overview A firsthand account of the three-and-a-half-year process of developing RFC9687 and navigating the Internet Engineering Task Force process. It explains when pursuing IETF standardization is appropriate, including cases involving changes to established protocols that affect the broader Internet routing system. ### Source excerpt The "simple" 38 step journey to getting an RFC The Internet is built on the mutual understanding of network protocols and practices, and most of those protocols are defined using Request For Comments (RFC) or Best Common Practices (BCP) documents. ## Attacking UNIX Systems via CUPS, Part I DevFeed: [Attacking UNIX Systems via CUPS, Part I]() Original publisher: [Read original article]() Author: Simone Margaritelli Published: 2024-09-26T14:51:30Z Content type: article Language: en Sources: [evilsocket]() Topics: [vulnerability](), [Security](), [Unix](), [Exploit](), [gnu linux](), [systems]() Tags: [bugs](), [cups](), [cups-browsed](), [cve](), [cve-2024-47076](), [cve-2024-47175](), [cve-2024-47176](), [cve-2024-47177](), [cybersecurity](), [disclosure](), [exploit](), [gnu-linux](), [hacking](), [ipp](), [lan](), [linux-security](), [mdns](), [no-authentication](), [port](), [print-services](), [printer](), [printers](), [printing](), [rce](), [responsible-disclosure](), [security](), [udp](), [unauthenticated-access](), [unix](), [vulnerability-research](), [zeroconf]() ### AI overview A security writeup describes multiple vulnerabilities in CUPS components affecting GNU/Linux and other UNIX systems. It reports that remote unauthenticated attackers may replace printer IPP URLs and trigger arbitrary command execution when a print job starts, with attacks possible over the public internet or via spoofed LAN advertisements. ### Source excerpt Hello friends, this is the first of two, possibly three (if and when I have time to finish the Windows research) writeups. We will start ## How to find hidden processes and ports on Linux/Unix/Windows DevFeed: [How to find hidden processes and ports on Linux/Unix/Windows]() Original publisher: [Read original article]() Author: Vivek Gite Published: 2024-05-07T05:05:51Z Content type: tutorial Language: en Sources: [nixCraft: Linux Tips, Hacks, Tutorials, And Ideas In Blog Format (RSS/FEED)]() Topics: [Processes](), [Linux](), [Unix](), [Malware](), [Windows](), [Kernel]() Tags: [forensic](), [linux](), [malware](), [operating-systems](), [tcp](), [udp](), [unix](), [windows]() ### AI overview A tutorial on using the Unhide and unhide-tcp forensic tools to detect hidden processes and listening TCP/UDP ports on Linux, Unix-like systems, and Windows. It covers installation across several distributions and operating systems, available detection techniques, and basic usage. ### Source excerpt Unhide is a little handy forensic tool to find hidden processes and TCP/UDP ports by rootkits / LKMs or by another hidden technique. This tool works under Linux, Unix-like system, and MS-Windows operating systems. Love this? sudo share_on: Twitter - Facebook - LinkedIn - Whatsapp - Reddit The post How to find hidden processes and ports on Linux/Unix/Windows appeared first on nixCraft. ## The origins of the Idle Scan DevFeed: [The origins of the Idle Scan]() Original publisher: [Read original article]() Published: 2023-10-19T10:40:27Z Content type: article Language: en Sources: [Antirez]() Topics: [Network](), [TCP/IP](), [Operating system](), [Tool](), [Protocol (disambiguation)]() Tags: [attacks](), [network](), [operating-systems](), [protocol](), [research](), [tcp](), [tcp-ip](), [tool](), [udp]() ### AI overview The article recounts how the Idle scan originated in 1998 through experimentation with Hping, a tool for crafting unusual TCP/IP packets. It explains that observing incrementing IP ID values revealed a universal outgoing-packet counter in operating systems, which could be used to estimate a networked computer's outgoing traffic. ### Source excerpt The Idle scan was conceived at the end of 1998, evidenced by emails. I had moved to Milan a few months prior, having been there since September if I recall correctly, brimming with new ideas, unaware that my stay in that city would be brief. I spent the summer on the beaches of Sicily, mainly occupied with reading many books recommended by the folks at Seclab (mostly by David). However, those readings needed a catalyst: the Idle scan was an attack born from theoretical rumination, but the stream of thoughts originated from a rather practical circumstance. I had recently created Hping, a tool whose logo was borrowed from that of Nutella. I mention this to emphasize the seriousness that governed my efforts at that time -- after all, I was only twenty-one and already in Northern Italy with a full-time job on my shoulders; some understanding was warranted. Hping was a Swiss Army knife for the TCP/IP protocol. Its initial use was mostly exploratory, for research. With Hping, you could assemble TCP, UDP, and ICMP packets in the most bizarre manner, and encapsulate them in equally eccentric IP packets, fragmented, with fields set to anomalous values. These packets were sent around to observe the network stack response of different operating systems. This is where Idle scan originates: playing with Hping for just a few minutes revealed a well-known yet (to me) surprising fact. The response packets had an ID field that continuously incremented by some measure. At that time, given that the attacks I would later disclose were not yet known, this ID field behavior aroused no concern. Every time an operating system emitted an IP packet, it first incremented a counter (which reset to zero once it reached the maximum value of two to the sixteenth power minus one), then the packet was sent with the ID set to the counter's value. The counter was universal for all outgoing packets. This allowed, for starters, to estimate the outgoing traffic of any networked computer. This information ## What Can You Monitor with epoll on Linux? DevFeed: [What Can You Monitor with epoll on Linux?]() Original publisher: [Read original article]() Author: Graham King Published: 2022-10-20T07:00:00Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Linux](), [Network](), [async](), [Filesystems](), [Processes](), [Streams]() Tags: [async](), [configuration](), [epoll](), [file](), [go](), [linux](), [logging](), [network](), [notifications](), [process](), [rust](), [software](), [tcp](), [tokio](), [udp](), [unix]() ### AI overview This article surveys Linux file descriptors that can be monitored with epoll, including network sockets, timers, signals, filesystem events, child processes, terminals, page faults, and seccomp notifications. It explains how these sources can be integrated into an epoll event loop or an asynchronous engine such as Go or Rust's tokio. ### Source excerpt On Linux what can you turn into a file descriptor and then monitor with epoll? ## Update on DoS Attacks against our Online Game DevFeed: [Update on DoS Attacks against our Online Game]() Original publisher: [Read original article]() Published: 2022-05-15T22:00:00Z Content type: article Language: en Sources: [Dennis Felsing]() Topics: [spoofing](), [servers](), [Open Source](), [Protocol (disambiguation)](), [client]() Tags: [attacks](), [https](), [ipv4](), [ipv6](), [open-source](), [server](), [servers](), [spoofing](), [udp]() ### AI overview This update describes ongoing DoS attacks against the open-source DDraceNetwork online game. It explains how spoofed UDP connection attempts overload single-threaded game servers and outlines an HTTPS-based IP whitelist, along with limitations involving capacity, IPv4, IPv6, and ISP address translation. ### Source excerpt In my previous post 8 months ago I described how our open source online game DDraceNetwork has been suffering under DoS attacks for about 8 years, basically since its inception. Recently the attacks have gotten much worse, forcing us to work on further approaches. Since many players made suggestions recently, I'm writing this blog post to summarize what we are attempting and to ask for help again. These traffic graphs are from two of the servers we are running, note the logarithmic x-axis. Each spike represents an incoming DoS attack, as you can see some of them last for nearly a day. Recently the attacks have been relatively weak in terms of incoming bandwidth, using spoofed IP addresses imitating our UDP-based connection process. At first the CPU gets overloaded since the server suddenly has to try and handle hundreds of thousands of connection attempts per second. Since our game servers are mostly running on cheap VPSes and each game server runs single-threaded, it is quite easy to overload a system in this manner. HTTPS-based Whitelist To prevent spoofing we collect all players' IP addresses and whitelist those. Since we also develop the game client, we can modify the client to connect to a server via HTTPs for this whitelisting. The iptables rules and ipset setup on the game servers for this whitelist look something like this: ipset create official iphash ipset create whitelist-ip iphash iptables -N serverinfo iptables -A serverinfo -m hashlimit --hashlimit-above 40/s --hashlimit-mode dstport --hashlimit-name si_dstport -j DROP iptables -N game iptables -A game -m set --match-set official src -j ACCEPT iptables -A game -m set --match-set whitelist-ip src -m u32 --u32 "38=0x67696533" -j serverinfo iptables -A game -m set --match-set whitelist-ip src -m u32 --u32 "38=0x66737464" -j serverinfo iptables -A game -m set --match-set whitelist-ip src -j ACCEPT # Still allow non-whitelisted players when there is no attack iptables -A game -m limit --limit 10000 -j ACCEP ## Troubleshooting Kubernetes Networking Issues DevFeed: [Troubleshooting Kubernetes Networking Issues]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Sasha Klizhentas) Published: 2022-04-26T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Kubernetes](), [Kubernetes networking](), [Kubernetes clusters](), [networking]() Tags: [bridge](), [firewall](), [ip](), [kernel](), [kubernetes](), [kubernetes-clusters](), [kubernetes-networking](), [modules](), [networking](), [troubleshooting](), [udp](), [vxlan]() ### AI overview Part 1 of a Kubernetes troubleshooting series focuses on networking failures, including traffic forwarding, bridge-netfilter settings, and firewall rules affecting overlay network traffic. It explains how these failures manifest and outlines ways to diagnose and fix them. ### Source excerpt Part 1 of our Troubleshooting Kubernetes series focuses on networking, listing common issues we have encountered along with easy ways to troubleshoot them. ## Flow Control in Aeron DevFeed: [Flow Control in Aeron]() Original publisher: [Read original article]() Author: Michael Barker (noreply@blogger.com) Published: 2020-03-19T22:20:00Z Content type: tutorial Language: en Sources: [Bad Concurrency]() Topics: [networking](), [Messaging](), [Protocol (disambiguation)](), [Development]() Tags: [distributed-system](), [messaging](), [multicast](), [networking](), [protocol](), [udp]() ### AI overview This article explains flow control in Aeron, focusing on sliding-window behavior over UDP. It compares Aeron's receiver status messages with TCP acknowledgements and describes how receiver-window limits help prevent senders from overrunning receivers and causing message loss. ### Source excerpt One of my more recent projects has led me to become more involved in the Aeron project. If you are unaware of Aeron, then head over to the Github site and check it out. At its core is an reliable messaging system that works over UDP, Multicast UDP and IPC. It also contains an archiving feature for recording and replay and (still under active development) an implementation of the Raft protocol for clustering. Did I mention that it was fast too. I've spent the last few weeks buried in the various strategies the Aeron has for flow control. Specifically modifying the existing flow control strategies and adding more flexible configuration on a per channel basis. Before I jump into that it would be useful to cover a little background first. What is flow control? Within a distributed system the purpose of flow control is to limit the rate of a sender so that is does not overrun it's associated receiver. UDP does not come with any form of flow control, therefore it is easy to create a sender that will out pace the receiver, leading to message loss. There are a number of different forms of flow control, but I'm going to focus on the sliding window flow control protocol used by TCP and Aeron. The sliding window protocol requires that the sender maintain a buffer of data (referred to as a window). The size of this window will typically communicated from the receiver to the sender as part of the protocol. With a bi-directional protocol like TCP the size of the window is communicated in each TCP segment header. This is the amount of data that the sender can transmit to the receiver before having to wait until an acknowledgement is received. If the application thread on the receiver side is busy and does not read the data from the socket and the sender continues to transmit, the window size value will decrease until it reaches 0, at which time the sender must stop and wait for an acknowledgement with a non-zero window size before sending again. There is a lot more networking theo ## Creating sockets DevFeed: [Creating sockets]() Original publisher: [Read original article]() Author: Marek Published: 2019-11-05T23:00:00Z Content type: tutorial Language: en Sources: [Marek Majkowski]() Topics: [Linux](), [networking](), [API](), [Unix](), [Internet]() Tags: [api](), [domain](), [ipv4](), [ipv6](), [linux](), [networking](), [tcp](), [udp](), [unix]() ### AI overview A tutorial on creating sockets on Linux. It explains the socket syscall's domain, type, and protocol arguments, then introduces IPv4, IPv6, and Unix sockets, including when AF_UNIX is appropriate for communication between processes on the same host. ### Source excerpt Creating sockets Articles from this series: - Creating sockets on Linux. - Addressing of AF_INET, AF_INET6 and AF_UNIX sockets. Our journey into the Linux networking API starts with the common syscall: It takes three arguments: - domain specifies an address family. Most commonly used are IPv4, IPv6 and Unix sockets - AF_INET, AF_INET6 and AF_UNIX families. Linux supports more families, notably AF_PACKET, AF_NETLINK, AF_ALG and AF_VSOCK are sometimes handy. ## Anycast Routing for TCP Services: Benefits and Deployment Challenges DevFeed: [Anycast Routing for TCP Services: Benefits and Deployment Challenges]() Original publisher: [Read original article]() Author: ben@benjojo.co.uk Published: 2017-07-20T16:13:30Z Content type: article Language: en Sources: [benjojo blog]() Topics: [networking](), [BGP](), [Load Balancing](), [reliability](), [Cloudflare](), [HTTP]() Tags: [bgp](), [cloudflare](), [dns](), [ipv6](), [load-balancing](), [networking](), [tcp](), [udp]() ### AI overview The article explains how anycast routing extends beyond UDP services such as DNS to TCP applications, including HTTP and games. It compares anycast with GeoDNS, describing potential performance, reliability, load-balancing, failover, and traffic-distribution benefits, while noting deployment challenges involving routing behavior and BGP traffic engineering. ### Source excerpt IPv6 anycast possibly done better Anycasting IP space has become quite a meme in the networking world in the last few years, with it being used sparsely in the past for UDP based services like DNS. Now it's being used for TCP based services too, ## Google SoC lwIP Conclusion DevFeed: [Google SoC lwIP Conclusion]() Original publisher: [Read original article]() Published: 2016-08-23T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [lwIP](), [TCP/IP](), [Operating system]() Tags: [c](), [conclusion](), [free](), [google](), [kernel](), [lwip](), [open-source](), [os](), [react](), [reactos](), [tcp-ip](), [threading](), [udp](), [win32](), [winapi]() ### AI overview A Google Summer of Code participant reports on developing TCP and UDP support for ReactOS using lwIP. The project did not achieve full browser support or a Windows Server 2003 driver replacement, but produced a fairly robust TCP/IP driver for C console applications using TCP and UDP sockets, with extensive testing on loopback. ### Source excerpt My Google Summer of Code project proposal stated that I would add TCP support to the network branch of ReactOS, which sought to integrate lwIP 1.4.1 as the protocol level network driver for the operating system, to ultimately be tested by replacing the network driver in an installation of Windows Server 2003 with my driver. The full proposal can be found here. At the time of my proposal, I underestimated the amount of effort a fully working network driver would take. ## Google SoC lwIP Report Week 13 DevFeed: [Google SoC lwIP Report Week 13]() Original publisher: [Read original article]() Published: 2016-08-22T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [lwIP](), [C](), [Network](), [Firefox]() Tags: [bugs](), [c](), [driver](), [firefox](), [free](), [google](), [lwip](), [network](), [open-source](), [os](), [react](), [reactos](), [report](), [tcp](), [threads](), [udp](), [win32](), [winapi]() ### AI overview A final-week Google Summer of Code report describes fixes to lwIP driver issues involving TCP port freeing, IRP cancellation, multithreaded tests, and restored UDP support. TCP became mostly usable for simple network C programs, but missing TDI_QUERY_INFORMATION support prevented full web-browser support. ### Source excerpt In this final week, I tried to do as much as possible to get my driver to some sort of usable state for simple network C programs. My first task this week was to fix a problem with port freeing. When a TCP connection dies, its lwIP PCB would sometimes remain, preventing new sockets from binding to the ports they are taking up. After a lot of tracing, I discovered that an lwIP internal semantic was at play. ## Google SoC lwIP Report Week 4 DevFeed: [Google SoC lwIP Report Week 4]() Original publisher: [Read original article]() Published: 2016-06-18T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [lwIP](), [ReactOS](), [Code](), [Data structures](), [Server](), [client]() Tags: [client](), [code](), [data-structure](), [free](), [google](), [lwip](), [open-source](), [os](), [react](), [reactos](), [server](), [tcp](), [udp](), [win32](), [winapi]() ### AI overview A week-four Google Summer of Code report describes work on ReactOS's lwIP integration. The author investigated TDI connection contexts and backlog support, introduced TCP_CONTEXT storage for TCP connections, fixed pending IRQ cancellation, merged code into a branch based on trunk, and implemented TDI_SEND and TDI_RECEIVE IRQs, though the text ends before confirming completion. ### Source excerpt This week, I started off chasing down how to handle TDI sending a new IRQ to create a connection context immediately after a connection has been accepted on the server end. At first, I thought it was for socket multiplexing. As I talked more with Art and looked more into the lwIP source code, I realized that this is an attempt by TDI to support backlogging. As such, this was not something I had to actively handle since lwIP has full backlogging support. ## Go and structured logging with ElasticSearch DevFeed: [Go and structured logging with ElasticSearch]() Original publisher: [Read original article]() Author: sasha@goteleport.com (Sasha Klizhentas) Published: 2016-01-01T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Logging](), [log management](), [Go Language](), [elasticsearch](), [kibana](), [Docker]() Tags: [beats](), [docker](), [elasticsearch](), [format](), [framework](), [go](), [kibana](), [logging](), [udp]() ### AI overview This tutorial describes an experiment that uses Go, logrus, and Elastic Beats to emit structured logs over UDP and ship them to Elasticsearch. It also covers running Elasticsearch and Kibana with Docker and configuring the document schema and mappings. ### Source excerpt We are playing with Elastic Beats, doing structured logging with Golang and Elastic Search ## Don't use the CAP theorem for packet losses DevFeed: [Don't use the CAP theorem for packet losses]() Original publisher: [Read original article]() Author: Nicolas Liochon (noreply@blogger.com) Published: 2015-03-18T15:16:00Z Content type: article Language: en Sources: [Nicolas Liochon]() Topics: [CAP theorem](), [consistency](), [Networks](), [Protocol (disambiguation)]() Tags: [acid](), [availability](), [cap-theorem](), [consistency](), [database](), [distributed-system](), [durability](), [ip](), [latency](), [messages](), [network](), [networks](), [partition](), [protocol](), [tcp](), [theory](), [udp]() ### AI overview The article explains why ordinary packet loss on IP networks should not automatically be treated as a CAP theorem partition. It distinguishes congestion-related packet loss from the arbitrary message loss assumed by the CAP model and discusses how TCP responds to congestion. ### Source excerpt In the previous post, we looked at this common saying: "nodes fail, network packets get lost, partitions happen so you need to use CAP to understand your trade-offs." We saw that node failures were not partitions. What about packet losses? Most distributed applications use TCP or UDP on top of IP, and it is well known that IP is an asynchronous protocol and that it can lose packets. So should we use all the results from the theory of asynchronous networks? Must we use CAP to do some trade-offs if we are using a network that can drop packets? The answer is no. The root issue lies in the incompleteness of our description of IP. "IP is an asynchronous protocol and it can lose packets" is true, but incomplete, and this incompleteness is misleading. Let's discuss why. CAP - The usual reminder CAP says that a distributed system cannot be Consistent, Available and Partition tolerant. We use here the definitions from the proof [C2]. Consistent is: [C2] "Atomic, linearizable, consistency [...]. There must exist a total order on all operations such that each operation looks as if it were completed at a single instant. This is equivalent to requiring requests of the distributed shared memory to act as if they were executing on a single node, responding to operations one at a time." Available is: [C2] "For a distributed system to be continuously available, every request received by a non-failing node in the system must result in a response." Partition is: [C2] "The network will be allowed to lose arbitrarily many messages sent from one node to another. When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost." How can you lose packets on a network Packet loss happens when a network equipment receives more messages that it can send. Losing packets is common on an IP network. A TCP connection tries to use most of the bandwidth available. It sends nearly as many packets as it can, until it loses some. Losi ## Websockets Are Not Magical DevFeed: [Websockets Are Not Magical]() Original publisher: [Read original article]() Published: 2015-03-01T00:00:00Z Content type: opinion Language: en Sources: [Tim Kellogg]() Topics: [WebSocket](), [Internet of things](), [Protocol (disambiguation)](), [Art-Net]() Tags: [internet-of-things](), [misconceptions](), [protocol](), [tcp](), [udp](), [websockets]() ### AI overview This commentary examines misconceptions about WebSockets, especially their use in the Internet of Things. It explains that WebSockets add framing overhead, are message-oriented, and provide TCP delivery guarantees and congestion control while avoiding TCP's stream orientation. ### Source excerpt A couple months ago I was talking to a high-ranking engineer from an embedded RTOS vendor. He was insisting that websockets are going to be one of the most important standards for the Internet of Things. Unfortunately, the conversation was cut short too soon for me to get a better understanding of his reasons. [Next page]()