История изменений
Исправление Iron_Bug, (текущая версия) :
вот как раз congestion algorithms и решает подобные вопросы. если у тебя данные уже приняты, то они уходят в апстрим, ты их не накапливаешь бесконечно. ну и представь себе, какой должен быть поток, чтобы быть настолько длинным, чтобы там стали повторяться по кругу одни и те же номера. там скорее таймаут произойдёт и начнётся новая сессия.
даже если ты не будешь эмулировать ось и у тебя уже готовый поток, то тебе надо принять какое-то решение, как ты будешь обрабатывать ситуации ошибок и перепосылок. например, могут быть посланы разные версии одного и того же пакета (например, испорченная и перепосылка правильной). и из-за этого тебе надо будет последующие пакеты отбрасывать и перестраивать. кроме того учти, что данные вообще надо проверять. там могут быть битые данные и длины могут не совпадать с реальными данными пакета и т.д. то есть, надо заранее считать данные возможно невалидными. обычно контроль валидности осуществляется где-то на более высоком уровне. на уровне TCP/IP можно гарантировать лишь некоторую условную валидность, в рамках выбранного алгоритма.
Исправление Iron_Bug, :
вот как раз congestion algorithms и решает подобные вопросы. если у тебя данные уже приняты, то они уходят в апстрим, ты их не накапливаешь бесконечно. ну и представь себе, какой должен быть поток, чтобы быть настолько длинным, чтобы там стали повторяться по кругу одни и те же номера. там скорее таймаут произойдёт и начнётся новая сессия.
даже если ты не будешь эмулировать ось и у тебя уже готовый поток, то тебе надо принять какое-то решение, как ты будешь обрабатывать ситуации ошибок и перепосылок. например, могут быть посланы разные версии одного и того же пакета (например, испорченная и перепосылка правильной). и из-за этого тебе надо будет последующие пакеты отбрасывать и перестраивать. кроме того учти, что данные вообще надо проверять. там могут быть битые данные и длины могут не совпадать с реальными данными пакета и т.д. то есть, надо заранее считать данные возможно невалидными.
Исправление Iron_Bug, :
вот как раз congestion algorithms и решает подобные вопросы. если у тебя данные уже приняты, то они уходят в апстрим, ты их не накапливаешь бесконечно. ну и представь себе, какой должен быть поток, чтобы быть настолько длинным, чтобы там стали повторяться по кругу одни и те же номера. там скорее таймаут произойдёт и начнётся новая сессия.
даже если ты не будешь эмулировать ось и у тебя уже готовый поток, то тебе надо принять какое-то решение, как ты будешь обрабатывать ситуации ошибок и перепосылок. например, могут быть посланы разные версии одного и того же пакета (например, испорченная и перепосылка правильной). и из-за этого тебе надо будет последующие пакеты отбрасывать и перестраивать.
Исходная версия Iron_Bug, :
вот как раз congestion algorithms и решает подобные вопросы. если у тебя данные уже приняты, то они уходят в апстрим, ты их не накапливаешь бесконечно. ну и представь себе, какой должен быть поток, чтобы быть настолько длинным, чтобы там стали повторяться по кругу одни и те же номера. там скорее таймаут произойдёт и начнётся новая сессия.
даже если ты не будешь эмулировать ось и у тебя уже готовый поток, то тебе надо принять какое-то решение, как ты будешь обрабатывать ситуации ошибок и перепосылок.