WebSocket API Review

I went through the WebSocket API and wrote down my thoughts. Nothing too earth-shattering, just some ideas.

1. How should WebSockets interact with the Dispatcher? In particular should open web sockets count towards maxRequestsPerHost ? (I think yes, but we should explicitly call this out.)
2. When can I cancel a WebSocketCall? Once it’s open is that equivalent to calling WebSocket#close() ?
3. Does isCanceled() return true after a WebSocket is closed?
4. Do we throw an IllegalStateException if you write the socket in onOpen() ? What about sendPing() and close() ? #2905
5. It looks like pings and the corresponding pongs are very loosely coupled. Any idea how strict the spec is? Seems weird to call out that pongs can come unsolicited. I’m really unsure about what to do with pings and pongs. My first instinct is to hide them from the API and instead offer something to send pings automatically for you on a schedule
6. I wonder if there’s a better name for WebSocketListener. With Call we have Callback and the names are cute. Is WebSocketCallback terrible?
7. An obnoxious idea – would it ever make sense to combine the WebSocketCall and WebSocket types? I’m getting here via the (slight) redundancy between cancel() and close(). Obviously sendMessage() would need to be a bit more clever to do something reasonable if it were invoked before onOpen() is received. Though it’s interesting to think about “fast open” where a web socket client can enqueue messages before we have confirmation that it’s all going to connect.
8. Should it be sendMessage(RequestBody) or just send(RequestBody) or just message(RequestMessage) ? Maybe instead of sendPing(ByteString) it should be just ping(ByteString) or even ping() ? #2904

[gengjiawen]

For 5: I would like to expose the ping pong api.Because this is very helpful to keep your websocket connected and reconnect when meet with network issue or something else.The WebSocketListener onClose method isn’t reliable in practice.

[swankjesse]

I propose we always fully buffer WebSocket messages. The consequences:

• A listener that receives onMessage() can return immediately without reading the response body. The ResponseBody the caller holds is buffered!
• A writer never blocks writing a message. It’s merely enqueued to be written later, with some limit on how many bytes or messages can be enqueued concurrently.

I’m proposing this behavior even though I know it’s weird. The reason is that message receipts are the application layer’s concern. If the client sends something that’s intended to be durable, the client already needs to hold that thing until a receipt is received. Blocking until the bytes have been written to the socket doesn’t confirm anything.