[whatwg] Issues with Web Sockets API

[Drew Wilson]

On Mon, Jul 27, 2009 at 1:36 PM, Alexey Proskuryakov <ap at webkit.org> wrote:

>
> 27.07.2009, в 13:20, Jeremy Orlow написал(а):
>
>  I agree that this will help if the application sends data in burst mode,
>> but what if it just constantly sends more than the network can transmit? It
>> will never learn that it's misbehaving, and will just take more and more
>> memory.
>>
>> An example where adapting to network bandwidth is needed is of course file
>> uploading, but even if we dismiss it as a special case that can be served
>> with custom code, there's also e.g. captured video or audio that can be
>> downgraded in quality for slow connections.
>>
>> Maybe the right behavior is to buffer in user-space (like Maciej
>> explained) up until a limit (left up to the UA) and then anything beyond
>> that results in an exception.  This seems like it'd handle bursty
>> communication and would keep the failure model simple.
>>
>
>
> This sounds like the best approach to me.
>
>
> 27.07.2009, в 13:27, Drew Wilson написал(а):
>
>  I would suggest that the solution to this situation is an appropriate
>> application-level protocol (i.e. acks) to allow the application to have no
>> more than (say) 1MB of data outstanding.
>>
>> I'm just afraid that we're burdening the API to handle degenerative cases
>> that the vast majority of users won't encounter. Specifying in the API that
>> any arbitrary send() invocation could throw some kind of "retry exception"
>> or return some kind of error code is really really cumbersome.
>>
>
> Having a send() that doesn't return anything and doesn't raise exceptions
> would be a clear signal that send() just blocks until it's possible to send
> data to me, and I'm sure to many others, as well. There is no reason to
> silently drop data sent over a TCP connection - after all, we could as well
> base the protocol on UDP if we did, and lose nothing.
>

There's another option besides blocking, raising an exception, and dropping
data: unlimited buffering in user space. So I'm saying we should not put any
limits on the amount of user-space buffering we're willing to do, any more
than we put any limits on the amount of other types of user-space memory
allocation a page can perform.


> - WBR, Alexey Proskuryakov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090727/4cdd671c/attachment.htm>