| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TWSocket пул сокетов
mnm © (2006-08-02 17:38:00)Интересует, как необходимо правильно организовывать клиентское много-поточное приложение (потоков до тысячи допустим), не хочу применять потоки-Threads, хочется сделать пул сокетов. Читал про подобное при конструировании сервера на чистом winsock'ете, с использованием пула сокетов.
Вот и хотелось бы узнать, реально ли организовать клиентское приложение на TWSocket с пулом сокетов, вместо виндовских потоков. Я себе лично не предстваляю, поэтому интересуюсь вашего мнения...
Сергей М. (2006-08-03 14:02:00) [1]
> mnm
Наверно, еще одним не худшим решением будет использовать (в кач-ве альтернативы TClientSocket и TTCPClient) компонент TApdWinsockPort в составе TurboPower AsyncPro. Если мне не изменяет память, там тоже реализован неблок.режим, к тому же имеются св-ва/методы/события, ощутимо упрощающие обмен по прикладному протоколу инф.обмена с партнером.
Сергей М. (2006-08-03 13:41:00) [2]
> mnm (03.08.06 13:28) [16]
TClientSocket тоже умеет работать в блок. и неблок. режимах, причем по-умолчанию в момент создания объекта устанавливается как раз неблок.режим.
TTCPCLient в неблок.режиме, пожалуй, даже более удачным решением будет - там событийный механиз получше продуман, да и методы SendLn()/ReceiveLn() по их внутренней логике будут более подходящими для простого обмена строками текста с HTTP-прокси-сервером.
Блокирующий же режим не годится по условию - для этого придется создавать доп.потоки, что нежелательно и вряд ли оправдано в решении данной задачи.
> какое поведение будет у такого массива
У массива нет и не может быть "поведения", он просто хранит ссылки на созданные сокетные объекты для их последующего уничтожения и быстрого доступа к конкретным объектам по их индексу в массиве.
Обработчики событий для всех объектов в массиве единые и устанавливаются однократно сразу после создания объектов.
mnm (2006-08-03 13:28:00) [3]Сергей М., спасибо большое, я так и думал приблизительно, только сомневался в правильности и надежности при большом количестве объектов в массиве. Сейчас посмотрел TTCPCLient, обнаружил в нем BlockMode, то бишь возможность использования блокирующего/не блокирующего режима и не пойму сейчас, а какое поведение будет у такого массива, при использовании блокирующего или не блокирующего? Я понимаю разницу между блокирующем и не блокирующим, но как тут это будет отражаться -- не понимаю.
Сергей М. (2006-08-03 13:19:00) [4]type
TMyForm = class(TForm)
..
ClientSockets: array[0..499] of TClientSocket;
..
procedure DoRead(Sender: TObject; Socket: TCustomWinSocket);
procedure DoWrite(Sender: TObject; Socket: TCustomWinSocket);
procedure DoConnect(Sender: TObject; Socket: TCustomWinSocket);
procedure DoError(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer)
..
end;
..
for i:= 0 to 499 do begin
ClientSockets[i] := TClientSocket.Create(Self);
with ClientSockets[i] do begin
Tag := i;
Address := ...; //нужный IP-адрес
Port := ...; //нужный порт
OnConnect := DoConnect;
OnRead := DoRead;
OnWrite := DoWrite;
OnError := DoError;
Open;
end;
end;
....
procedure TMyForm.DoRead(Sender: TObject; Socket: TCustomWinSocket);
begin
... здесь читаешь анализируешь данные, поступающие от сервера ..
... по окончанию анализа делаешь Socket.Close, далее см. (*)
end;
procedure TMyForm.DoWrite(Sender: TObject; Socket: TCustomWinSocket);
begin
... если есть не переданные серверу данные, передаешь их здесь...
end;
procedure TMyForm.DoConnect(Sender: TObject; Socket: TCustomWinSocket);
begin
... коннект с сервером установлен ...
end;
procedure TMyForm.DoError(Sender: TObject; Socket: TCustomWinSocket; ErrorEvent: TErrorEvent; var ErrorCode: Integer)
begin
ErrorCode := 0;
Socket.Close;
... здесь устанавливаешь, если необходимо, другой адрес и другой порт (*):
with ClientSockets[TComponent[Sender].Tag] do begin
Address := ....;
Port := ....;
Open; //старт операции коннекта
end;
end;
mnm (2006-08-03 12:56:00) [5]Ну а если можно с ним (TClientSocket и TTCPClient), пример небольшой привести. Я не понимаю, как использовать компонент/класс в моей идеи. Т.е. при использовании чистого TSocket, всё более менее чуть-чуть внятно. Что делать в случае с TClientSocket и TTCPClient, я хоть убейте за мою тупость не пойму?
Сергей М. (2006-08-03 12:44:00) [6]А чем стандартные TClientSocket и TTCPClient не угодили ?
mnm (2006-08-03 12:31:00) [7]Спасибо, что поняли мою идею :) Ну на голом winsocket'e я уже немного представляю как такое реализовать, но вопрос мой про реализацию этой же идеи, но с помощью TWSocket (ICS, www.overbyte.be/eng/products/ics.html). Есть идеи? Я просто не очень предстаялю как с ним такое осуществить.
Сергей М. (2006-08-03 11:57:00) [8]Ну у каждой системы они свои ..
Здесь следует больше волноваться за то, сколько гнезд при этом может существовать одновременно. Гнездо же, по сути, представлено в памяти некой внутренней структурой, с которой ассоциирован хэндл этого гнезда. А память она не резиновая).. Кр.того, ограничены иные ресурсы как процесса, так и системы в целом..
Rouse_ (2006-08-03 11:45:00) [9]Ну да :) Я в плане системных ограничений :)
Сергей М. (2006-08-03 11:44:00) [10]
> Rouse_ © (03.08.06 11:38) [8]
А ему не надо ничего держать)
Он же просто переводит указанное гнездо в неблок.режим с оконными нотификациями, т.е. говорит одному конкретному гнезду, мол, отныне при таких-то транспортных событиях посылай такое-то сообщение такому-то окну.
Rouse_ (2006-08-03 11:38:00) [11]Я кстати тоже про WSAAsyncSelect подумал, надо будет на досуге поэксперементировать, сколько он сможет выдержать :)
Сергей М. (2006-08-03 11:29:00) [12]А и не надо select)
На то, сам понимаешь, есть WSAAsyncSelect/WSAEventSelect
Правда, в случае с WSAEventSelect засада будет в другом месте - придется разруливать ситуацию с системным ограничением кол-ва ивентов, передаваемых на вход wait-функций
Rouse_ (2006-08-03 11:23:00) [13]Боюсь что select не потянет сразу 500 гнезд :)
Сергей М. (2006-08-03 08:20:00) [14]
> mnm
Ты так и не сказал, зачем тебе понадобились потоки, да еще в таком количестве.
Создай нужное число клиентских гнезд, переведи их в неблококирующий режим и работай с ними в одном и том же потоке..
mnm (2006-08-02 19:58:00) [15]Вот к примеру, если меня не поняли, ещё одно упоминание о моей идеи вот тут http://www.xakep.ru/post/14087/default.asp
mnm (2006-08-02 19:21:00) [16]Ну первым делом, скажу, чтоя правда запутался в терменах. В итоге, сейчас постараюсь переформулировать.
Как организовать многопоточность (я не говорю про именно многопоточность по tthread / createthread, просто употребляю этот термин как одновременное кол-во объектов работающих с сетью), не прибегая к использованию встроенной в винду потоковой (createthread / tthread - delphi) технологии, на TWSocket.
Пример, где я напрмер встетил похожую реализацию но на чистом winsockete. http://delphiworld.narod.ru/base/sockets3.html
До 1000 потоков, я сказал по максимуму, ну вот допустим представляете есть у вас скажем список ip адресов (много, несколько тысяч...) , необходимо их проверить на пригодность для использования в качестве прокси. Я конечно учитываю, что и канал очень-хороший и оборудование тоже. Вот в таком случае и можно применить потоков 500. Ну это я же опять всё для примера привел.
Блин, опять наверное все ещё больше запутал....
(2006-08-02 18:39:00) [17]Удалено модератором
DiamondShark (2006-08-02 18:00:00) [18]Что-то мне кажется, здесь каша понятий какая-то...
Зачем клиентскомуприложению такое количество потоков?
Что такое пул сокетов? Сокеты -- "одноразовые" объекты, после отключения их можно только уничтожить. Значит, фактически, пул подключений? Откуда такое количество подключений? Почему пул подключений противопоставляется использованию потоков?
Странное какое-то приложение...
Или терминология от общепринятой отличается.
| |
