А знаете, почему работает? Я вот догадываюсь. В режиме передачи потока проходит не одна сессия отправки данных, а две! Первая - один микропакет (четыре байта), вторая - основной блок данных. Так вот, за счёт малого размера первого пакета (4 байта значительно меньше MTU, который обычно 0.5 - 5 Кб) он буферизируется, инициализация сессии проходит успешно, и следом уже по рабочему каналу уходят данные. Ключевой момент тут в том, что первый пакет содержит размер данных на посылку, и принимающая сторона настойчиво ждёт все данные уже зная их размер. А вот в случае со строкой клиент без малейшего понятия, чего ждёт, что первое "прилетит" в сокет, то измерит по длине, положит в память, назовёт строкой и выдаст наружу (угадайте, есть ли в таком поведении подводные камни). Хотя и в режиме dtStream, естественно, всем по фигу до возможных ошибок, но благодаря такой последовательности пакетов, вероятность проблем снижается, но не пропадает совсем, например, при блокировкеошибке на первой посылке (что ооочень маловероятно, но всё-же...) отправлены будут только данные, без длины! Причём принимающая сторона вместо данных ждёт 4 байта - число с длиной, а тут прилетает каких-нибудь десять мегабайт, можно представить, что будет в таком "забавном" случае Спасает лишь то, что временная блокировка на 4 байта - жутко редкое явление а все остальные ошибки чаще всего блокируют ОБЕ отправки (например, сетевой кабель не подключен и т.п.). Но вероятность того, что только один пакет не уйдёт - не нулевая, ибо где проверка на успешную доставку первого пакета? Нет её. Тупо нет и всё.