Re[2]: TCP window update
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 15.03.17 20:26
Оценка:
Здравствуйте, watchmaker, Вы писали:

По-моему, это всё крайне кривые решения. Если делать большие периоды перепосылки проб, восстановление потока может проходить крайне медленно, а если делать маленькие, это будет грузить сеть ерундой.
То есть формально решение есть, но по сути оно кривое до ужаса.
Почему бы не сделать опцию расширения типа window confirm?

Тут, кстати, есть ещё одна засада. Window size scaling устанавливается при старте соединения. Пусть были тогда уже запрошены какие-то супербуфера типа 16MB, это значит, scale 2^8 == 256, или даже выше. Это значит, что любое значение окна от 0 до 255 байт будет передано как 0, и только начиная от 256 байт будет передано как 1 (что с учётом масштаба даст 256). Это ровно из дословного понимания RFC1323 (или 7323, эта часть не менялась). Если буфера сохраняют свой исходный размер, это даст просто грубоватую реакцию, но если буфер ужать после коннекта, может заклинить безо всяких сетевых потерь. (Я бы просто не давал делать это ужатие, если соединение установилось.)
The God is real, unless declared integer.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.