Пожалуйста обьясните в чем разница в сокетах

← →
kopcap (2003-04-10 07:20) [0]

Пожалуйста обьясните в чем разница в следующих типах
TServerSocket.ServerType: stNonBlocking, stThreadBlocking
TClientSocket.ClientType: stNonBlocking, stBlocking
только пожалуйста, на надо посылать меня искать архивы или читать хелп, я там уже был и там ничего не написано в чем преимущества и недостатки в этих типах и почему.

← →
Digitman © (2003-04-10 08:31) [1]

TServerSocket.ServerType

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

2. stThreadBlocking - модель асинхронных нотификаций по-умолчанию отключена; обработка транспорта каждого из активных клиентов - в отдельном кодовом потоке; транспортные алгоритмы всех клиентов работают параллельно

TClientSocket.ClientType

1. stNonBlocking - по-умолчанию включена модель асинхронных нотификаций о событиях гнездового транспорта клиента; события возбуждаются в одном и тои же код.потоке (создавшем объект-гнездо); вызовы трансп.методов гнезда - неблокирующие

2. stBlocking - по-умолчанию отлючена модель асинхронных нотификаций о событиях гнездового транспорта клиента; события возбуждаются в одном и том же код.потоке (создавшем объект-гнездо); вызовы трансп.методов гнезда - блокирующие

← →
kopcap (2003-04-10 11:16) [2]

или дайте линк или пришлите пожалуйста доки на е-мейл, если есть

← →
kopcap (2003-04-10 11:26) [3]

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

← →
Digitman © (2003-04-10 13:24) [4]

> kopcap

у каждого режима каждого из этих объектов есть свои преимущества и недостатки... и рассматривать их нужно с т.з. лишь организации выч.процесса приложения как такового (и не более того !)

а на надежность связи выбор режима никак не влияет

← →
VID © (2003-04-10 13:57) [5]

сервер нельзя назвать надёжным когда он в режиме stNonBlocking

← →
Digitman © (2003-04-10 14:08) [6]

> VID

это почему же ?)

← →
Polevi © (2003-04-10 18:42) [7]

2VID © (10.04.03 13:57)
да, мне тоже интересно, почему

← →
VID © (2003-04-11 00:07) [8]

to Digitman, Polevi: потому что как ни крути, а при массовой атаке сервера (имеется ввиду например одновременный коннект к нему нескольких тысяч клиентов, да ещё и отправка ими какого-нибудь текста или других данных), поток в котором работает сервер (а чаще всего им является основноый поток приложения) будет практически заблокирован, во всяком случае сервер будет очень медленно работать для тех клиентов, которые легально на всех правах к нему подключились, и пытаются отправлять/принимать данные...
вот собственно и "почему". если я в чём то ошибаюсь, исправляйте, буду только рад :)

← →
Digitman © (2003-04-11 08:24) [9]

> во всяком случае сервер будет очень медленно работать для
> тех клиентов, которые легально на всех правах к нему подключились

а какое отношение все это имеет к "надежности" ? imho, совершенно никакого)

кр.того, "слушающее" гнездо имеет такое св-во как backlog - размер очереди буферизации вх.запросов на соединение. По-умолчанию, размер очереди = 5. Все остальные запросы получат "отлуп" - connection reject

← →
Digitman © (2003-04-11 09:07) [10]

> VID

и, по-моему, мы с тобой уже "обсасывали" этот вопрос)
задача защиты сервера от флуда, спама, QoS и прочей "хрени" - отнюдь не задача самого сервера... это - прерогатива файрвола

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

Сервер (XP, W2k) "умеет" делать условный акцепт вх.кл.запросов на соединение, но не знает, как отличить флудера от "честного" клиента (хотя, в принципе, его можно и этому научить). Файрвол же, в свою очередь, как правило, содержит интерактивно настраиваемый механизм блокировки спама/флуда (при установке блокировки IP-адрес (и некоторые прочие атрибуты) remote-"хулигана", как правило, известны). Достаточно "научить" файрвол передавать такую инф-цию (в виде некоего ignore-листа) серверу, а уж сервер, выполняя усл.акцепт, будет давать "отлуп" всем тем потенц.клиентам, о которых он извещен ignore-списком от файрвола

← →
kopcap (2003-04-11 11:09) [11]

Спасибо за ответы, буду использовать то, что более удобным покажется :)

← →
VID © (2003-04-11 11:19) [12]

to Digitman: backlog ? интересно, я про это никогда раньше не слышал.
Но всё таки, согласись, что блокирующий сервер, можно назвать более правильным решением нежели неблокирующий.
Само то что обслуживание всех клиентов будет происходить (или хотя бы начинаться) в одном и том же потоке, уже как то не так...

← →
VID © (2003-04-11 11:25) [13]

