|
|
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) AkhБлокирующий сокет.ичо, поймал уведомление в неблокирующем select-е и читай его блокирующими вызовами наздаровье Я и говорю, что вышеуказанное верно для блокирующего сокета. Речь шла про connect. Не блокирующий сокет вернет errno, что пока сервер не готов. Кстати, если реализовывать в одном потоке с каллбаками по сокетам, то, считаю, что блокировать его потом не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:44 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) onstat-Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. гнать фшею такого разработчика. Можно на время connect-а сделать сокет неблокирующим, потом восстановить флажок и ждать соединения на select-е. Этот случай также описан в популярной литературе :) Согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:45 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat-...Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. немного лирики...тьху определений... Сервер - тот кто предоставляет услуги в сети... Клиент - тот кто использует эти услуги. всё, другого нема..хотите этого Вы или нет... Посему любая станция или группа станций может выступать как сервер(а) так и клиенты(ом). Но (!) тут есть маленьчкий нюанс (точнее их гораздо больше, но опустим) - сервер должен предвидеть все те ситуации в которые его может загнать клиент(ы)... Посему не совсем правильно не прокачав эти аспекты делать из клиента сервер (например).. сервер в клиента - это наверное просче, тут затрагиваются в основном проблемы секьюритей и скорострельности.... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 13:30 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
White OwlНу отлаживать то как раз проще когда только один поток :)Приложение все равно многопоточное получается, пользовательский интерфейс все равно в своем потоке. Так что я отлаживаюсь пока как 1+1 поток. 1 интерфейс, 1 задача. onstat-Если эта задержка не напрягает то можно и в один.Напрягает. Очень. Gluk (Kazan)мы вроде об сервере ? какие нафих connect-ы ???Разные. И connect-ы, и accept-ы... Например, тот же SMTP, или FTP сервер обязаны уметь связываться сами. AkhКстати, если реализовывать в одном потоке с каллбаками по сокетам, то, считаю, что блокировать его потом не стоит.А неблокирующие сокеты будут кушать не меньше ресурсов, чем потоки. Если, конечно, потокам не выдавать по мегабайту стека. Gluk (Kazan)гнать фшею такого разработчика. Можно на время connect-а сделать сокет неблокирующим, потом восстановить флажок и ждать соединения на select-е. Этот случай также описан в популярной литературе :)А еще в популярной литературе инопланетян описывают... О! Давайте все хором выгоним "фшею" всех разработчиков SQL, FTP, SMTP, POP3 и проч, и проч... kolobok0Посему любая станция или группа станций может выступать как сервер(а) так и клиенты(ом). А также и отдельно взятая программа. kolobok0сервер в клиента - это наверное просче, тут затрагиваются в основном проблемы секьюритей и скорострельности.... Сервер и клиент - разные вещи. Сервер к примеру должен быть устойчивым и надежным. Ну, по возможности еще и быстрым. Но он не обязан быть таким же умным как клиент. Я не имею сейчас в виду что-то типа SQL сервера... Возьмем, к примеру тот же самый FTP сервер. Ну отправил клиент ему запрос с лишним пробелом на конце. Сервер не обязан при этом его отработать. Вернет ошибку, и делов-то... А клиент обязан разбирать его ответы, парсить текстовые строки, и т.д. и т.п. В случае FTP, или скажем, POP3 протоколов серверы выглядят куда более простыми, нежели клиенты. Все дальнейшее усложнение сервера - это повышение надежности, скорости и управляемости. Просто путь от запорожца к мерседесу. Но колес - все равно столько же, и водитель-клиент этого сервера-мерседеса все равно должен лучше знать, куда рулить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 14:20 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik Gluk (Kazan) Этот случай также описан в популярной литературе :)А еще в популярной литературе инопланетян описывают... О! Давайте все хором выгоним "фшею" всех разработчиков SQL, FTP, SMTP, POP3 и проч, и проч... Макарчик, не слишком ли ты многословен, для человека задающего вопрос ? Не нравится запах - не нюхай (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:01 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Макарчик, не слишком ли ты многословен, для человека задающего вопрос ?Ок. Отлично. Ты вопрос-то читал? Перечитай... И свои ответы на него тоже... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:07 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik Gluk (Kazan)Макарчик, не слишком ли ты многословен, для человека задающего вопрос ?Ок. Отлично. Ты вопрос-то читал? Перечитай... И свои ответы на него тоже... спасибо, не интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:35 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik....Сервер и клиент - разные вещи.... истина...одобрям... Makar4ik...Сервер к примеру должен быть устойчивым и надежным. Ну, по возможности еще и быстрым. Но он не обязан быть таким же умным как клиент.... простите Вы противоречите определению - см. выше.. в топку... Или по другому, я наверное открою серкет, но кс решения нуна не только в плоскости умный-быстрый смотреть...Иначе Вам потребуется удача Makar4ik...Я не имею сейчас в виду что-то типа SQL сервера...... на самом деле пофигу что брать... у сиквол сервака кто есть клиент ? прально - его драйвер... весь ум которого заключается в сравнении типов, имён и преобразование к типам того языка под которым он лежит... Makar4ik...Возьмем, к примеру тот же самый FTP сервер.Ну отправил клиент ему запрос с лишним пробелом на конце.Сервер не обязан при этом его отработать. Вернет ошибку, и делов-то...А клиент обязан разбирать его ответы, парсить текстовые строки, и т.д. и т.п.В случае FTP, или скажем, POP3 протоколов серверы выглядят куда более простыми, нежели клиенты....... возьмём.. эххх...я наверное открою большой секрет - но что и кто должен делать те или иные действия определяемые задачей - увы и ах ни каким рэксом не связаны со стороной их обработки.. Не конечно же связаны, но(!) и это очень важно(!!!) НЕТ ШАБЛОННЫХ РЕШЕНИЙ(!!!) вдумайтесь... и прочитайте ышо раз то, что Вы написали постом выше... Поясню... Например у нас один клиент и один сервер (почему бы и нет?) ... Задачи сервака тупо отрабатывать как мона скорее рядом с хранилищем данных (ну задача такая к примеру) - либо на не стандартном железе (пущай будет at89c51rc - это такой МК)...Работу связанную с проверкой формата мы можем водрузить на клиента ? а почему бы и нет ? Кто запретил ? И продолжаем экспиримёнт.. увеличиваем кол-во клиентов...Опс...тут уже всем становиться понятно, что сервак без проверки формата запроса - мягко говоря не жизненное решение...Значит функционал поехал на сервак... надеюсь кривой пример пояснил мою предыдущую мыслю... Makar4ik..Все дальнейшее усложнение сервера - это повышение надежности, скорости и управляемости. Просто путь от запорожца к мерседесу. Но колес - все равно столько же, и водитель-клиент этого сервера-мерседеса все равно должен лучше знать, куда рулить... ну это заблуждение... например берём клиентов со стандартизированным шлюзом(интерфейсом) ну какой нить IE броузер к вэб сервакам..И шо мы видим ? А ничего.. Плевал(и правильно делал в рамках поставленной задачи) клиент на управляемость сервера !!!! с уважением (круглый) ЗЫ Понимаете ли в чём дело мил человек... КС системы тем и хороши, что догм нет...И это НЕТ идёт от определения...см. выше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:39 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=34043773&tid=2030323]: |
0ms |
get settings: |
5ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
384ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 673ms |

| 0 / 0 |
