Insight Vault

Final Decision Model: Choose the Protocol by Conversation Shape

2 min read

Learning Question

How should protocol choices be made once connection and protocol semantics are separated?

Choose the protocol by the conversation shape, not by a vague desire for “real time” or “an open connection.” The right question is what messages need to exist, who sends them, how long the exchange stays active, whether objects should be cacheable, and what reliability or recovery rules the application needs.

Conversation Shapes

Use these distinctions:

ordinary request-response
-> HTTP request and response
 
large upload or download
-> one HTTP message with a body that can be transferred progressively
 
server-to-client event stream
-> SSE or HTTP streaming
 
bidirectional application messages
-> WebSocket
 
large-scale video playback
-> HLS or DASH over HTTP segments
 
low-latency two-way media
-> WebRTC or another real-time media stack

The lower connection may stay open in several of these cases. That does not make them equivalent.

Diagnostic Questions

When choosing or debugging a protocol, ask:

  1. Is the interaction mostly request-response?
  2. Does the server need to push updates without repeated client requests?
  3. Does the client also need to send frequent messages on the same channel?
  4. Are messages independent cacheable objects?
  5. Is the data a long body of one message or many separate messages?
  6. Can stale cached data be reused safely?
  7. What happens when the connection drops?
  8. Does the application need persistence, replay, ordering, or deduplication above the protocol?

Common Corrections

Keep these corrections available:

Many TCP segments do not mean many HTTP requests.
One open TCP connection does not mean WebSocket semantics.
SSE is not multiple completed HTTP responses.
WebSocket does not provide offline delivery or message persistence.
Video streaming is often many cacheable HTTP segment requests, not one endless server push.

Final Summary

Connections move bytes. Protocols define conversations. Applications assign business meaning and recovery rules.

The durable model is:

connection capability
-> protocol message boundaries
-> conversation direction and lifetime
-> caching and delivery assumptions
-> application state and recovery

Once those layers are separate, HTTP, SSE, WebSocket, HLS, DASH, and WebRTC stop competing as vague “ways to send data” and become tools for different conversation shapes.

Backlinks

Graph View