Редактировалось 5 раз(а), последний 2021-05-21 05:32:15

Стоял тот же, только в режиме StreamToStr. Оригинальные схемы примеров можно найти в первом посте темы об указанных компонентах.
Отдельно работы с Stream там нет. Просто потому, что это можно сделать в схеме самому. Вариантов два:
1) Использовать конвертер. Поток преобразовывается в строку и отправляется. Минус - ограничение на объем файла (может не поместится в ОЗУ). Плюс - простота реализации. Данные через сеть передаются одинаково что из строки, что из стрима.
2) Используя DataToFile, в цикле считывать файл частями и отправлять опять же в виде строки. Минус - штатный DataToFile не умеет считывать/записывать строку указанной длины, а только строки с разделителями. Можно использовать модифицированный DataToFile. Плюс - таким образом можно реализовать практически любой существующий или собственный протокол передачи данных (впрочем, как и в первом случае).

Почему режим Stream не был введен в компонент? Потому, что передачу файла таким образом на практике применить тяжело: другой стороне сложно узнать об размере файла, начале/окончании передачи, обработать отмену передачи (в общем передать любую служебную информацию). Опять же ограничен размер файла на принимающей стороне.

ага ещё и собирать надо этот файлик путём убора
итд потому что информация идёт порциями а не целиком

"Путем убора
" - по описанной выше вине DataToFile. Собственно, "порция" никаких лишних
не содержит. Нормальный DataToFile + MemoryStream на принимающей стороне полностью эквивалентны старому режиму Stream.

Но не зря же применяют режим передачи чанк

Наверное. В любом случае, при реализации протокола передачи данных нужно предусмотреть возможность определения размера одного "сообщения". Просто потому, что протокол TCP гарантирует только обработку начала/заверешения соединения, порядок и целостность сетевых пакетов. А вот чтобы на один метод doSend получить одно событие onReceive - на это расчитывать не стоит: данные, отправляемые по doSend, разбиваются на порции, по которым происходит событие onReceive, причем последняя часть предыдущего doSend вполне может приклеится к первой следующего doSend и выдастся вместе событием onReceive.

Поэтому в протоколе верхнего уровня нужно предусмотреть отправку длины "сообщения" (либо разделителей, а обычно и того и другого), а в принимающей стороне делать накопление данных с события onReceive и разделять сообщения по полю длины либо по разделителях.