Re: [streams] Merge ReadableByteStream into ReadableStream (#430)

In Linux (I'm reading 3.13), the size of window to advertise is determined from sk_rcvbuf (using tcp_adv_win_scale). By default, 3/4 of free space of sk_rcvbuf is advertised. The free space is calculated by deducting sk_rmem_alloc from sk_rcvbuf.

sk_rmem_alloc represents the number of bytes received but not yet consumed by reading out to the user land. It increases when skb_set_owner_r() is called on delivery of data to TCP layer. skb_set_owner_r() also sets sock_rfree() to the sk_buff's destructor which decreases sk_rmem_alloc. tcp_read_sock() invokes this sock_rfree() by calling sk_eat_skb() on finished sk_buff. tcp_read_sock() is invoked on tcp_recvmsg().

When sending data or ack only packet, __tcp_select_window() is called to calculate the up-to-date window size to advertise in the packet. The calculation explained above happens in this function.

TCP_WINDOW_CLAMP socket option bounds window. But it seems only when window scaling is not turned on. See tcp_sock's window_clamp.

SO_RCVBUF socket option sets sk_rcvbuf. See SO_RCVBUF handling code in net/core/sock.c.

These values also cannot be less than SOCK_MIN_RCVBUF / 2. But it should be ok. It's small, and while read(2) doesn't happen the buffer gets filled to make sk_rmem_alloc hit sk_rcvbuf and let __tcp_select_window() decrease the advertised window.

When tcp_moderate_rcvbuf sysctl option is enabled, tcp_rcv_space_adjust() may automatically increase the space every time when read(2) consumes data from the kernel buffer. This is done based on the amount copied to user space in the last RTT and some strategy.

Setting SO_RCVBUF disables this automatic increase (see that SOCK_RCVBUF_LOCK is set to sk->userlocks) and reset the buffer size limit (sk_rcvbuf) to the given value.

So, IIUC, TCPSocketPosix::SetReceiveBufferSize() would help us prevent / recover from unexpected increase of amount of data being buffered in kernel.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/430#issuecomment-193877949