как известно, при отсылке текстовых сообщений, близко расположенных по времени, они сливаются в одно (если длинное то приходит несколькими частями). А вот в режиме Stream такого не происходит - они просто не приходят (или не отсылаются?) вообще ни одно code_10272.txt . Если в таймере поставить AutoStop=2 и снять DOUBLE, то 20 ms вполне хватает для нормальной работы (в длинных сетях и на больших сообщениях не проверялось). Есть предложение - научить клиента докладывать о выполнении поручений только после их выполнения (а то хаб-то ему верит)..

что это значит?


это не режим, а способ отсылки данных. Отличается от всех прочих тем, что в соукет передается количаство отсылаемых байт, которое и проверяется на принимающей стороне - пока все байты не будуи приняты ничего в поток выведено не будет

Тоже бывало - решил при помощи символа-разделителя

что Hub не должен запускать onEvent2, пока не доставлено сообщение по onEvent1 (я так думаю).
Судя по взаимонепониманиям, я что-то не так делаю хочу узнать - как это делается..

Андрей., это называется работа сокета в блокирующем режиме. Режим этот выставляется в настройках сокета при его создание. В HiAsm не использовался до сего моменту ввиду ненадобности. Если честно не совсем понимаю, каким образом теряются данные в протоколе с гарантированной доставкой Как правило такая недоставка данных приводит к дисконнекту сокета после чего делается повторное соединение и отправка.

Андрей., да понял про что ты имел ввиду.

продолжаем разговор

вот такая code_10303.txt схема работает. Если отправлять 2 сообщения подряд с одного клиента, то TCP_ServerEx тоже ничего не выдаёт. Напрашивается вывод, что причина - клиент, а именно - не разруливается совместный доступ при рестарте потока (имхо неспециалиста)..