This is an optimization when GATT MTUs are large. Since we have a default Gattlink buffer size that's kept small to avoid unnecessary latency, and with a default Gattlink window size of 8, when the GATT MTU becomes large, there's a risk of having to wait for ACKs too long:
When the peer has no data to send, it sends ACKs when either a timeout has passed (200ms by default) or the number of unacknowledged packets is > (rx_window)/2. So, if the number of packets that the sender's buffer would be split into is too small (which would happen if the packets get large), the sender may be waiting too long for ACKs.
With this PR, we introduce a limit on the max packet size when using the default buffer size and default window size (when using custom configs, the caller can decide what to do, even if sub-optimal, but we want to keep the default config optimal).
In practice, this will result in the max fragment size limit to be 256 with the current default settings (default buffer is 2560 (2*1280), and rx_window=8, and we choose the limit so that 1/2 of the buffer fits in (1+rx_window)/2, so 256 bytes.
This change has been tested between 2 macs that negotiate an ATT MTU of 527. It does offer a small throughput improvement.
More testing should be done on other platforms, with different environment, but it should be considered a safe default for all cases.
This is an optimization when GATT MTUs are large. Since we have a default Gattlink buffer size that's kept small to avoid unnecessary latency, and with a default Gattlink window size of 8, when the GATT MTU becomes large, there's a risk of having to wait for ACKs too long: When the peer has no data to send, it sends ACKs when either a timeout has passed (200ms by default) or the number of unacknowledged packets is > (rx_window)/2. So, if the number of packets that the sender's buffer would be split into is too small (which would happen if the packets get large), the sender may be waiting too long for ACKs. With this PR, we introduce a limit on the max packet size when using the default buffer size and default window size (when using custom configs, the caller can decide what to do, even if sub-optimal, but we want to keep the default config optimal). In practice, this will result in the max fragment size limit to be 256 with the current default settings (default buffer is 2560 (2*1280), and rx_window=8, and we choose the limit so that 1/2 of the buffer fits in (1+rx_window)/2, so 256 bytes.
This change has been tested between 2 macs that negotiate an ATT MTU of 527. It does offer a small throughput improvement. More testing should be done on other platforms, with different environment, but it should be considered a safe default for all cases.