<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>sockets on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/ja/tags/sockets/</link><description>Recent content in sockets on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Mon, 05 Oct 2026 13:20:23 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/sockets/index.xml" rel="self" type="application/rss+xml"/><item><title>UDPのconnect()は何も送らず、getsockname()で自分のIPが分かる</title><link>https://blog.yusukeikoma.com/ja/posts/udp-connect-local-ip/</link><pubDate>Mon, 05 Oct 2026 13:20:23 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/udp-connect-local-ip/</guid><description>Wi-Fi、VPN、コンテナのブリッジがあるマシンにはアドレスが複数あり、ホスト名の解決では間違ったものが返ることがあります。UDPソケットを宛先にconnectすると、カーネルがその宛先に使う送信元アドレスを決め、getsockname()でパケットを1つも送らずに読み出せます。Linuxで3つのインターフェースを使って確かめ、5つの宛先に対して5つの答えが得られ、IPv4とARPのフレームは流れませんでした。</description></item><item><title>systemdの再起動中、ソケットアクティベーションなら接続は拒否されず、待たされる</title><link>https://blog.yusukeikoma.com/ja/posts/replace-running-daemon-without-downtime/</link><pubDate>Sat, 03 Oct 2026 18:08:27 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/replace-running-daemon-without-downtime/</guid><description>稼働中のデーモンをリクエストを落とさずに入れ替える手順書です。小さなTCPサーバーを本物のsystemdで動かして試しました。単純なrestartは毎回、接続の拒否かリセットを起こしました。SO_REUSEPORTで新旧を並べる方法は拒否ゼロでしたが、一部の回でリセットが出て、カーネルの設定でそれが消えました。ソケットアクティベーションはエラーなしでした。処理中リクエストのドレインとTimeoutStopSecの関係、新バージョンを確認して巻き戻すリリース切り替えも扱います。</description></item><item><title>write() を2回呼ぶだけで、TCPが40ms止まる</title><link>https://blog.yusukeikoma.com/ja/posts/two-small-writes-nagle-delayed-ack/</link><pubDate>Tue, 01 Sep 2026 20:56:28 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/two-small-writes-nagle-delayed-ack/</guid><description>ヘッダーと本文を小さな write() 2回に分けて送り、返事を待つと、CPUもネットワークも空いているのに、1往復ごとに約40ms止まることがあります。Nagleアルゴリズムも遅延ACKも、単体では正しい仕様です。2つが組み合わさると、タイマーが切れるまで互いに待ち合ってしまいます。この記事では、停止を予想し、50行のスクリプトで再現し、パケットトレースで確かめ、4つの対処を比べます。</description></item><item><title>エッジトリガーのepollは部分読みで止まる。イベント配信も、同じ理由で壊れる</title><link>https://blog.yusukeikoma.com/ja/posts/level-triggered-invalidation/</link><pubDate>Tue, 25 Aug 2026 17:33:01 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/level-triggered-invalidation/</guid><description>epoll のエッジトリガーは部分的に読むと止まりますが、レベルトリガーは止まりません。同じ違いが、イベントの喪失・重複・順序入れ替えに耐えられるかを分けます。再現できる epoll の実験、損失のあるチャネル上での5通りのシミュレーション、そして見落とされがちな競合(再取得の最中に届いたイベント)を扱う40行ほどの invalidator を紹介します。</description></item></channel></rss>