On Feb 1, 2010, at 4:58 PM, Ian Hickson wrote: > On Mon, 1 Feb 2010, Maciej Stachowiak wrote: >> On Feb 1, 2010, at 4:00 PM, Ian Hickson wrote: >>> >>> On the client side, I agree in principle (at least to ensure that no >>> client-to-server data is lost in a case where the API is used to send >>> frames then immediately close the connection). However, what if the >>> server never closes its side of the connection, even after the client >>> initiates a close? Should we have some sort of timeout? >>> >>> On the server side, I don't think there's any point _requiring_ that >>> the server close gracefully. If the server really doesn't care if data >>> it just sent is received, e.g. because it knows the client side has >>> already GC'ed its WebSocket object, then it should just be able to >>> close abruptly. >> >> How can the server possibly know that the client has already GC'd its >> WebSocket object, if the server and not the client is the initiator of >> the close? (If the client initiates the close, then at least in my >> proposal there's no extra work for the server.) > > The server and the client are typically written by the same person. If the > client sends a message in the subprotocol saying "ok after this I'm > throwing away all references to the object", then the server can know that > there's no point sending further data. Why would the client do that instead of sending a close message (thus making the client the close initiator)? Also, just throwing away all references to the object would not make it eligible for GC. Per the API spec, it is protected from GC if the connection is open and the WebSocket still has event listeners. I would say that explicitly closing the client side should send a close message (thus making the client the close initiator), and removing all listeners and dropping all references without closing should lead to GC which should close the connection (thus again making the client the close initiator). In either case, the client sending an extra "I'm dropping all references" message is extra work for the client and doesn't actually save work for the server, so what's the point? > I'm not saying this is good practice, I'm just saying that there's no > point making such practice non-conforming. I don't think there is a valid use case for allowing it, and it makes the protocol more complicated to have multiple options. Regards, Maciej
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.