to kopcap: Поначалу то более удобным покажется stNonBlocking...
но вот не стоит всё таки на это клевать. Если твоя прога не будет выставлена на всеобщее обозрение, а будет использоваться лишь несколькими "культурными" людьми, то конечно можно оставить stNonBlocking
Если же есть вероятность того, что к твоему серверу кто угодно будет подключаться, то лучше начинать с stThreadBlocking...
Причём логика работы сервера когда он stNonBlocking заметно отличается от stThreadBlocking...
special to Digitman: Я в имею ввиду организацию транспорта, да и вообще написание кода :)

← →
Digitman © (2003-04-11 11:42) [14]

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

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

> Само то что обслуживание всех клиентов будет происходить
> (или хотя бы начинаться) в одном и том же потоке, уже как
> то не так...

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

← →
Digitman © (2003-04-11 11:46) [15]

> backlog ? интересно, я про это никогда раньше не слышал.

вот и мне интересно, как это ты, рассуждая на полном серьезе на эти темы, до сих пор не удосужился проанализировать текст серверного компонента в части вызова ф-ций listen()/accept()

← →
VID © (2003-04-11 12:20) [16]

to Digitman: дело в том что в последнее время (с октября прошлого года) я занимаюсь клиент-серверными базами данных, в этом плане я хотя бы достиг бОльших успехов чем в том же чате например...
А так, мне ж никто не запрещает высказывать свою т.з. если я не ознакомился с некоторыми материалами по теме...
как говориться, не все йогурты одинаковы :)

← →
Polevi © (2003-04-12 13:27) [17]

2VID © (11.04.03 12:20)
non-block режим сложнее программировать, зато он предоставляет большие возможности машстабируемости, включая порты завершения ввода вывода

← →
Дефлоратор (2003-04-14 15:58) [18]

Режим stNonBlocking действительно ненадёжен.
Я проверял, просто посылая строки с 10 клиентов серверу, а сервер отправлял каждую полученную стоку всем клиентам.
бывали случаи, когда строки просто сливались в одну.

← →
Digitman © (2003-04-14 16:45) [19]

> Дефлоратор

чушь ты городишь
читай http://book.itep.ru, раздел "Протокол TCP"

← →
VID © (2003-04-15 10:32) [20]

TO Дефлоратор: Это склеивание... это не то...
TO Digitman, Polevi: И всё равно, лучше делать блок сервер :)
Сами то небось только такие делаете )

← →
Digitman © (2003-04-15 10:57) [21]

> VID

Да пойми ты наконец, голова, что выбор того или иного режима зависит только от конкр.задач, возлагаемых на сервер, и никак не влияет на его "надежность" ! Гнездо остается гнездом в любом случае, меняется только модель нотификации.

Ведь если выбрать блок.режим, то вызов В ЛЮБОМ КОД.ПОТОКЕ транспортных и иных гнездовых ф-ций будет блокировать выполнение код.потока до возврата (успешного или неуспешного) из вызванных гнезд.ф-ций. Если в момент вызова требуется оперативная реакция код.потока (создавшего гнездо) на иные события/сообщения (не связанные с гнезд.транспортом), то выбор блок.режима неразумен, ибо в момент блокировки у даннного код.потока нет возможности ожидания/диспетчеризации/обработки этих событий/сообщений - он "встал" на исполнении блок.вызова !

← →
kopcap (2003-04-15 12:42) [22]

Как я понял из ваших сообщений(спасибо вам за это), хелпов, статей разница блок. и не блок. режимов заключается в том, что блок. режим блокирует выполнение приложения до отправки или приема всех данных и возникающими событиями при приеме/отправке данных. Так у меня появились еще несколько вопросов теоретического и практического характера:
1. Необязательно ли использовать на серверной и клиентских частях одинаковых режимов (в смысле оба блокир. или наоборот)?
2. При блокирующем режиме при отправке (например SendStream(MyStream)) программа полностью блокируется, можно ли этого как нибудь избежать? Можно ли получить текущий статус отправленных данных? Или же отправлять по кускам.
3. В кл. части при исп. ctBlocking событие onRead не происходит. Как сервер может может отправить сообщение клиенту? Или же Клиент отправ. и сразу же ждет ответа? Должен ли Клиент начать отправку данных сразу после соединения?
4. Если сервер stThreadBlocking, то он генерирует onWrite у клиента и клиент должен начать отправку только после этого?
5. TServerSocket и TClientSocket отличаются от стандартных Windows-овских сокетов или сделаны на их основе?
6. Блок. режим рекомндуем когда работа как при почтовом сервере(соединился, отправил и принял данные, отсоедилися)? А не-блок. режим как при чате(клиент соед., отправка данных по событию от пользователя)?

