[whatwg] Issues with Web Sockets API

[Alexey Proskuryakov]

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.

- WBR, Alexey Proskuryakov