| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Пожалуйста обьясните в чем разница в сокетах
kopcap © (2003-04-10 07:20:00)Пожалуйста обьясните в чем разница в следующих типах
TServerSocket.ServerType: stNonBlocking, stThreadBlocking
TClientSocket.ClientType: stNonBlocking, stBlocking
только пожалуйста, на надо посылать меня искать архивы или читать хелп, я там уже был и там ничего не написано в чем преимущества и недостатки в этих типах и почему.
Fredericco (2003-04-18 10:55:00) [1]2 VID
Выслал. Лови!
VID (2003-04-17 18:29:00) [2]Ну раз так, то похоже мне надо скачать файл hands_patch.sys
:)
to Fredericco: Не мог бы отправить код приложения - сервера (без exe файла) на vidsnap@mail.ru ? если это возможно конечно...
Fredericco (2003-04-17 14:24:00) [3]To VID: Слегка тормозило. Мышь в порядке. Окно немного медленнее перерисовывалась, чем обычно. Но, в принципе, приемлемо. Остальные приложения работали как обычно.
Digitman (2003-04-17 14:08:00) [4]
> К тому же ничто не мешает вынести обработку асинхронных
> событий winsock в отдельный поток, создав в нем окно (если
> пользоваться WSAAsyncSelect), или Event в случае WSAEventSelect
соглашусь.
достаточно приемлемый вариант , сочетающий в себе простоту Non-Blocking-режима и распараллеливание потоков вычислений
Polevi (2003-04-16 18:46:00) [5]2VID © (16.04.03 17:12)
а почему бы ему не отвечать ?
скорость обмена данными по сети гораздо меньше чем между ячейками памяти :-)) - врядли очередь сообщения будет наполняться с большей скоростью, чем ты будешь выбирать их оттуда (хотя это зависит от кода обратчиков этих событий, которые должны отрабатывать как можно быстрее (что справедливо для любых асинхонных ф-ий, не обязательно связаных с winsock))
К тому же ничто не мешает вынести обработку асинхронных событий winsock в отдельный поток, создав в нем окно (если пользоваться WSAAsyncSelect), или Event в случае WSAEventSelect
Ты пойми, в твоем случае на каждого клиента будет создан програмный поток, и программа большую часть времени будет переключать контексты потоков (эта операция требует некоторого времени), а процесс создания потока вообще "тяжел" для ОС
В асинхронном варианте поток будет один, красота просто
VID (2003-04-16 17:12:00) [6]to Fredericco: а как вело себя в это время (когда ты спамил его) приложение-сервер ? Отвечало на внешние события, типа мышкой там ткнуть что нибудь... ?
Polevi (2003-04-16 13:46:00) [7]чудо из чудес !
Fredericco (2003-04-16 12:59:00) [8]2 VID
Пробывал 300 клиентов. Каждый шлет 10000 пакетов сам себе через сервер. В теле пакета содержалась строка "Test Message N", где N номер клиента. Подсчитывал на клиентской стороне как правильно пришедшие пакеты, так и не правильные. Сервер при приеме склеивает/расклеивает сообщение, расшифровывает, выбирает адресата из списка подключенных клиентов и, если таковой найден, зашифровывает сообщение и отправляет его клиенту. Все клиенты получили по 10000 пакетов, которые и отправляли, чужих не было, через сервер прошло ровно 3000000 пакетов.
VID (2003-04-16 10:59:00) [9]to Digitman: отлично объяснил, спасибо :)
Вот об этом не думал: Но ничто не мешает этому код.потоку изменить режим работы "своего" гнезда !!
Digitman (2003-04-16 09:17:00) [10]
> VID
обрати внимание, что в имени идентификатора stThreadBlocking упоминается 2 слова : "thread" и "blocking".
"blocking" говорит о том, что каждое гнездо, созданное сервером для организации транп.канала с отдельным клиентом, по-умолчанию инициализируется им (сервером) для работы его (отдельного гнезда) в блок.режиме. Это говорит о том, что все lookup- и транспортно-диспетчесрские ф-ции/методы такого гнезда будут БЛОКИРОВАТЬ выполнение код.потока, вызывающего эти ф-ции/методы, вплоть до завершения (успешного или неуспешного) работы этих ф-ций/методов. Заметь, что на этом уровне вовсе не идет речи о том, КАКОЙ КОНКРЕТНО код.поток (основной или некий дополнительный) будет вызывать эти ф-ции/методы (и при этом блокироваться на время их выполнения) ! Ничто в принципе не мешает обращаться к ф-циям/методам блокирующего гнезда из любого код.потока (как основного, так и любого дополнительного, созданного при необходимости любым удобным способом)
"thread" же говорит о том, что для обращения к ф-циям/методам отдельного гнезда (как бы оно ни было инициализировано сервером по-умолчанию) сервер, имея соответствующий встроенный событийный и кэш-механизм, предлагает использовать доп.кодовый поток-"заготовку" - наследник класса TServerClientThread. Этот код.поток получает одним из параметров VCL-объект-гнездо класса TServerClientWinSocket, по-умолчанию инициализированное для работы в блок.режиме. Обращаясь в ходе инф.обмена к этому гнезду, доп.код.поток, естественно, будет блокироваться при вызове ф-ций/методов гнезда, не блокируя при этом выполнение прочих код.потоков серверного процесса, в т.ч. и в первую очередь - основного. Но поскольку сам этот код.поток все же блокируется при обращении к гнездовым ф-циям/методам, на время блокировки он не в состоянии оперативно реагировать ни на одно событие/сообщение, адресованное как ему, так и окнам, им открытым. Но ничто не мешает этому код.потоку изменить режим работы "своего" гнезда !! Несмотря на то, что изначально оно было создано сервером как блокирующее !! Достаточно вызвать одну из ф-ций WSAAsyncSelect/WSAEventSelect - и гнездо станет неблокирующим !! При этом код.поток приобретет как минимум одну ценную сособность - немедленно получать назад управление после вызовов ф-ций/методов гнезда и организовать цикл ожидания/приема/диспетчеризации/обработки событий/сообщений, ему адресованных, в т.ч. и в первую очередь - событий/сообщений гнезда, которое было переведено в режим работы с асинхронными нотификациями о результатах выполнения его ф-ций/методов.
VID (2003-04-15 19:54:00) [11]to Fredericco : создай 5000 клиентов
приконнекть всех к серверу
дай им команду слать какой нить текст на сервер
и посмотри что получиться с сервером...
Я тоже когда то так извращался...
Но дело в том, что стоит тебе хотя бы одну банальную строчку в ОнРиде написать, например S:=Socket.ReceivedText, то при вышеуказанной ситуации сервер будет неумолимо умирать...
to Digitman:
Блокирующим я называю режим stThreadBlocking
Разве кодовоый поток создавший сервер блокируется при таком режиме ? насколько мне известно, при коннекте клиента к серверу, работающему в таком режиме, для клиента создаётся поток, в котором в дальнейшем и будут обрабатываться все поступающие от клиента данные...
не понимаю, о какой блокировке код. потока, создавшего stThreadBlocking-сервер идёт речь ?
Объясни, плиз...
to sapsi: Если тебя интересует метод решения проблемы приходящих неполностью пакетов, или наоборот, пакетов, приходящих в склеенном виде, то тебе сюда:
http://delphibase.endimus.ru/?action=viewfunc&topic=nettransfer&id=10335
А вообще, я в своё время писал чат основанный на неблок. сокетах... В августе прошлого года
sapsi (2003-04-15 16:30:00) [12]Предложение по теме
ЗДесь (на сайте) давно выложен пример чата.
Но работает он весьма криво уже при 3 клиентах.
Проблемы как раз в том, что посылаемые строки склеиваются, перекрываются и т.п. Возникает путаница в списках юзеров, другие проблемы.
КТо-нибудь мог бы довести до ума этот код либо написать новый, а может код уже есть, в качестве примера того же чата, по которому наглядно можно было бы понять как работать с сокетами, в условиях, когда идет активный обмен сообщениями между клиентами?
Спасибо.
Digitman (2003-04-15 13:45:00) [13]
> kopcap
1. Необязательно. Выбор режимов на каждой из сторон - за тобой.
2. На то и блок.режим, чтобы ф-ция возвратила управление либо после полного и успешного завершения либо при первом же отказе в ее теле. Та же ф-ция, будучи вызванной в неблок. режиме, немедленно вернет управление вызывающему код.потоку сразу после ее вызова, а о результатах успешного либо неуспешного фактического завершения ты будешь извещен асинхронно в одном из соотв.событий, которые сгенерирует для тебя Winsock
3. А откуда ему взяться-то, событию OnRead ? Это же - событие для асинхр.извещений ! А блок.режим не предусматривает таковых !
В синхронном (блокирующем) режиме ты в нужный тебе момент времени вызываешь любой из recv-методов/ф-ций и "висишь" на ней до тех пор, пока либо не будут приняты ВСЕ запрошенные тобой к приему данные либо не произойдет отказ транспортных механизмов соединения. То же самое касается и механизма установления коннекта, и lookup-механизма и работы с send-методами/ф-циями
4. Нет. Будучи в любом из режимов, сервер не генерирует никаких событий на стороне клиента. События сервера - это события только серверной стороны; равно как и события клиента - это события только кл.стороны.
В режиме stThreadBlocking cобытие OnClientWrite автоматически возникнет только в случае неперекрытия наследником TServerClientThread метода ClientExecute, событие это - искуственно (синхронно) генерируемое код.потоком и извещает серверную сторону лишь о том факте, что сервер с момента возникновения этого события волен в любой момент времени передать клиенту инф-цию по установленному активному соединению с ним (попросту - событие On[Client]Write есть сигнал готовности "передатчика" той стороны, на которой оно возникает, к передаче данных другой стороне)
5. Именно - на их основе. Эти компоненты - лишь удобная VCL-оболочка системного гнездового механизма.
6. Блок.режим рекомендуем, когда протокол инф.обмена между сервером и клиентом предусматривает четкую синхронизацию "запрос - ответ"
Fredericco (2003-04-15 13:12:00) [14]2 VID ©
У меня сервер должен обрабатывать большое количество пакетов от различных клиентов, и действительно еслив процедуре чтения данных из сокета OnRead вызывать свои проц. функ. обработки данного пакета, то при больших количествах посылок, по крайней мере у меня, терялись некоторые пакеты. Так как я учусь на транспорте, первым моим желанием было разгрузить обработчик OnRead, что я и сделал. В ОнРид я лишь добавляю полученный текст и хэндл гнезда в массив. А потом первую запись этого массива обрабатываю в отдельном потоке и удаляю. Так же и на клиентской стороне. Работает как часы. Так что я пока не наблюдал ненадежной работы СерверСокета в не блок. режиме.
kopcap (2003-04-15 12:42:00) [15]Как я понял из ваших сообщений(спасибо вам за это), хелпов, статей разница блок. и не блок. режимов заключается в том, что блок. режим блокирует выполнение приложения до отправки или приема всех данных и возникающими событиями при приеме/отправке данных. Так у меня появились еще несколько вопросов теоретического и практического характера:
1. Необязательно ли использовать на серверной и клиентских частях одинаковых режимов (в смысле оба блокир. или наоборот)?
2. При блокирующем режиме при отправке (например SendStream(MyStream)) программа полностью блокируется, можно ли этого как нибудь избежать? Можно ли получить текущий статус отправленных данных? Или же отправлять по кускам.
3. В кл. части при исп. ctBlocking событие onRead не происходит. Как сервер может может отправить сообщение клиенту? Или же Клиент отправ. и сразу же ждет ответа? Должен ли Клиент начать отправку данных сразу после соединения?
4. Если сервер stThreadBlocking, то он генерирует onWrite у клиента и клиент должен начать отправку только после этого?
5. TServerSocket и TClientSocket отличаются от стандартных Windows-овских сокетов или сделаны на их основе?
6. Блок. режим рекомндуем когда работа как при почтовом сервере(соединился, отправил и принял данные, отсоедилися)? А не-блок. режим как при чате(клиент соед., отправка данных по событию от пользователя)?
Если у кого-нибудь есть подробная информация об этом, то пожалуйста пришлите мне на E-Mail: kopcap@netmail.kg
Digitman (2003-04-15 10:57:00) [16]
> VID
Да пойми ты наконец, голова, что выбор того или иного режима зависит только от конкр.задач, возлагаемых на сервер, и никак не влияет на его "надежность" ! Гнездо остается гнездом в любом случае, меняется только модель нотификации.
Ведь если выбрать блок.режим, то вызов В ЛЮБОМ КОД.ПОТОКЕ транспортных и иных гнездовых ф-ций будет блокировать выполнение код.потока до возврата (успешного или неуспешного) из вызванных гнезд.ф-ций. Если в момент вызова требуется оперативная реакция код.потока (создавшего гнездо) на иные события/сообщения (не связанные с гнезд.транспортом), то выбор блок.режима неразумен, ибо в момент блокировки у даннного код.потока нет возможности ожидания/диспетчеризации/обработки этих событий/сообщений - он "встал" на исполнении блок.вызова !
VID (2003-04-15 10:32:00) [17]TO Дефлоратор: Это склеивание... это не то...
TO Digitman, Polevi: И всё равно, лучше делать блок сервер :)
Сами то небось только такие делаете )
Digitman (2003-04-14 16:45:00) [18]
> Дефлоратор
чушь ты городишь
читай http://book.itep.ru, раздел "Протокол TCP"
Дефлоратор (2003-04-14 15:58:00) [19]Режим stNonBlocking действительно ненадёжен.
Я проверял, просто посылая строки с 10 клиентов серверу, а сервер отправлял каждую полученную стоку всем клиентам.
бывали случаи, когда строки просто сливались в одну.
Polevi (2003-04-12 13:27:00) [20]2VID © (11.04.03 12:20)
non-block режим сложнее программировать, зато он предоставляет большие возможности машстабируемости, включая порты завершения ввода вывода
| |
Страницы: 