<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>UDP on Skycoin Blog</title><link>https://blog.theskywirenetwork.net/tags/udp/</link><description>Recent content in UDP on Skycoin Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 15 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.theskywirenetwork.net/tags/udp/index.xml" rel="self" type="application/rss+xml"/><item><title>Faithful UDP-Over-Skynet</title><link>https://blog.theskywirenetwork.net/posts/faithful-udp-over-skynet/</link><pubDate>Fri, 15 May 2026 00:00:00 +0000</pubDate><guid>https://blog.theskywirenetwork.net/posts/faithful-udp-over-skynet/</guid><description>&lt;p&gt;Skywire has always carried TCP traffic well. Route groups are reliable, ordered, head-of-line-blocked on packet loss — exactly the contract &lt;code&gt;net.Conn&lt;/code&gt; callers expect. That&amp;rsquo;s the right shape for HTTP, SSH, raw TCP forwarding, and almost everything else apps reach for by default.&lt;/p&gt;
&lt;p&gt;But real-world UDP applications — DNS, NTP, VoIP, gaming, QUIC, anything that has its own loss-tolerance built in — treat &lt;strong&gt;late packets as worse than lost packets&lt;/strong&gt;. A DNS resolver that retries after 100ms doesn&amp;rsquo;t want the original response to arrive 5 seconds later through a TCP-shaped tunnel. A VoIP codec that masks 20ms of lost audio doesn&amp;rsquo;t want all subsequent audio to wait while the lost packet retransmits. A gaming engine doesn&amp;rsquo;t want the world-state update from a frame ago — it wants the current update or nothing.&lt;/p&gt;</description></item></channel></rss>