Francis, I'm all for protocol layering and if features can be implemented in a subprotocol, then they probably should be. However, we don't want to force subprotocols into having to re-implement TCP with timeouts, keep-alives, acks etc. if a few simple features in the base protocol can expose more of TCP/IP's capabilities to the layered protocol. In the case of orderly close, a layered protocol could implement its own orderly close. But it would still have a problem with error closes, as the servers response to all sorts of issues is simply to close the socket. If my layered protocol does: websocket.send(moderatelyLargeMessage) and then receives a onclose callback before any acks or orderly close are received, then the layered protocol knows there has been a failure, but does not know the cause. So it will probably open another connection and send the moderatelyLargeMessage again.... and again... and again.... If it new that the message was being rejected by the other endpoint rather than a network failure, then it would know not to retry. The same problem goes if the user opens too many tabs and exceeds some connection limit on the server. The sub protocol will be unable to tell the difference between that and network failure. TCP is a reliable transport, but if a layered protocol is unable to see the difference between an orderly close, and error close and a network failure, then it cannot use TCP reliably. If I do a websocket.send(message) and then a short time later I get a websocket.onclose() call back, then I have no idea if that message was delivered. So websockets is obscuring the reliable capabilities of TCP. As I've said before, it's more like webserialport than websocket and subprotocols will need to be more complex as a result. regards Francis Brosnan Blazquez wrote: > Hi Greg, > >> TCP does have difference between an orderly shutdown (FIN), >> error shutdown (RST) and timeouts. >> >> So if you want to be like TCP, then you'll have those >> concepts. > > Why not? > > I think people is interested on Websocket because they will layer its > favourite protocol on top of it. I not stating I'm against this but I > still don't see this point and how it would improve the protocol... > > In other words, people that cares about orderly close will use a > protocol on top of Websocket that provides graceful close (like BEEP) > and people that do not cares about this will have an additional feature > not requested....so it looks to me both kind of users won't use this.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.