На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
  
    > Два соединения для коннекта клиента-сервера?
      Всем привет!

      Часто возникает ситуация, когда одна из сторон (клиент или/и сервер) долго обрабатывают поставленную задачу. Стандартный способ - использование тайм-аутов. Но тут тоже есть минус - как определить "достаточность" тайм-аута. Возникла мысль, а что если сделать два соединения. Одно, собственно, рабочее, в второе - "типа для проверки". Сценарий примерно следующий. По первому соединению идет постановка задачи и ожидание ответа. Второе соединение раз в промежуток времени опрашивает вторую сторону "мол жив здоров?". Ответом должно быть нечто "Ok <цифра>". Под цифрой можно понимать разное, например, текущий счетчик итераций, процент выполнения, если это считаемо, может еще чего. Естественно, если по второму соединению нет ответа за уже конечный тайм-аут, значит что-то пошло не так. И тогда оба соединения закрываются принудительно.

      Ваши мысли? Плюсы? Минусы?
        В общем идея здравая и имеет право на жизнь...после тестирования :D
        Вот тогда плюсы и минусы всплывут сами... :)
          На обработчике в любом случае придётся запускать новый поток для чтения второго коннекта. Тогда уж лучше сам запрос выполнять асинхронно, и контролировать его выполнение по тому же коннекту, по которому пришёл запрос. Всё равно, по-хорошему, надо из него вычитывать данные, чтобы не было переполнения буфера.
            Цитата Олег М @
            На обработчике в любом случае придётся запускать новый поток для чтения второго коннекта. Тогда уж лучше сам запрос выполнять асинхронно, и контролировать его выполнение по тому же коннекту, по которому пришёл запрос. Всё равно, по-хорошему, надо из него вычитывать данные, чтобы не было переполнения буфера.

            Увы, сетевым программированием я ранее не занимался. Пока почитываю материалы в сети. Запомнилось одно утверждение "если есть возможность в архитектуре приложения использовать блокируемые сокеты, то лучше использовать их, а не неблокируемые". Правильно ли это?
              Цитата JoeUser @
              Увы, сетевым программированием я ранее не занимался. Пока почитываю материалы в сети. Запомнилось одно утверждение "если есть возможность в архитектуре приложения использовать блокируемые сокеты, то лучше использовать их, а не неблокируемые". Правильно ли это?

              Думаю, да. Лично я обычно использую блокирующие. Для неблокирующих сокетов единственно, что функции connect и recv возвращаются сразу, но, как правило, это не нужно, даже мешает.
              А чтобы не блокировался recv надо перед его вызовом запрашивать количество данных в буфере.
                Цитата JoeUser @
                Часто возникает ситуация, когда одна из сторон (клиент или/и сервер) долго обрабатывают поставленную задачу. Стандартный способ - использование тайм-аутов.

                Допустим, клиент законнектился к серверу и сделал запрос.
                Предполагается, что сервер будет "долго" его выполнять. Пусть он для этого запустит другой поток
                и будет готов выполнять другие запросы клиента.
                Возможен запуск нескольких (разных или одинаковых) длительно обрабатывающихся запросов.
                Клиент может запрашивать состояние работ на сервере (что продолжает выполняться по его запросу, а что уже нет)
                т.е. флаги "Busy/Ready". И коды ошибок завершения, конечно.
                Возможно также запрашивать процент выполненной работы - это как захочешь.
                ---
                Этот вопрос к сетевому программированию отношения не имеет - это вопос о взаимодействии процессов.
                Сообщение отредактировано: ЫукпШ -
                  Цитата ЫукпШ @
                  Этот вопрос к сетевому программированию отношения не имеет - это вопос о взаимодействии процессов.

                  Совершенно справедливо...
                  Здесь скорее всего речь идет о создании протокола мультиконнекта.
                    Цитата ЫукпШ @
                    Предполагается, что сервер будет "долго" его выполнять. Пусть он для этого запустит другой поток
                    и будет готов выполнять другие запросы клиента.

                    А вот тут собака зарылась :) Я намеренно спросил выше о блокирующих и неблокирующих сокетах. ЫукпШ, как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части?
                      Цитата
                      Возникла мысль, а что если сделать два соединения.

                      Разрабатывай свой протокол поверх tcp, у меня один поток слушает, разбирает пакеты и ложит данные в шаред структуромассивы, при необходимости создаёт потоки в которых идёт обработка данных, в любой момент клиент может запросить состояние обработки пакетов на что ему будет выдана инфа. Два соединения, имхо, избыточно.
                      Цитата
                      как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части?

                      На highload серверах такое малоприменимо, проще глянуть как работает допустим тот же nginx, сырцы открыты, емнип кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига
                      Сообщение отредактировано: Gonarh -
                        Цитата Gonarh @
                        кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига

                        И работает на ... асинхронных (неблокируемых) сокетах, верно?

                        Добавлено
                        Цитата Gonarh @
                        Разрабатывай свой протокол поверх tcp

                        Эххх ... нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ...
                          Цитата JoeUser @
                          Разрабатывай свой протокол поверх tcp

                          Эххх ... нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ...

                          До протокола здесь как до луны пешком. Для начала стоит научиться просто с сокетами работать.
                            Цитата JoeUser @
                            Цитата Gonarh @
                            кол-во потоков-обработчиков равно как и кол-во коннектов регулируется параметрами конфига

                            И работает на ... асинхронных (неблокируемых) сокетах, верно?

                            Разумеется

                            Добавлено
                            У меня штук пять сервисов на перле, писал на неблокируемых, работает годами.

                            Добавлено
                            Цитата JoeUser @
                            нужна web-морда для клиентов, со всеми там AJAX, JQuery, Bootstrap иже еси на небеси ...

                            тогда какой смысл в своем сервисе? пиши fastcgi и не люби мозги
                            Сообщение отредактировано: Gonarh -
                              Цитата Gonarh @
                              И работает на ... асинхронных (неблокируемых) сокетах, верно?

                              Разумеется


                              И в чём же было их преимущество, в твоём случае, перед блокирующими?
                                Цитата JoeUser @
                                А вот тут собака зарылась :) Я намеренно спросил выше о блокирующих и неблокирующих сокетах. ЫукпШ, как ты себе представляешь "серверную" часть, которая держит 10 000 соединений? Столько же потоков запускать на "серверной" части?

                                Столько, сколько посчитаешь нужным.
                                Можно 1. Можно - 10.
                                И можно даже ни одного.
                                Т.е. можно всю работу выполнять в потоке, принимающем соединения.
                                Все запросы просто ставятся в очередь, которая должна быть к каждому рабочему потоку.
                                "Поблизости" в конференции обсуждали похожие вопросы.
                                "О взаиможействии потоков", "о передачи данных между потоками" или что-то вроде этого.
                                ---
                                Кроме того, вовсе незачем сохранять соединения на время выполнения длительной работы.
                                Можно так:
                                1. Подсоединились.
                                2. Запросили выполнение работы - получили идентификатор.
                                Если работа "короткая" - сразу получили результат.
                                3. Отключились.
                                А дальше время от времени подключаемся и узнаём статус и степень выполнения "работы"
                                по её идентификатору.
                                Сообщение отредактировано: ЫукпШ -
                                  Цитата Олег М @
                                  И в чём же было их преимущество, в твоём случае, перед блокирующими?

                                  Всё зависит от задач. У меня комплексное решение и с теми и с другими сокетами, в одном месте был необходим моментальный возврат при вызове connect в случае недоступности сервера. Если бы стоял вопрос о десятках тысяч коннектов, то о блокирующем режиме можно точно забыть.
                                  Сообщение отредактировано: Gonarh -
                                    JoeUser
                                    Цитата JoeUser @
                                    "если есть возможность в архитектуре приложения использовать блокируемые сокеты, то лучше использовать их, а не неблокируемые". Правильно ли это?

                                    Для новичков лучше использовать блокирующие. Так как если вы будете использовать неблокирующие, то вам придётся делать синхронизацию. Синхронизация это по любому блокировка.
                                    Встаёт вопрос зачем делать блокировки самому когда они есть готовые? Ответ прост вы можете уменьшить их число и время простоя. Для этого вы должны знать теорию транзакций.
                                    Ах да теория транзакций не описана в одной книге или одной статье. Что-бы её освоить мне пришлось собрать крупицы знаний из не менее чем 5 статей.

                                    Цитата JoeUser @

                                    Часто возникает ситуация, когда одна из сторон (клиент или/и сервер) долго обрабатывают поставленную задачу. Стандартный способ - использование тайм-аутов.

                                    Если протокол чужой и в нем не продуманы транзакции, то вам придётся городить параллельность. А в параллельности всё равно есть блокировки. А с ней никто грамотно работать не умеет, кроме меня :tong:.
                                      Цитата Олег М @
                                      И в чём же было их преимущество, в твоём случае, перед блокирующими?

                                      Предположим, необходимо срочно завершить приложение, а "connect" блокирующий.
                                      Когда он закончится - не известно.
                                      В результате, нельзя даже завершить приложение по своему желанию. =:0
                                      0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                      0 пользователей:


                                      Рейтинг@Mail.ru
                                      [ Script execution time: 0,0433 ]   [ 17 queries used ]   [ Generated: 28.03.24, 23:21 GMT ]