-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Say we have a maximum data size #4288
Comments
How are the packet number spaces subdivided? But yes, there are some absolute limits that it might be useful to mention earlier. |
I think that the packet number spaces caused a little confusion here: they multiply the number of packets (in theory, in practice they just add a small fixed number). It's good systems design to be prepared to lose fragile resources like connections, so I'm very happy that packet numbers eventually run out. I would almost have been happier with a lower limit, but this is where we ended up. BTW, the connection flow control limit is more likely to be the limit that applications hit (at least if you don't consider DATAGRAM). |
Proposing no action here. |
I don't think we can come up with a maximum data limit, since:
I expect that we can do an approximate maximum (2^62 * MTU = 4.6 * 10^18 * MTU), which will have no practical value to an application. |
The proposed resolution was to close to with action, which was signalled to the appropriate review channel. Hearing no pushback, I'm closing this. |
I know that this is a lot of space, although you subdivide it so its
smaller, but I would be useful is the fact that there was a maximum data size
was stated up from and it was specified. There are some applications that
expect to send continuously without disruption and would need to take action
prior to termination of the transfer.
The text was updated successfully, but these errors were encountered: