История изменений
Исправление firkax, (текущая версия) :
Нет.
TCP - это транспорт в виде потока. Внутри него реализуется протокол обмена на уровне приложения. Клиент передает сообщение, вначале идет длина (фиксированное кол-во байт), потом полезная нагрузка. Сервер получает длину сообщения, узнает сколько байт в сообщении, потом читает полезную нагрузку. Потом точно также переходит к следующему сообщению.
Вот это правильно.
Если произошла потеря, т.е. ты не получил/потерял длину сообщения, то поток сломался и его надо чинить. Т.е. заново искать начало следующего сообщения. Это реализовано.
Вот это неправильно. Ты не можешь «не получить длину сообщения», поскольку это просто два (или сколько у тебя?) байта в потоке. Вот ты прочитал эти байты - это и есть длина. Но TCP тут совершенно ни при чём, это твой протокол поверх него.
Как я понял, у тебя в коде стоит какое-то условие, определяющее «неполучение длины». Как оно выглядит? (если что, таких проверок там быть не должно, за исключением разве что случая забагованного приложения - не tcp а именно приложения - на той стороне, которое шлёт изначально битый поток).
Исправление firkax, :
Нет.
TCP - это транспорт в виде потока. Внутри него реализуется протокол обмена на уровне приложения. Клиент передает сообщение, вначале идет длина (фиксированное кол-во байт), потом полезная нагрузка. Сервер получает длину сообщения, узнает сколько байт в сообщении, потом читает полезную нагрузку. Потом точно также переходит к следующему сообщению.
Вот это правильно.
Если произошла потеря, т.е. ты не получил/потерял длину сообщения, то поток сломался и его надо чинить. Т.е. заново искать начало следующего сообщения. Это реализовано.
Вот это неправильно. Ты не можешь «не получить длину сообщения», поскольку это просто два (или сколько у тебя?) байта в потоке. Вот ты прочитал эти байты - это и есть длина. Но TCP тут совершенно ни при чём, это твой протокол поверх него.
Как я понял, у тебя в коде стоит какое-то условие, определяющее «неполучение длины». Как оно выглядит? (если что, таких проверок там быть не должно, за исключением разве что случая забагованного приложения - не tcp а именно приложения - на той стороне, которое шлёт битый поток).
Исходная версия firkax, :
Нет.
TCP - это транспорт в виде потока. Внутри него реализуется протокол обмена на уровне приложения. Клиент передает сообщение, вначале идет длина (фиксированное кол-во байт), потом полезная нагрузка. Сервер получает длину сообщения, узнает сколько байт в сообщении, потом читает полезную нагрузку. Потом точно также переходит к следующему сообщению.
Вот это правильно.
Если произошла потеря, т.е. ты не получил/потерял длину сообщения, то поток сломался и его надо чинить. Т.е. заново искать начало следующего сообщения. Это реализовано.
Вот это неправильно. Ты не можешь «не получить длину сообщения», поскольку это просто два (или сколько у тебя?) байта в потоке. Вот ты прочитал эти байты - это и есть длина. Но TCP тут совершенно ни при чём, это твой протокол поверх него.
Как я понял, у тебя в коде стоит какое-то условие, определяющее «неполучение длины». Как оно выглядит? (если что, его там быть не должно, за исключением разве что случая забагованного приложения - не tcp а именно приложения - на той стороне).