Если у кого-нибудь есть подробная информация об этом, то пожалуйста пришлите мне на E-Mail: kopcap@netmail.kg

← →
Fredericco © (2003-04-15 13:12) [23]

2 VID ©
У меня сервер должен обрабатывать большое количество пакетов от различных клиентов, и действительно если в процедуре чтения данных из сокета OnRead вызывать свои проц. функ. обработки данного пакета, то при больших количествах посылок, по крайней мере у меня, терялись некоторые пакеты. Так как я учусь на транспорте, первым моим желанием было разгрузить обработчик OnRead, что я и сделал. В ОнРид я лишь добавляю полученный текст и хэндл гнезда в массив. А потом первую запись этого массива обрабатываю в отдельном потоке и удаляю. Так же и на клиентской стороне. Работает как часы. Так что я пока не наблюдал ненадежной работы СерверСокета в не блок. режиме.

← →
Digitman © (2003-04-15 13:45) [24]

> kopcap

1. Необязательно. Выбор режимов на каждой из сторон - за тобой.

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

3. А откуда ему взяться-то, событию OnRead ? Это же - событие для асинхр.извещений ! А блок.режим не предусматривает таковых !
В синхронном (блокирующем) режиме ты в нужный тебе момент времени вызываешь любой из recv-методов/ф-ций и "висишь" на ней до тех пор, пока либо не будут приняты ВСЕ запрошенные тобой к приему данные либо не произойдет отказ транспортных механизмов соединения. То же самое касается и механизма установления коннекта, и lookup-механизма и работы с send-методами/ф-циями

4. Нет. Будучи в любом из режимов, сервер не генерирует никаких событий на стороне клиента. События сервера - это события только серверной стороны; равно как и события клиента - это события только кл.стороны.
В режиме stThreadBlocking cобытие OnClientWrite автоматически возникнет только в случае неперекрытия наследником TServerClientThread метода ClientExecute, событие это - искуственно (синхронно) генерируемое код.потоком и извещает серверную сторону лишь о том факте, что сервер с момента возникновения этого события волен в любой момент времени передать клиенту инф-цию по установленному активному соединению с ним (попросту - событие On[Client]Write есть сигнал готовности "передатчика" той стороны, на которой оно возникает, к передаче данных другой стороне)

5. Именно - на их основе. Эти компоненты - лишь удобная VCL-оболочка системного гнездового механизма.

6. Блок.режим рекомендуем, когда протокол инф.обмена между сервером и клиентом предусматривает четкую синхронизацию "запрос - ответ"

← →
sapsi (2003-04-15 16:30) [25]

Предложение по теме
ЗДесь (на сайте) давно выложен пример чата.
Но работает он весьма криво уже при 3 клиентах.
Проблемы как раз в том, что посылаемые строки склеиваются, перекрываются и т.п. Возникает путаница в списках юзеров, другие проблемы.
КТо-нибудь мог бы довести до ума этот код либо написать новый, а может код уже есть, в качестве примера того же чата, по которому наглядно можно было бы понять как работать с сокетами, в условиях, когда идет активный обмен сообщениями между клиентами?
Спасибо.

to Fredericco : создай 5000 клиентов
приконнекть всех к серверу
дай им команду слать какой нить текст на сервер
и посмотри что получиться с сервером...
Я тоже когда то так извращался...
Но дело в том, что стоит тебе хотя бы одну банальную строчку в ОнРиде написать, например S:=Socket.ReceivedText, то при вышеуказанной ситуации сервер будет неумолимо умирать...

to Digitman:
Блокирующим я называю режим stThreadBlocking
Разве кодовоый поток создавший сервер блокируется при таком режиме ? насколько мне известно, при коннекте клиента к серверу, работающему в таком режиме, для клиента создаётся поток, в котором в дальнейшем и будут обрабатываться все поступающие от клиента данные...
не понимаю, о какой блокировке код. потока, создавшего stThreadBlocking-сервер идёт речь ?
Объясни, плиз...

to sapsi: Если тебя интересует метод решения проблемы приходящих неполностью пакетов, или наоборот, пакетов, приходящих в склеенном виде, то тебе сюда:
http://delphibase.endimus.ru/?action=viewfunc&topic=nettransfer&id=10335
А вообще, я в своё время писал чат основанный на неблок. сокетах... В августе прошлого года

> VID

обрати внимание, что в имени идентификатора stThreadBlocking упоминается 2 слова : "thread" и "blocking".

