Сообщение от Жека
Почему TCP не гарантирует доставку?
|
читай внимательнее:
Сообщение от impersonalis
при асинхронном сокете tcp (и, надо полагать, udp - не работал с ним)
|
и да - он гарантированно доставит то, что он отметил (путём указания длины в возвращаемом значении) как отправленное. Синхронный заблокирует вызывающий поток до конца отправки всего буфера. Для большого количества приложений это очень неудобно.
Суть такова: ты хочешь отправить команду "12345". Но в момент отправки сеть едва скрипит, поэтому за малое время, выделенное на отправку, уходит только "123", и функция возвращает тебе число 3, как индикатор количества отправленных байт. Очень часто, это число никто не проверяет (ограничиваясь только проверкой на отсутствие сбоя), считая что асинхронный сокет будет сам как-то выкручиваться и отправлять оставшееся "45". НЕТ. При следующем вызове надо будет отправить* "45" ещё раз. И опять убедиться - что отправилось.
Про контроль прочитанного мы знаем ещё по блитцу. В общем-то никто не гарантирует какими порциями информация будет уходить по сети. Как правило, происходит некая аккумуляция данных, чтобы не забивать сетку маленькими пакетами. Но при необходимости, это можно изменить. Но это отдельная большая тема.
Я бы не советовал в общем случае привязываться к разделителю строк. Сепаратор надо выбирать исходя из передаваемого контента. Возможно, его получится сделать более коротким, или наоборот - проще сделать подлиннее (например, исходя из больших размеров "строки").