Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.97.9.175] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Всем привет!
Часто возникает ситуация, когда одна из сторон (клиент или/и сервер) долго обрабатывают поставленную задачу. Стандартный способ - использование тайм-аутов. Но тут тоже есть минус - как определить "достаточность" тайм-аута. Возникла мысль, а что если сделать два соединения. Одно, собственно, рабочее, в второе - "типа для проверки". Сценарий примерно следующий. По первому соединению идет постановка задачи и ожидание ответа. Второе соединение раз в промежуток времени опрашивает вторую сторону "мол жив здоров?". Ответом должно быть нечто "Ok <цифра>". Под цифрой можно понимать разное, например, текущий счетчик итераций, процент выполнения, если это считаемо, может еще чего. Естественно, если по второму соединению нет ответа за уже конечный тайм-аут, значит что-то пошло не так. И тогда оба соединения закрываются принудительно. Ваши мысли? Плюсы? Минусы? |
Сообщ.
#2
,
|
|
|
В общем идея здравая и имеет право на жизнь...после тестирования
Вот тогда плюсы и минусы всплывут сами... |
Сообщ.
#3
,
|
|
|
На обработчике в любом случае придётся запускать новый поток для чтения второго коннекта. Тогда уж лучше сам запрос выполнять асинхронно, и контролировать его выполнение по тому же коннекту, по которому пришёл запрос. Всё равно, по-хорошему, надо из него вычитывать данные, чтобы не было переполнения буфера.
|
Сообщ.
#4
,
|
|
|
Цитата Олег М @ На обработчике в любом случае придётся запускать новый поток для чтения второго коннекта. Тогда уж лучше сам запрос выполнять асинхронно, и контролировать его выполнение по тому же коннекту, по которому пришёл запрос. Всё равно, по-хорошему, надо из него вычитывать данные, чтобы не было переполнения буфера. Увы, сетевым программированием я ранее не занимался. Пока почитываю материалы в сети. Запомнилось одно утверждение "если есть возможность в архитектуре приложения использовать блокируемые сокеты, то лучше использовать их, а не неблокируемые". Правильно ли это? |
Сообщ.
#5
,
|
|
|
Цитата JoeUser @ Увы, сетевым программированием я ранее не занимался. Пока почитываю материалы в сети. Запомнилось одно утверждение "если есть возможность в архитектуре приложения использовать блокируемые сокеты, то лучше использовать их, а не неблокируемые". Правильно ли это? Думаю, да. Лично я обычно использую блокирующие. Для неблокирующих сокетов единственно, что функции connect и recv возвращаются сразу, но, как правило, это не нужно, даже мешает. А чтобы не блокировался recv надо перед его вызовом запрашивать количество данных в буфере. |
Сообщ.
#6
,
|
|
|
Цитата JoeUser @ Часто возникает ситуация, когда одна из сторон (клиент или/и сервер) долго обрабатывают поставленную задачу. Стандартный способ - использование тайм-аутов. Допустим, клиент законнектился к серверу и сделал запрос. Предполагается, что сервер будет "долго" его выполнять. Пусть он для этого запустит другой поток и будет готов выполнять другие запросы клиента. Возможен запуск нескольких (разных или одинаковых) длительно обрабатывающихся запросов. Клиент может запрашивать состояние работ на сервере (что продолжает выполняться по его запросу, а что уже нет) т.е. флаги "Busy/Ready". И коды ошибок завершения, конечно. Возможно также запрашивать процент выполненной работы - это как захочешь. --- Этот вопрос к сетевому программированию отношения не имеет - это вопос о взаимодействии процессов. |
Сообщ.
#7
,
|
|
|
Цитата ЫукпШ @ Этот вопрос к сетевому программированию отношения не имеет - это вопос о взаимодействии процессов. Совершенно справедливо... Здесь скорее всего речь идет о создании протокола мультиконнекта. |
Сообщ.
#8
,
|
|
|
Цитата ЫукпШ @ Предполагается, что сервер будет "долго" его выполнять. Пусть он для этого запустит другой поток и будет готов выполнять другие запросы клиента. А вот тут собака зарылась Я намеренно спросил выше о блокирующих и неблокирующих сокетах. ЫукпШ, как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части? |
Сообщ.
#9
,
|
|
|
Цитата Возникла мысль, а что если сделать два соединения. Разрабатывай свой протокол поверх tcp, у меня один поток слушает, разбирает пакеты и ложит данные в шаред структуромассивы, при необходимости создаёт потоки в которых идёт обработка данных, в любой момент клиент может запросить состояние обработки пакетов на что ему будет выдана инфа. Два соединения, имхо, избыточно. Цитата как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части? На highload серверах такое малоприменимо, проще глянуть как работает допустим тот же nginx, сырцы открыты, емнип кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига |
Сообщ.
#10
,
|
|
|
Цитата Gonarh @ кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига И работает на ... асинхронных (неблокируемых) сокетах, верно? Добавлено Цитата Gonarh @ Разрабатывай свой протокол поверх tcp Эххх ... нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ... |
Сообщ.
#11
,
|
|
|
Цитата JoeUser @ Разрабатывай свой протокол поверх tcp Эххх ... нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ... До протокола здесь как до луны пешком. Для начала стоит научиться просто с сокетами работать. |
Сообщ.
#12
,
|
|
|
Цитата JoeUser @ Цитата Gonarh @ кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига И работает на ... асинхронных (неблокируемых) сокетах, верно? Разумеется Добавлено У меня штук пять сервисов на перле, писал на неблокируемых, работает годами. Добавлено Цитата JoeUser @ нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ... тогда какой смысл в своем сервисе? пиши fastcgi и не люби мозги |
Сообщ.
#13
,
|
|
|
Цитата Gonarh @ И работает на ... асинхронных (неблокируемых) сокетах, верно? Разумеется И в чём же было их преимущество, в твоём случае, перед блокирующими? |
Сообщ.
#14
,
|
|
|
Цитата JoeUser @ А вот тут собака зарылась Я намеренно спросил выше о блокирующих и неблокирующих сокетах. ЫукпШ, как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части? Столько, сколько посчитаешь нужным. Можно 1. Можно - 10. И можно даже ни одного. Т.е. можно всю работу выполнять в потоке, принимающем соединения. Все запросы просто ставятся в очередь, которая должна быть к каждому рабочему потоку. "Поблизости" в конференции обсуждали похожие вопросы. "О взаиможействии потоков", "о передачи данных между потоками" или что-то вроде этого. --- Кроме того, вовсе незачем сохранять соединения на время выполнения длительной работы. Можно так: 1. Подсоединились. 2. Запросили выполнение работы - получили идентификатор. Если работа "короткая" - сразу получили результат. 3. Отключились. А дальше время от времени подключаемся и узнаём статус и степень выполнения "работы" по её идентификатору. |
Сообщ.
#15
,
|
|
|
Цитата Олег М @ И в чём же было их преимущество, в твоём случае, перед блокирующими? Всё зависит от задач. У меня комплексное решение и с теми и с другими сокетами, в одном месте был необходим моментальный возврат при вызове connect в случае недоступности сервера. Если бы стоял вопрос о десятках тысяч коннектов, то о блокирующем режиме можно точно забыть. |