"blocking" говорит о том, что каждое гнездо, созданное сервером для организации транп.канала с отдельным клиентом, по-умолчанию инициализируется им (сервером) для работы его (отдельного гнезда) в блок.режиме. Это говорит о том, что все lookup- и транспортно-диспетчесрские ф-ции/методы такого гнезда будут БЛОКИРОВАТЬ выполнение код.потока, вызывающего эти ф-ции/методы, вплоть до завершения (успешного или неуспешного) работы этих ф-ций/методов. Заметь, что на этом уровне вовсе не идет речи о том, КАКОЙ КОНКРЕТНО код.поток (основной или некий дополнительный) будет вызывать эти ф-ции/методы (и при этом блокироваться на время их выполнения) ! Ничто в принципе не мешает обращаться к ф-циям/методам блокирующего гнезда из любого код.потока (как основного, так и любого дополнительного, созданного при необходимости любым удобным способом)

"thread" же говорит о том, что для обращения к ф-циям/методам отдельного гнезда (как бы оно ни было инициализировано сервером по-умолчанию) сервер, имея соответствующий встроенный событийный и кэш-механизм, предлагает использовать доп.кодовый поток-"заготовку" - наследник класса TServerClientThread. Этот код.поток получает одним из параметров VCL-объект-гнездо класса TServerClientWinSocket, по-умолчанию инициализированное для работы в блок.режиме. Обращаясь в ходе инф.обмена к этому гнезду, доп.код.поток, естественно, будет блокироваться при вызове ф-ций/методов гнезда, не блокируя при этом выполнение прочих код.потоков серверного процесса, в т.ч. и в первую очередь - основного. Но поскольку сам этот код.поток все же блокируется при обращении к гнездовым ф-циям/методам, на время блокировки он не в состоянии оперативно реагировать ни на одно событие/сообщение, адресованное как ему, так и окнам, им открытым. Но ничто не мешает этому код.потоку изменить режим работы "своего" гнезда !! Несмотря на то, что изначально оно было создано сервером как блокирующее !! Достаточно вызвать одну из ф-ций WSAAsyncSelect/WSAEventSelect - и гнездо станет неблокирующим !! При этом код.поток приобретет как минимум одну ценную сособность - немедленно получать назад управление после вызовов ф-ций/методов гнезда и организовать цикл ожидания/приема/диспетчеризации/обработки событий/сообщений, ему адресованных, в т.ч. и в первую очередь - событий/сообщений гнезда, которое было переведено в режим работы с асинхронными нотификациями о результатах выполнения его ф-ций/методов.

to Digitman: отлично объяснил, спасибо :)
Вот об этом не думал: Но ничто не мешает этому код.потоку изменить режим работы "своего" гнезда !!

2 VID
Пробывал 300 клиентов. Каждый шлет 10000 пакетов сам себе через сервер. В теле пакета содержалась строка "Test Message N", где N номер клиента. Подсчитывал на клиентской стороне как правильно пришедшие пакеты, так и не правильные. Сервер при приеме склеивает/расклеивает сообщение, расшифровывает, выбирает адресата из списка подключенных клиентов и, если таковой найден, зашифровывает сообщение и отправляет его клиенту. Все клиенты получили по 10000 пакетов, которые и отправляли, чужих не было, через сервер прошло ровно 3000000 пакетов.

чудо из чудес !

to Fredericco: а как вело себя в это время (когда ты спамил его) приложение-сервер ? Отвечало на внешние события, типа мышкой там ткнуть что нибудь... ?

2VID © (16.04.03 17:12)
а почему бы ему не отвечать ?
скорость обмена данными по сети гораздо меньше чем между ячейками памяти :-)) - врядли очередь сообщения будет наполняться с большей скоростью, чем ты будешь выбирать их оттуда (хотя это зависит от кода обратчиков этих событий, которые должны отрабатывать как можно быстрее (что справедливо для любых асинхонных ф-ий, не обязательно связаных с winsock))

К тому же ничто не мешает вынести обработку асинхронных событий winsock в отдельный поток, создав в нем окно (если пользоваться WSAAsyncSelect), или Event в случае WSAEventSelect

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

В асинхронном варианте поток будет один, красота просто

> К тому же ничто не мешает вынести обработку асинхронных
> событий winsock в отдельный поток, создав в нем окно (если
> пользоваться WSAAsyncSelect), или Event в случае WSAEventSelect

соглашусь.
достаточно приемлемый вариант , сочетающий в себе простоту Non-Blocking-режима и распараллеливание потоков вычислений

To VID: Слегка тормозило. Мышь в порядке. Окно немного медленнее перерисовывалась, чем обычно. Но, в принципе, приемлемо. Остальные приложения работали как обычно.

Ну раз так, то похоже мне надо скачать файл hands_patch.sys
:)
to Fredericco: Не мог бы отправить код приложения - сервера (без exe файла) на vidsnap@mail.ru ? если это возможно конечно...

2 VID
Выслал. Лови!

Пожалуйста обьясните в чем разница в сокетах Найти похожие ветки