smoltcp
smoltcp copied to clipboard
[Feature Request] Resize TCP socket buffer dynamically after TCP socket has been created
Currently, the buffer for TCP socket needs to be preallocated in socket::tcp::Socket::new() and I found nowhere to change its size. However, a configurable window size is necessary to achieve a balance between good bandwidth and low memory footprint. I notice that TCP window scaling (RFC 1323) is advertised to be implemented but it seems it's only properly implemented for the remote endpoint. Can this feature be implemented in local side?
I'm not sure what feature you're requesting:
- You can already use buffers any size you want. If you want a bigger buffer (hence a bigger window), use a bigger buffer.
- TCP window scaling is fully implemented. if you set a buffer bigger than 65536, window scaling will be used to advertise the full buffer size to the remote side. (Also note window scaling is just a TCP extension allowing advertising window sizes larger than 16 bits, which is the window field size in the header. Window scaling by itself won't make the buffer bigger.)
Thanks for your replying. What I want to achieve is the following:
- I don't know if the connection needs a big bandwidth initially, so I create a TCP socket with
tcp::Socket::new(vec![0;65536], vec![0; 65536])to reduce memory usage. - After some data exchange, I notice that we need a bigger receive window to satisfy BDP. Then I want to make the receive window to be 1MB. (Always allocating 1MB buffer for every socket at the beginning will lead to much bigger memory footprint)
Is this already possible?
ah okay! you want to dynamically change the buffer size after the TCP socket has already been created. Makes sense.
Unfortunately that's not possible now, no. Doing it if the buffer is borrowed might be hard, but should be doable if it's an owned Vec.
Then can we add such an API for sockets with owned Vec or Socket<'static> such as
fn replace_recv_buf<T: Into<SocketBuffer<'static>>(&mut self, new_buffer: T)->Option<SocketBuffer<'static>>
? Enabling this feature will be helpful to memory-constraint devices with skewed bandwidth needs.
sure! pull reuquests welcome