Subject: [hybi] WS is not a request-response protocol (which would make things easier)

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 20:48:54 +0200

Hi, probably is TOO late for this comment:

WebSocket protocol is not based on request-response, but just on
"message". This makes things difficult as we've observed in some
recent threads:

- How to reject a message because frame size is too big?

- A Pong requires same body as the Ping (is it really the most
efficient way to match a "response" with a previous request??).

Now imagine that WS is frame-request/frame-response based and each
frame contains a "msg_id" or just "id" field (as I've suggested in
other mail), so:

1)
- Endpoint A sends a frame request (FIN=1, opcode=1, id=aiusdy87).
- Endpoint B replies a 200 code in a frame response (a simple frame
with id=aiusdy87 and code=200, no more).

Endpoint A knows that the remote has received the frame.

2)
- Endpoint A sends a frame request (FIN=1, opcode=1, id=qweqwe) *very* big.
- Endpoint B does not accept so long frame so replies a 485 (or
whatever) code in a frame response (a simple frame with id=aiusdy87
and status=485, and optionally a "reason" text field).

3)
- Endpoint A sends a Ping (FIN=1, opcode=8, id=asdasd) with *any* payload data.
- Endpoing B replies 200 (id=asdasd, code=200) and that's all.

Advantages:

- Implicit multiplexation (thanks to "id" field) which allows varios
frames (fragments of different messages) being sent in parallel.
- The client can know the rejection reason of a specific request
(instead of receiving a close connection control frame).
- Extensible: extensions can use request-response control frames to
re-negotiate during an established WS session.

Too late for this? Sure, I know XD

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Mon, 15 Aug 2011 15:26:13 -0400

That is a well thought-out and comprehensive analysis.    However, I am
against this in the strongest possible terms.

Websockets is an asynchronous protocol.   Introducing any
request/response mechanisms introduces synchronicity and defeats one of the
fundamental design goals of WS.

Reliable delivery is provided by TCP.    WS has no need to confirm delivery.

Message processing failure and any requirements by the application layer to
synchronize or  verify handling by the counter-party are the responsibility
of the application(s), not of WS.

On Mon, Aug 15, 2011 at 2:48 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 21:42:25 +0200

> fundamental design goals of WS.

I don't think it breaks so much, or at least it's not so bad. Why?
most of the protocols work in such a way.

> Reliable delivery is provided by TCP.

Not true in presence of intermediary proxies, right?

> WS has no need to confirm delivery.

Why not? what about my examples?

> of the application(s), not of WS.

I just don't agree. Confirming the receipt of a response at transport
level is fully legitimate.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 21:45:38 +0200

> level is fully legitimate.

Sorry, I mean "Confirming the receipt of a request at transport level
is fully legitimate"

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: David Endicott <[email-masked]>
Date: Mon, 15 Aug 2011 15:58:59 -0400

> most of the protocols work in such a way.

Most protocols in widespread use are synchronous.    Notable exceptions are
those based on UDP.      It breaks everything because it's a different
paradigm.

> Not true in presence of intermediary proxies, right?

Wrong.   TCP is a reliable transport protocol.    Intermediary proxies
messing things up is not a problem with TCP, it's a problem with the
infrastructure and is comparable to router failure, cable breaks, alien
intervention, etc.

> Why not? what about my examples?

Because TCP is a reliable transport and we know that frames will arrive or
our connection is lost.

> level is fully legitimate.

TCP "confirms receipt" (actually adjusts transport window, but same idea) of
the IP frames. And that is how TCP implements "reliable delivery" over
"unreliable" IP.     Since WS builds on TCP, we do not need to reinvent the
wheel and provide reliable transport.

Defining a request/response mechanism and confirming receipt of response is
the responsibility of an application protocol.   And you just re-invented
HTTP.

WS is asynchronous.    If the application using WS wants to implement a
request/response model, they are free to do so, but that should not be part
of the base WS protocol.

Asynchrony is a fundamental design goal of WebSockets.   This is also
reflected by the event-driven nature of the Javascript client
implementation.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 22:12:02 +0200

> infrastructure and is comparable to router failure, cable breaks, alien

I don't agree at all. TCP is a end-to-end protocol just in case
intermediaries are IP routers. But when the intermediary is an HTTP
proxy then there are two TCP connections (from client to HTTP proxy,
and from HTTP proxy to the server).

> Because TCP is a reliable transport and we know that frames will arrive or

Same argument as above.

> reflected by the event-driven nature of the Javascript client

Again, I don't see how a request-response protocol cannot be
event-driven. Of course it can be.

-- 
Iñaki Baz Castillo
<[email-masked]>