Разработка мультипоточной программы, раздающая данные множеству клиентав( не менее 400 машин)

Здравствуйте!



Вот такая ситуация у меня: Нужно написать по работе, прогу

которая сможет в один миг(почти в один момент) передать одну

и туже информацию не менее 500 клиентам по сети. Т.е. прога

будет серверной!!!

В связи с тем что я реализовываю ее на билдере 6.0. При

расмотрении компонентов я накнулся на вкладку, так называемых

"инди", думаю кто с ними имел дело сразу поймет о каких "инди"

идет речь, так вот во вкладке этих компонентов есть tcp сервак

У меня вопрос сможет ли этот компонент выдержать такую наг-

рузку?

2.

Второй вариант о возможной реализации, это создать сразу

около 25 потоков(по моему в апаче такая техника) и дать каж-

дому потоку передать данные 20 клиентам. Также в этом вариан-

те предполагается использование WinAPI безовсяких компонент-

ных обертов, в связи с чем возникают еще два вопроса:

-Справится ли винда при работе 25 потоков, каждый из которых

отдает данные 20 клиентам?

-И выдержат ли винсоки?



зы: ассемблер и визуал с++ не предлагать, у меня на работе

"стандарт" на использование билдера! ((

 

Во-первых: использовать компоненты для работы с сетью - это просто ужасно! Никогда так не делай ни в коем случае.

Во-вторых: использовать кучу потоков это далеко не лучший вариант (по производительности).

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

 

Если UDP, то ведь это не факт,что клиент получит данные! а потоковое обязон!(как правило)

А у меня серьезные данные(температура к примеру) не полученная нужными людьми информация ведет к моему нагибанию в позу! (

Но то что ты предложил, вроде имеет смысль,надо докумекать!



Еще мысли?

 

Передавай по UDP, а после передачи какого-то количества информации пусть клиенты возвращают подтверждение ее доставки. При правильной реализации накладные расходы будут гораздо меньше чем на TCP.

Или пиши на TCP, но только на сокетах. Во-первых писать на них проще, чем на компонентах, во-вторых лучше производительность и больше возможности.

 

а сокеты, как я уже это спрашивал, выдержат нагрузку?

 

Смотря на какой машине. У меня Сel 3000 поставленый в качестве сервера держал одновременно 1500 TCP соединений без особого напряга. Тоесть это скорее зависит от того - выдержит ли канал. При широковещательной рассылке в сеть отсылается только одна копия данных, а с TCP придется отправлять отдельно каждому клиенту. Вот сам и считай - выдержит ли канал.

 

спасибо за вашу отческую опеку!

Если не трудно не могли бы вы по шагам описать весь процесс работы программы, если бы эту программу разрабатывали Вы! если конечно вас не затруднит

 

Я вообще то прокси разрабатывал, но применительно отправке данных через TCP сокеты многим клиентам я бы

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

Если нужен двусторонний обмен, то лучше использовать пул потоков (функция QueueUserWorkItem), а не создавать новые потоки. При этом обмен лучше делать на синхронных сокетах.

При программировании высокопроизводительного сервера полезно не создавать сокеты для каждого подключения, а создать массив сокетов и использовать их многоразово. Также следует повторно использовать созданые евенты, потоки и.т.д.

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



По программированию сокетов рекомендую почитать статью http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1060&mode=print, там все описано понятным языком, хотя к сожалению рассмотрены далеко не все тонкости сетевого программирования.

 

Я как раз сейчас пишу прогу с Инди токо на Дельфе. Насколько я понимаю, то если ты установишь соединения и не будешь их закрывать, а держать открытыми, к примеру запихнув ихни хендлы в какой-то масив, то по-идее 500 ззапросов выдержит, только есс-но зависит от того что ты подразумеваешь мгноенно и есс-но какая сетка, сервак. Если же открывать соединения через сокет каждый разкак надо передать даные, то получится очень долго.

По-моему можна реализовать первый вариант, только придется обрабатывать исключение.

 

Соединения закрывать как раз можно (да и часто нужно), но делать это нужно функцией shotdown, после чего сокет можно использовать для другого соединения.

 

2 Ms Rem

а можно чуть больше рассказать о WSAOverlapped и WSAVaitForMultipleEvents ?

 

К стати нагрузку на сервак можно снизить, если использовать некоторою распределённость. Посылаем через TCP соединение данные машине 192.168.0.1 (к примеру) затем 192.192.0.3, 192.168.0.5 и т.д. Каждая машина отправляет этот же пакет через TCP соединение своему соседу 192.168.0.1->192.168.0.2; 192.168.0.3->192.168.0.4 и т.д. Идея интересная, только надо разработать стратегию... Нечего сервер перегружать, у него работы и так хватает ))

 

Инфа про это есть в статье, линк на которую я давал.

Неплохая идея. Недостаток ее в том, что нужно доверять клиентам. А вдруг клиент откажет или просто не станет отсылать данные, или передаст их в измененном виде (всему что делается у клиентов нельзя доверять).

Но с точки зрения производительности вариант весьма неплохой.

 

Нагрузка на сервер упадет изрядно, но латентность передачи сигналов может и возрасти (т.е. клиенты будут получать их несколько позже). Не могу представить, что будет в итоге, только для 500 соединений.

 

На какую платформу нужна программа? Если НТ - тогда юзай I/O Completion Port.



A simple IOCP Server/Client Class



codeproject

Там много примеров работы с ним.

 

Ms Rem

Не думаю что соединения нужно закрывать, так как на открытие нового может уходить очень много времени. В том учебном году я уже сталкивался с этим. Мне нужно было синхронно посылать команды от сервака к клиентам, и добиться синхронности можно было только не закрывая соединения.

 

Dart_Bobr

Я не говорю, что соединения всегда нужно закрывать. При реализации своего протокола этого можно (и следует) избежать. Но есть протоколы в которых это обязательно необходимо делать, например в HTTP прокси.

 

Ms Rem

Не понятно, а как использовать созданные сокеты уже после вызова shutdown? Ведь при подключении клиента создастся новый сокет. Я чего путаю или/и плохо знаю

 

Я говорю не о серверной, а о клиентской стороне. Если принимать соединения, то действительно сокеты придется закрывать. А если самому коннектиться куда-либо, то после shutdown можно снова вызвать connect для того же сокета.

Например в случае прокси, нужно не только принять соединение, но и приконнектиться к target хосту, и этот процесс и можно оптимизировать не закрывая сокеты.

 

извините, что долго не появлялся.

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