https://blog.yusukeikoma.com/tags/websocket/Recent content in websocket on Ikoma's BlogHugoen-usTue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/Tue, 22 Sep 2026 13:39:45 +0900https://blog.yusukeikoma.com/posts/durable-objects-websocket-hibernation/Cloudflare’s docs say hibernation keeps WebSocket connections open and discards in-memory state. This post runs a small Durable Object under local workerd and watches exactly what that means: the socket stays OPEN, the constructor runs again on the next message, class fields reset, attachments survive only if you serialize them, and a pending timer or the standard WebSocket API quietly turns hibernation off. Production behaviour and billing are not tested.https://blog.yusukeikoma.com/posts/mobile-os-background-sockets/Sat, 12 Sep 2026 14:18:24 +0900https://blog.yusukeikoma.com/posts/mobile-os-background-sockets/Apple’s and Android’s own documentation say a backgrounded app can be suspended, its network access deferred, and its existing connections closed. So when your app comes back, readyState === OPEN is only a memory of the last event, not a measurement. This post derives a small foreground routine (probe, rebuild, catch up) from those documented rules, runs it against a frozen-process stand-in on Linux, and is explicit about what no device was used to check.https://blog.yusukeikoma.com/posts/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/posts/websocket-origin-check-is-not-authentication/The Origin header on a WebSocket handshake is set by browsers and can be set to anything by every other client. So an allow-list protects a cookie-authenticated browser session from other sites, and it proves nothing about who is connecting. A runnable server, a real headless-browser attack, and the handshake rule that follows.https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/Sun, 06 Sep 2026 20:54:24 +0900https://blog.yusukeikoma.com/posts/websocket-bufferedamount-backpressure/WebSocket send() never waits, and bufferedAmount only sees the part of the path that is in your own process. In a small lab, a sender that politely waited for bufferedAmount to drain still let a slow consumer queue nearly all 400 messages in its own memory, while a credit window of 8 kept the backlog at 8. This post goes through four common beliefs about send(), bufferedAmount, message size and backpressure, tests each one, and ends with a table for choosing between them.https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/Fri, 21 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/After the 101 response, no request carries credentials: the server remembers a verdict, not the evidence. This article follows one token through a browser handshake, shows what a page can and cannot see, and compares three ways to renew it (reconnect, in-band, out-of-band) with a runnable server, tests, and a headless-Chrome check.https://blog.yusukeikoma.com/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/Thu, 20 Aug 2026 18:03:49 +0900https://blog.yusukeikoma.com/posts/replace-polling-with-subscriptions-keep-poll-as-fallback/How a mobile client moved from timer-driven polling to shared change subscriptions over a per-message-billed relay. The subtle part is not the stream. It is deciding honestly when the fallback poll may stand down.https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/Wed, 19 Aug 2026 12:47:53 +0900https://blog.yusukeikoma.com/posts/batching-and-bounded-frames-on-a-metered-relay/When every WebSocket message costs money and every frame has a hard cap, you need batching with independent flush triggers, a single-frame threshold below the cap, bounded chunking, and capability flags that survive mixed-version rollouts. The sharp edges are ordering on shutdown and a zero value that disappears from the wire.https://blog.yusukeikoma.com/posts/liveness-without-pings-and-idle-sleep/Tue, 18 Aug 2026 22:41:09 +0900https://blog.yusukeikoma.com/posts/liveness-without-pings-and-idle-sleep/A fixed-interval keepalive costs a message in each direction even when the connection is busy. Treating every inbound frame as proof of life, probing only quiet connections, and letting an existing heartbeat tell an idle host when to disconnect removes most of that traffic, at the price of a bounded wake-up delay.https://blog.yusukeikoma.com/posts/when-the-close-event-never-comes/Mon, 17 Aug 2026 17:27:04 +0900https://blog.yusukeikoma.com/posts/when-the-close-event-never-comes/A client that waits for its own socket’s close event before cleaning up can stall silently when that event never arrives. Settle your state when you decide to end the connection, make the cleanup idempotent, and keep the event for closes you did not start.