Binary Data and Streams

Analogy categoryAnalogies

Sending Binary Data over Socket.IO

Socket.IO natively supports binary data as part of any emitted payload — you can include a Node.js Buffer, an ArrayBuffer, or a Blob directly inside an object passed to socket.emit(), and the underlying engine.io transport (WebSocket when available, or an XHR-based fallback) automatically detects and serializes the binary parts separately from the JSON-encodable parts of the payload, then reassembles them correctly on the receiving side. This means you don't need to manually base64-encode binary data (which would bloat payload size by roughly 33%) — Socket.IO's binary-parser handles the split transparently using placeholder references internally.

🏏

Cricket analogy: It's like a broadcast feed sending the raw video stream (binary) on one channel while sending the scorecard overlay (JSON) on a separate metadata channel, combined seamlessly on your TV rather than embedding video as text.

javascript

// Server: emit a Buffer directly alongside JSON metadata
fs.readFile('report.pdf', (err, fileBuffer) => {
  socket.emit('file-ready', {
    filename: 'report.pdf',
    mimeType: 'application/pdf',
    data: fileBuffer // Buffer is transmitted as binary, not base64
  });
});

// Client: receive and reconstruct the binary payload
socket.on('file-ready', ({ filename, mimeType, data }) => {
  const blob = new Blob([data], { type: mimeType });
  const url = URL.createObjectURL(blob);
  downloadLink.href = url;
  downloadLink.download = filename;
});

Buffers, ArrayBuffers, and Blobs

On the Node.js server side, binary data is typically handled as a Buffer, while browser clients naturally work with ArrayBuffer or Blob objects; Socket.IO's client automatically converts incoming binary data to ArrayBuffer by default (configurable via socket.io(url, { ... }) parser options is not standard, but you can convert an ArrayBuffer to a Blob manually with new Blob([arrayBuffer])). It's important to know that Blobs are not directly serializable as socket.emit arguments in the same transparent way ArrayBuffers and Buffers are in all Socket.IO client versions — check your client version's binary support, and prefer ArrayBuffer on the browser side for maximum compatibility across transports.

🏏

Cricket analogy: It's like different broadcasters handling the same raw satellite feed differently — one production truck (Node Buffer) processes it one way, while the studio's playback system (browser ArrayBuffer) expects a slightly different container format.

Streaming Large Files in Chunks

Because Socket.IO messages (and the underlying WebSocket frames) are not designed for arbitrarily huge single payloads, large files should be split into smaller chunks — commonly 16KB to 256KB per chunk — and emitted sequentially with sequence metadata (chunkIndex, totalChunks, fileId) so the receiver can reassemble them in order and detect any missing pieces. Using acknowledgement callbacks (socket.emit('chunk', data, callback)) for each chunk lets the sender implement basic backpressure by waiting for the previous chunk's ack before sending the next, preventing memory buildup on slow connections rather than firing all chunks at once.

🏏

Cricket analogy: It's like a stadium delivering ball-by-ball commentary updates instead of one giant end-of-match report, each update tagged with over and ball number so viewers can reconstruct the innings in order.

Never emit an entire multi-gigabyte file as a single Socket.IO payload — it will spike server memory (the whole Buffer must be held in memory), risk exceeding maxHttpBufferSize (default 1MB, configurable on the server), and block the event loop while serializing. Always chunk large transfers and consider a dedicated HTTP endpoint or object storage (e.g., S3 pre-signed URLs) for genuinely large file uploads/downloads instead of routing them through the WebSocket connection.

Socket.IO automatically detects and transmits Buffers, ArrayBuffers, and Blobs as true binary, avoiding costly base64 encoding overhead.
Node.js servers typically use Buffer; browsers typically work with ArrayBuffer, which you can wrap into a Blob when needed.
Large files should be split into sequential chunks (e.g., 16KB-256KB) tagged with chunkIndex and totalChunks for reassembly.
Acknowledgement callbacks per chunk enable simple backpressure, preventing the sender from overwhelming a slow receiver.
The server's maxHttpBufferSize option (default 1MB) caps payload size and should inform your chunk sizing decisions.
For genuinely large files, prefer a dedicated HTTP endpoint or object storage over routing everything through WebSocket frames.
Reassembly on the receiving end must handle out-of-order or missing chunks gracefully, especially over unreliable networks.