Challenge 3: Explain an Interoperability Failure — Possible Solution
====================================================================

THE SCENARIO
-------------
A Python service using a plain WebSocket client library (e.g. Python's
"websockets" package) tries to connect directly to a Socket.IO server,
and the connection doesn't behave correctly.

WHY THIS HAPPENS
-----------------
A Socket.IO server is not simply "a WebSocket server" — it's built on top
of Engine.IO, which layers its OWN handshake and message-framing protocol
on top of the underlying WebSocket (or long-polling) transport described
in Chapter 2. Concretely:

- Even the initial connection isn't a plain WebSocket handshake — Socket.IO
  typically starts with an Engine.IO-specific HTTP handshake (often over
  long-polling first) that negotiates a session ID and transport, THEN
  upgrades to WebSocket if available. A plain WebSocket client that just
  opens "ws://server/socket.io/" and expects a normal Chapter 2 handshake
  may get a response it doesn't know how to interpret, since Socket.IO's
  server expects its own specific connection sequence, not a bare
  WebSocket connection request.

- Even once a WebSocket connection IS established, every message
  Socket.IO sends is wrapped in its own framing — a small prefix
  indicating the Engine.IO packet type (open, message, ping, pong, etc.)
  and, within "message" packets, further Socket.IO-specific framing
  indicating the event name and acknowledgement ID. A plain WebSocket
  client receives these as opaque text/binary frames and has no built-in
  understanding of what any of those extra characters mean — it would see
  garbled-looking data rather than clean event payloads.

- The reverse is equally true: a Socket.IO CLIENT talking to a plain "ws"
  server (like the one built in Chapter 3) would send Engine.IO-framed
  handshake/message packets that the raw ws server has no idea how to
  parse — it would just see unexpected-looking text/binary data on
  "message" events, with no built-in concept of "rooms," "acks," or
  "events" the way Socket.IO expects the other end to understand.

THE FIX
--------
Either replace the Python service with an actual Socket.IO client library
(several exist for Python, e.g. "python-socketio"), which correctly
speaks the same Engine.IO/Socket.IO protocol layers, OR change the server
side to use raw ws instead of Socket.IO if broad cross-language/cross-
library interoperability with non-Socket.IO clients is a real
requirement — which is exactly the "raw ws wins" scenario this chapter
describes for services that need to be reachable by arbitrary WebSocket
clients, not just other Socket.IO instances.