<?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>realtime on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/ja/tags/realtime/</link><description>Recent content in realtime on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Sat, 19 Sep 2026 21:10:16 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/realtime/index.xml" rel="self" type="application/rss+xml"/><item><title>APNs が保持する通知は1アプリ1件だけなので、プッシュはヒントとして設計する</title><link>https://blog.yusukeikoma.com/ja/posts/push-notifications-are-hints-apns-stores-one/</link><pubDate>Sat, 19 Sep 2026 21:10:16 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/push-notifications-are-hints-apns-stores-one/</guid><description>端末がオフラインのとき、アプリが終了されたとき、送信が多すぎるときにプッシュがどうなるかを、AppleとGoogleは文書で説明しています。通知は置き換えられ、捨てられ、順序が入れ替わり、遅れます。文書に書かれた失敗モードの表と、ペイロードを適用するクライアントが収束せず、カーソルから取得するクライアントが収束することを示す小さなシミュレーションを紹介します。</description></item><item><title>bufferedAmountを待っても守れるのは送信側だけで、遅い受信側は守れない</title><link>https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/</link><pubDate>Sun, 06 Sep 2026 20:54:24 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/websocket-bufferedamount-backpressure/</guid><description>WebSocketのsend()は待ってくれず、bufferedAmountが見ているのは自分のプロセスの中の待ち行列だけです。小さな実験では、bufferedAmountが減るのを待ってから送る送信側でも、受信側のメモリには、400件のほぼ全部が溜まりました。受信側が処理済みを返す「クレジット窓」(8件)なら、溜まるのは8件で止まりました。send()、bufferedAmount、メッセージサイズ、バックプレッシャーについてよくある4つの思い込みを実際に試し、使い分けの表にまとめます。</description></item><item><title>カーソル・有限ログ・スナップショットで、再接続したイベントストリームを再開する</title><link>https://blog.yusukeikoma.com/ja/posts/resumable-streams-cursors-last-event-id-snapshots/</link><pubDate>Fri, 04 Sep 2026 19:26:37 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/resumable-streams-cursors-last-event-id-snapshots/</guid><description>再接続したクライアントが、状態を取りこぼさず、重複せず、履歴を読み直さずに追いつく方法を、「全部読み直す」から「上限つきのログとスナップショットのフォールバック」まで、版0から版4まで段階的に組み立てます。ブラウザの EventSource が再接続時と non-200 応答のときに実際に何をするか、スナップショットの順序のバグ、決定木も扱います。</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><item><title>ポーリングを変更通知の購読に置き換え、保険として残す</title><link>https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</link><pubDate>Thu, 20 Aug 2026 18:03:49 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/</guid><description>メッセージ単位で課金されるリレー越しに、モバイルクライアントがタイマー駆動のポーリングから共有の変更通知へ移った経緯を扱います。難しいのはストリームそのものではなく、保険のポーリングをいつ止めてよいかを正直に決めることです。</description></item><item><title>共同編集の実体と残す保存を分ける</title><link>https://blog.yusukeikoma.com/ja/posts/live-document-and-saved-copy/</link><pubDate>Thu, 13 Aug 2026 10:14:09 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/live-document-and-saved-copy/</guid><description>共同編集の文書同期とスナップショット保存を分離し、初回同期前の空の文書による上書きを防ぐ設計を説明します。</description></item></channel></rss>