Многопоточное соединение сервер-клиент

[ShadowMaster]

Здравствуйте! Читаю форум, и вижу, что всем помогают, от простых вопросов до самых сложных.... Сидел, мучился в одиночку и вот решил спросить, мб и мне кто пожет. Итак, Сабж.
Есть сервер-клиент соединение основанное на TSocketServer/Client. В клиент вшита мат. машина, но к делу это не относится. После подключения, пользователь получает список подруженных баз. После нажатия на OK по таймеру(например раз в 2 секунды) начинает идти строка для расчета(с сервера на клиент). Далее пользователь жмет на запуск подачи данных со второй базы. И вот тут загвоздка.

Например на сервере есть готовыепотоки M1 :=TMemoryStream;
M2 :=TMemoryStream;
Далее по запросу SendStream(m1);
Пришел Второй запрос:
SendStream(M2);
На буфере клиента будет свалка.Индексировать перед отправкой тоже тупо. Задача такая
send ServerStream(M1)--->ClientStream1;
Send ServerStream(M2)-->ClientStream2;
Почему тупо индексировать данные? Во-первых это нужно знать уникальные ключи сервера.
Во вторых поток придется разбирать и проверять/разбивать по ключам=> Времени будет тратится много а толку нет.
Вот например как инетовские качалки пашут? Скажем ReGet, DM, FlashGet?
В процессе активной закачки в один поток можно добавить еще один поток.
Можно его отключить при этом данные не потеряются.=> Если там все таки ключи какие-нить, то Должны быть госты, по которым весь мир ключи эти генерит. Хотя мне почему то кажется что это делается многопоточным соединением.

Вот если бы два клиента было, тогда понятно. После подключения в массив коннектов вводится номер машины-клиента. Но клиент то один. И процедура SendStream тоже одна.=(
Жду предложений от экспертов.

[NikLik]

Используй Indy компоненты IdTCPServer\Client.
Там принцип работы другой--пока не обработана предыдущая комманда, следующая не выполняется, если я не ошибаюсь.

[ShadowMaster]

Если я правильно понял ваш ответ

Сообщение от NikLik

пока не обработана предыдущая комманда, следующая не выполняется

то чем мне это поможет? Мне как раз таки надо одновременно в разные стримы гнать на клиенте.
Или вы к тому, что там так и можно гнать просто не будет свалки на потоке клиента?
Если можно с примером, для наглядности.

[alexBlack]

Сообщение от ShadowMaster

Вот если бы два клиента было, тогда понятно. После подключения в массив коннектов вводится номер машины-клиента. Но клиент то один. И процедура SendStream тоже одна.=(
Жду предложений от экспертов.

По-моему можно создать отдельный TClientSocket для каждого потока/запроса. Пример передачи двух потоков:

[Квэнди]

в подобном случае проще организовывать такую схему: опишу на примере Indy (при реализации с TclientSocket и TserverSocket реализовывается аналогично):
Сервер TidTcpServer, к оторому подсоединяется некий сервер и отправляет некую комманду, по которой в обработчике onexecute вы, распарсив и проанализировав комманду создаете сторонний поток, в котором в run-time создаете TcpClient , с помощью которого отправляете необходимые вам данные. На другой стороне будет корректно также использовать TcpClient для подключения к серверу и отправки комманд и TidTcperver для приема получаемых данных, в этом случае все получаемые данные будут автоматически получаться в отдельных потоках (только в Indy , TserverSocket многопоточность реализовывайте ручками). подобный метод будет держать достаточное кол-во одновременных потоков. По поводу кол-ва почитайте этот раздел, эта тема уже поднималась.

[ShadowMaster]

Не знаю как правильнее было бы сделать но идея alexBlack`а мне понравилась. Модифицировав, можно опросить массив соединений на сервере. Потестил, реально работает, спасибо=) Хотя этот метод достаточно сильно грузит( ведь по сути это создание виртуальных клиентов), в моем случае это не критично т.к. у меня система работать будет от 1-го до 8 потоков. Крайний(пиковый) режим 50 потоков.
Стало интересно, а downloader`ы инетовские типо FlashGet и т.п. так же работают? Просто они запрашивают размер файла, делят его на количество потоков и смещают TStream.Seek? или там какие то другие замутки?
Квэнди впринципе как я понял ваш метод в чем то похож на метод alexBlack`а. Та же run-time генерация.