| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / 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
только пожалуйста, на надо посылать меня искать архивы или читать хелп, я там уже был и там ничего не написано в чем преимущества и недостатки в этих типах и почему.
VID (2003-04-11 12:20:00) [21]to Digitman: дело в том что в последнее время (с октября прошлого года) я занимаюсь клиент-серверными базами данных, в этом плане я хотя бы достиг бОльших успехов чем в том же чате например...
А так, мне ж никто не запрещает высказывать свою т.з. если я не ознакомился с некоторыми материалами по теме...
как говориться, не все йогурты одинаковы :)
Digitman (2003-04-11 11:46:00) [22]
> backlog ? интересно, я про это никогда раньше не слышал.
вот и мне интересно, как это ты, рассуждая на полном серьезе на эти темы, до сих пор не удосужился проанализировать текст серверного компонента в части вызова ф-ций listen()/accept()
Digitman (2003-04-11 11:42:00) [23]
> согласись, что блокирующий сервер, можно назвать более правильным
> решением нежели неблокирующий
не соглашусь.
потому что конкретная организация выч.процесса на стороне сервера оч сильно зависит от задач, им решаемых
> Само то что обслуживание всех клиентов будет происходить
> (или хотя бы начинаться) в одном и том же потоке, уже как
> то не так...
если ты, используя неблок. однопоточный режим, не предусмотрел или не расчитал (во взаимосвязи с конкр. протоколом ИО) реальной задержки, вносимой телами различных обработчиков событий - это твоя проблема как программиста, а не проблема сервера)
VID (2003-04-11 11:25:00) [24]to kopcap: Поначалу то более удобным покажется stNonBlocking...
но вот не стоит всё таки на это клевать. Если твоя прога не будет выставлена на всеобщее обозрение, а будет использоваться лишь несколькими "культурными" людьми, то конечно можно оставить stNonBlocking
Если же есть вероятность того, что к твоему серверу кто угодно будет подключаться, то лучше начинать с stThreadBlocking...
Причём логика работы сервера когда он stNonBlocking заметно отличается от stThreadBlocking...
special to Digitman: Я в имею ввиду организацию транспорта, да и вообще написание кода :)
VID (2003-04-11 11:19:00) [25]to Digitman: backlog ? интересно, я про это никогда раньше не слышал.
Но всё таки, согласись, что блокирующий сервер, можно назвать более правильным решением нежели неблокирующий.
Само то что обслуживание всех клиентов будет происходить (или хотя бы начинаться) в одном и том же потоке, уже как то не так...
kopcap (2003-04-11 11:09:00) [26]Спасибо за ответы, буду использовать то, что более удобным покажется :)
Digitman (2003-04-11 09:07:00) [27]
> VID
и, по-моему, мы с тобой уже "обсасывали" этот вопрос)
задача защиты сервера от флуда, спама, QoS и прочей "хрени" - отнюдь не задача самого сервера... это - прерогатива файрвола
единственное, что может объединять сервер и файрвол в борьбе за право "честного" клиента быть обслуженным быстро и качественно - это потенциальная организация взаимодействия файрвола и сервера.
Сервер (XP, W2k) "умеет" делать условный акцепт вх.кл.запросов на соединение, но не знает, как отличить флудера от "честного" клиента (хотя, в принципе, его можно и этому научить). Файрвол же, в свою очередь, как правило, содержит интерактивно настраиваемый механизм блокировки спама/флуда (при установке блокировки IP-адрес (и некоторые прочие атрибуты) remote-"хулигана", как правило, известны). Достаточно "научить" файрвол передавать такую инф-цию (в виде некоего ignore-листа) серверу, а уж сервер, выполняя усл.акцепт, будет давать "отлуп" всем тем потенц.клиентам, о которых он извещен ignore-списком от файрвола
Digitman (2003-04-11 08:24:00) [28]
> во всяком случае сервер будет очень медленно работать для
> тех клиентов, которые легально на всех правах к нему подключились
а какое отношение все это имеет к "надежности" ? imho, совершенно никакого)
кр.того, "слушающее" гнездо имеет такое св-во как backlog - размер очереди буферизации вх.запросов на соединение. По-умолчанию, размер очереди = 5. Все остальные запросы получат "отлуп" - connection reject
VID (2003-04-11 00:07:00) [29]to Digitman, Polevi: потому что как ни крути, а при массовой атаке сервера (имеется ввиду например одновременный коннект к нему нескольких тысяч клиентов, да ещё и отправка ими какого-нибудь текста или других данных), поток в котором работает сервер (а чаще всего им является основноый поток приложения) будет практически заблокирован, во всяком случае сервер будет очень медленно работать для тех клиентов, которые легально на всех правах к нему подключились, и пытаются отправлять/принимать данные...
вот собственно и "почему". если я в чём то ошибаюсь, исправляйте, буду только рад :)
Polevi (2003-04-10 18:42:00) [30]2VID © (10.04.03 13:57)
да, мне тоже интересно, почему
Digitman (2003-04-10 14:08:00) [31]
> VID
это почему же ?)
VID (2003-04-10 13:57:00) [32]сервер нельзя назвать надёжным когда он в режиме stNonBlocking
Digitman (2003-04-10 13:24:00) [33]
> kopcap
у каждого режима каждого из этих объектов есть свои преимущества и недостатки... и рассматривать их нужно с т.з. лишь организации выч.процесса приложения как такового (и не более того !)
а на надежность связи выбор режима никак не влияет
kopcap (2003-04-10 11:26:00) [34]Спасибо Digitman, но в чем примущества? Мне нужно написать прогу для обмена файлами между компами через интернет и не знаю что выбрать. Мне нужна связь понадежнее
kopcap (2003-04-10 11:16:00) [35]или дайте линк или пришлите пожалуйста доки на е-мейл, если есть
Digitman (2003-04-10 08:31:00) [36]TServerSocket.ServerType
1. stNonBlocking - по-умолчанию включена модель асинхронных нотификаций о событиях гнездового транспорта; обработка транспортных событий для всех активных клиентов - однопоточная, последовательная
2. stThreadBlocking - модель асинхронных нотификаций по-умолчанию отключена; обработка транспорта каждого из активных клиентов - в отдельном кодовом потоке; транспортные алгоритмы всех клиентов работают параллельно
TClientSocket.ClientType
1. stNonBlocking - по-умолчанию включена модель асинхронных нотификаций о событиях гнездового транспорта клиента; события возбуждаются в одном и тои же код.потоке (создавшем объект-гнездо); вызовы трансп.методов гнезда - неблокирующие
2. stBlocking - по-умолчанию отлючена модель асинхронных нотификаций о событиях гнездового транспорта клиента; события возбуждаются в одном и том же код.потоке (создавшем объект-гнездо); вызовы трансп.методов гнезда - блокирующие
| |
Страницы: 