There has been an update to the discussions in git about this by the QUINN people. @bzee
And it seems that they have confirmed some things @dirvine while not fully understanding Nodes comms and its peer-to-peer nature. They are viewing this through the glasses of data-centre server to client type of comms where its the server controlling things. For Autonomi the “server” is just another node and the client is another node (node here could be a uploader/downlader app too) and both can be behind a potato router.
max_stream_datadoesn’t apply to a connection, but instead to a stream on the connection. One connection may have multiple streams, in which case the max allowed unacknowledged data on the connection is the# streams X max_stream_data.max_connection_dataapplies an additional maximum to the whole connection.
But this detail is probably not super important for you if you have a smaller number of streams.
Yes I did conflate the two a bit in the OP but later posts separate them. The point made in the OP was relating to the stream being part of the connection. As mentioned the conflation is not so important an issue with small number of streams per connection.
max_stream_datais not the maximum outgoing data that we can sent unacknowledged on a stream. Instead it is the max unacknowledged data that we allow the remote peer to sent to us, before they must stop sending (else it’s a protocol violation).
In fact this just confirms my findings and clarified it. Each node (or downloader app) can be the requester and there is a sender node (or uploader app) and it is indeed the sender that needs to have its data chopped up into smaller parts to allow, on its link/router, other data to flow or the router buffer to not overflow. So they have confirmed the OP while correcting the wording.
Basically this is a peer to peer network and nodes can and will be at certain stages a sender or receiver. The requester limiting the max windows size helps the sender to not have router issues or link congestion issues. The comments above is written more from the requester side.
@riddim This explains why setting the max_window_size on your end had no effect, it is because the troubles only occur when your nodes are sending. You setting the size only affects when you are the requester (receiving). And explains another reason it has to be network wide.
Also a potential attack vector, albeit a tiny largely ineffectual one, in future when the max window size is reduced to 128KB or 256KB and that it a person could set their env vars to want the larger window size and cause some routers to have buffer overflows, and a good reason to not allow ENV vars to change the max_window_size