[whatwg] Issues with Web Sockets API
Maciej Stachowiak
mjs at apple.com
Mon Jul 27 12:35:15 PDT 2009
On Jul 27, 2009, at 1:16 PM, Alexey Proskuryakov wrote:
>
> 06.07.2009, в 21:30, Ian Hickson написал(а):
>
>>> postMessage() may want another exception condition... 'too much data
>>> pending exception'... consider calling postMessage in a while(true)
>>> loop... at some point the system is going to have to give up
>>> queing the
>>> data if its not actually making its way out on the wire.
>>
>> The spec doesn't specify how UAs are to handle hitting hardware
>> limitations or system limitations, because it's often difficult to
>> truly
>> control how those cases are handled.
>
>
> I agree with Michael that send() should not silently drop data that
> could not be sent. It is very easy to fill send buffers, and if
> bytes get silently dropped, implementing app-level acks becomes
> quite difficult. With TCP, the basic guarantee is that bytes are not
> lost until the connection is lost, so app-level acks only require
> confirming the last processed command, and losing this guarantee
> would be quite unfortunate. Most (all?) system TCP implementations
> certainly have ways to deal with flow control.
>
> However, I do not think that raising an exception is an appropriate
> answer. Often, the TCP implementation takes a part of data given to
> it, and asks to resubmit the rest later. So, just returning an
> integer result from send() would be best in my opinion.
With WebSocket, another possibility is for the implementation to
buffer pending data that could not yet be sent to the TCP layer, so
that the client of WebSocket doesn't have to be exposed to system
limitations. At that point, an exception is only needed if the
implementation runs out of memory for buffering. With a system TCP
implementation, the buffering would be in kernel space, which is a
scarce resource, but user space memory inside the implementation is no
more scarce than user space memory held by the Web application waiting
to send to the WebSocket.
Regards,
Maciej
More information about the whatwg
mailing list