байт с одной стороны в другую. то что под капотом это бьется на пакеты с сиквенсом и прочими делами по определенным правилам, дальше упаковывается в IP пакет и дальше в L2 пакет это и так всем понятно - любой нынче кто хочет все это может увидеть каким-нибудь Wireshark без проблем или еще чего. Но на выходе у TCP сокета поток байт бесконечный до закрытия соединения (Называется TCP streams) - есть логическое начало с открытием соединения и есть логический конец после закрытия и все что можно делать с ним это читать из этого потока и в него писать, а также спрашивать у API если ли чего сейчас там в буфере стрима в данный момент, если нет то ждать пока будет например. Передавая какой-то массив данных чтобы из этого массива сделать логическую единицу нам нужно либо передать размер и потом вычитывать этот размер, либо использовать такие же потоковые сериализаторы как msgpack, либо мудрить что-то свое. Как обычная работа с TCP сокетом устроена? Берем узнаем есть че прочитать и читаем сколько есть. Если не рвать соединение то где конец одной логической единицы? Как его узнать? Ответ: никак, если не передать эту информацию в этом же потоке - нужно описывать свою логику ОТ и ДО. Как отослать 10 файлов через TCP сокет? Ответ: шлем его длинну и потоком все его содержимое, на другом конце принимаем длинну и вычитываем ровно столько из сокета, потом ждем опять длинну следующего и вычитываем этот размер из сокета. Это блин очень просто для понимания. И да важный момент - если данных в стриме сейчас нет это не значит что это конец передачи - это вполне себе штатная ситуация для сетей как медленный канал или медленно отправитель отсылает или еще чего. Надеюсь после этого обьяснения вопросов не останется, а если останутся - гугл и книжки в помощь, а лучше немного практики и самому разок написать что-то поверх TCP голого
+много
Обсуждают сегодня