TWSocket пул сокетов

← →
mnm (2006-08-02 17:38) [0]

Интересует, как необходимо правильно организовывать клиентское много-поточное приложение (потоков до тысячи допустим), не хочу применять потоки-Threads, хочется сделать пул сокетов. Читал про подобное при конструировании сервера на чистом winsock"ете, с использованием пула сокетов.

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

← →
DiamondShark © (2006-08-02 18:00) [1]

Что-то мне кажется, здесь каша понятий какая-то...

Зачем клиентскому приложению такое количество потоков?

Что такое пул сокетов? Сокеты -- "одноразовые" объекты, после отключения их можно только уничтожить. Значит, фактически, пул подключений? Откуда такое количество подключений? Почему пул подключений противопоставляется использованию потоков?

Странное какое-то приложение...
Или терминология от общепринятой отличается.

← →
имя (2006-08-02 18:39) [2]

Удалено модератором

← →
mnm (2006-08-02 19:21) [3]

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

Как организовать многопоточность (я не говорю про именно многопоточность по tthread / createthread, просто употребляю этот термин как одновременное кол-во объектов работающих с сетью), не прибегая к использованию встроенной в винду потоковой (createthread / tthread - delphi) технологии, на TWSocket.

Пример, где я напрмер встетил похожую реализацию но на чистом winsockete. http://delphiworld.narod.ru/base/sockets3.html

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

Блин, опять наверное все ещё больше запутал....

← →
mnm (2006-08-02 19:58) [4]

Вот к примеру, если меня не поняли, ещё одно упоминание о моей идеи вот тут http://www.xakep.ru/post/14087/default.asp

← →
Сергей М. © (2006-08-03 08:20) [5]

> mnm

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

← →
Rouse_ © (2006-08-03 11:23) [6]

Боюсь что select не потянет сразу 500 гнезд :)

← →
Сергей М. © (2006-08-03 11:29) [7]

А и не надо select)

На то, сам понимаешь, есть WSAAsyncSelect/WSAEventSelect

Правда, в случае с WSAEventSelect засада будет в другом месте - придется разруливать ситуацию с системным ограничением кол-ва ивентов, передаваемых на вход wait-функций

← →
Rouse_ © (2006-08-03 11:38) [8]

Я кстати тоже про WSAAsyncSelect подумал, надо будет на досуге поэксперементировать, сколько он сможет выдержать :)

← →
Сергей М. © (2006-08-03 11:44) [9]

> Rouse_ © (03.08.06 11:38) [8]

А ему не надо ничего держать)
Он же просто переводит указанное гнездо в неблок.режим с оконными нотификациями, т.е. говорит одному конкретному гнезду, мол, отныне при таких-то транспортных событиях посылай такое-то сообщение такому-то окну.

← →
Rouse_ © (2006-08-03 11:45) [10]

Ну да :) Я в плане системных ограничений :)

← →
Сергей М. © (2006-08-03 11:57) [11]

Ну у каждой системы они свои ..
Здесь следует больше волноваться за то, сколько гнезд при этом может существовать одновременно. Гнездо же, по сути, представлено в памяти некой внутренней структурой, с которой ассоциирован хэндл этого гнезда. А память она не резиновая).. Кр.того, ограничены иные ресурсы как процесса, так и системы в целом..

← →
mnm (2006-08-03 12:31) [12]

Спасибо, что поняли мою идею :) Ну на голом winsocket"e я уже немного представляю как такое реализовать, но вопрос мой про реализацию этой же идеи, но с помощью TWSocket (ICS, www.overbyte.be/eng/products/ics.html). Есть идеи? Я просто не очень предстаялю как с ним такое осуществить.

А чем стандартные TClientSocket и TTCPClient не угодили ?

← →
mnm (2006-08-03 12:56) [14]

Ну а если можно с ним (TClientSocket и TTCPClient), пример небольшой привести. Я не понимаю, как использовать компонент/класс в моей идеи. Т.е. при использовании чистого TSocket, всё более менее чуть-чуть внятно. Что делать в случае с TClientSocket и TTCPClient, я хоть убейте за мою тупость не пойму?

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 13:28) [16]

Сергей М., спасибо большое, я так и думал приблизительно, только сомневался в правильности и надежности при большом количестве объектов в массиве. Сейчас посмотрел TTCPCLient, обнаружил в нем BlockMode, то бишь возможность использования блокирующего/не блокирующего режима и не пойму сейчас, а какое поведение будет у такого массива, при использовании блокирующего или не блокирующего? Я понимаю разницу между блокирующем и не блокирующим, но как тут это будет отражаться -- не понимаю.

> mnm (03.08.06 13:28) [16]

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

TTCPCLient в неблок.режиме, пожалуй, даже более удачным решением будет - там событийный механиз получше продуман, да и методы SendLn()/ReceiveLn() по их внутренней логике будут более подходящими для простого обмена строками текста с HTTP-прокси-сервером.

Блокирующий же режим не годится по условию - для этого придется создавать доп.потоки, что нежелательно и вряд ли оправдано в решении данной задачи.

> какое поведение будет у такого массива

У массива нет и не может быть "поведения", он просто хранит ссылки на созданные сокетные объекты для их последующего уничтожения и быстрого доступа к конкретным объектам по их индексу в массиве.

Обработчики событий для всех объектов в массиве единые и устанавливаются однократно сразу после создания объектов.

> mnm

Наверно, еще одним не худшим решением будет использовать (в кач-ве альтернативы TClientSocket и TTCPClient) компонент TApdWinsockPort в составе TurboPower AsyncPro. Если мне не изменяет память, там тоже реализован неблок.режим, к тому же имеются св-ва/методы/события, ощутимо упрощающие обмен по прикладному протоколу инф.обмена с партнером.

TWSocket пул сокетов Найти похожие ветки