из брандмауэров только стандартный и тот отключен
мне кажется файерволы здесь точно ни при чём, т.к. сервер после посыла большого месседж, не шлёт далее запланированные мелкие мессаги такие как маркеры окончания передачи и прочее.

hitman249, а мысль передавать кусками длинное сообщение не возникало

nesco, насколько крупные сообщения можно передавать?
может это и есть у меня "куски"

ПС переделал сервер и клиент на Stream, вродебы работает

hitman249, сразу предупреждаю, я не делфятник и буду опираться на свой опыт работы с сокетами в ассемблере по аналогии, местные гуру поправят. С очень большой долей вероятности могу предположить, судя по исходным кодам пары библиотек и пары компонентов, в частности, TCP_Client, на базе которого собран сервер, что отправка не учитывает некоторых ньюансов при передаче. По-хорошему программист должен был проверять, успело ли установиться соединение (SendBlocked = False), не произошло ли других ошибок. Вместо этого беспечно предполагается, что отправка ВСЕГДА заведомо успешна Хуже того, временная блокировка сокета (это когда, например, соединение инициализируется и данные не могут быть отправлены прямо сейчас) - это вообще единственное, что хоть как-то обрабатывается из возможных ошибок, можете забыть про onError - он сделан для красоты и бесполезен. А бесполезен он потому, что TCP_Client реализует функционал через TCP.pas, в котором игнорируются практически все остальные ошибки. Вот такой вот пофигизм.
------------ Дoбавленo в 09.46:

А мысль исправить кривые библиотеки и компоненты?
------------ Дoбавленo в 09.53:
Или TCP.pas - очередная неприкосновенная историческая ценность?

Да нет, я им не занимался вообще, а потому, я его не знаю. Пишите Автору, пусть поправит, или религия не позволяет
1nd1g0, вместо того, что бы тут на кого-то наезжать, взял бы и поправил сам
------------ Дoбавленo в 10.21:

Вот этот пофигизм и озвучьте Автору, я к этому никакого отношения не имею. Я уже говорил не раз, что не очень хорошо разбираюсь в интернет компонентах и потому лезьть в них не стану

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

[flood]да.. боюсь стабильный сервер написать для меня будет занятие не простое[/flood]
------------ Дoбавленo в 13.29:
какая идёт последовательность при подключении к серверу
по точкам
onConnect, ##eventHandle, IP
т.е.
при подключении onConnect выдаёт IP подключившегося, далее выбирает он сам свою схему, чтобы можно было считать точку ##eventHandle ?

------------ Дoбавленo в 13.51:

если он всёже выбирает схему, то другой предыдущий подключившийся клиент 100 мс назад, качавший уже чтото в это время получит фигу?
------------ Дoбавленo в 13.55:
далее продолжая мысль, следующий любой подключившийся клиент, может теоретически нарушить работу сервера
т.к. в это время ктото может чтото слать и внезапно подключившийся клиент поменяет хендл и данные уйдут не туда

По идее ##eventHandle должен содержать информацию о схеме, породившей событие, не зависимо от текущей выбранной схемы, то есть "самовыбора" проиходить не должно.

вот кусочек для размышления
это почти два дня борьбы с большим разнообразием глюков
единственный пока подобранный мной вариант, который работает без глюков

в остальных вариантах, похоже сервер не успевает обрабатывать и в результат выпадают дублирующие данные к имени строки
отсюда множество строк c разными именами но с одинаковыми IP адресами

code_25933.txt
------------ Дoбавленo в 16.02:
этот модуль цепляется на выхлоп элемента TCP_ServerEx

nesco, желательно тебе проверить как сервер ведёт себя в реальных условиях.

достаточно выставить интервал таймера на 1 или вовсе пересобрать схему без таймера.
при одновременно подключающихся клиентах и уже происходящем обменом данных очень красивые вещи начинаются с определением IP.
ВАЖНО: клиенты должны быть запущены с другого ПК

симптомы: после подключения сервер сразу начинает обмен данными, он сразу отсылает запрос на определение имени ПК и ждёт ответ клиента,
если в момент ожидания подключается ещё один клиент, его добавляют в очередь, а не по системе "сразу всех".
при массовом подключении (у меня эффект неправильных IP получился уже после одновременного подключения 3-4 клиентов).


а на практике не получается так красиво

Это не так просто сделать физически. Во-вторых: компонент TCP_ServerEx разрабатывал tsdima, я туда вообще ни ногой не полезу

nesco, C MTStrTbl реально общаться из копии TCP_ServerEx?

Да, если таблица находится по иерархии выше и не в другом контейнере

ничего не пойму, сервер отсылает список 2 раза
code_26014.txt
------------ Дoбавленo в 13.59:
переделал логику
nesco, MTStrTbl имеет гдето событие на изменение списка строк? пересмотрел возможные по логике компоненты, не нашёл

Привет! onChange есть везде, где есть изменение списка, уж точно есть в MST_RowAction и MST_ColAction