Когда нужно закрывать соединение между сокетами

Имеется приложение на Flask. Также имеется другое приложение, которое в режиме реального времени обрабатывает некоторые данные. Необходимо эти данные вернуть пользователю.

Пользователь делает GET запрос, параметрами которого являются данные, которые нужно взять из приложения.
Для того, чтобы можно было получать данные и не вмешиваться в работу приложения, которое обрабатывает данные, при его запуске создается поток, в котором создается серверный сокет.

Приложение Flask при получении первого GET запроса проверяет доступно ли соединение, если да, то формирует пакет, отправляет его в сокет. Серверный сокет ловит пакет, обрабатывает, возвращает ответ в сокет. Клиентский сокет принимает ответ, обрабатывает, возвращает данные пользователю.

Вопрос: после того, как был обработан GET запрос (т.е. данные от приложения получены и готовы к отправке пользователю) нужно ли закрывать сокет? Или держать соединение до тех пор, пока или web сервер не отключится, либо пока приложение, которое обрабатывает данные не будет приостановлено.

Интервал между запросами на получение данных: от 10 в секунду (0.1 сек) и выше.

0

Не могу сказать наверняка, но я слышал, что:

"Открытый порт для "мамкиного Хацкера" - как котику сметанка.

0

Damenikx, сеть локальная.

0

Странно всё. Ну и ладно.

Объявите переменную сокета и код открытия сокета на удалённый сервис (приложуху) в глобальной области видимости. Для того, чтобы сокет открывался при запуске воркера flask и соединение всегда было установлено.

* Ещё нужно настроить keep-alive, чтобы соединение не разорвалось при простаивании.
* Если соединение всё же разорвалось - восстанавливаем.
* Работу с сокетом лучше обернуть в какой-нибудь класс и давать остальному flask'у пару методов.

В итоге получается, что веб-сервер стартует, каждый воркер поднимает соединение до приложения и держит его.

Всё будет работать при условии, что приложение умеет обрабатывать несколько запросов по одному соединению. То есть послали запрос, а потом (сразу или через несколько секунд) опять послали по этому же сокету.

Добавлено через 5 минут
Я бы использовал для общения между сервисами JSON-RPC или самодельную реализацию. Отлаживать проще (открыл ссылку в браузере или съэмулировал post-запрос).

Добавлено через 49 секунд
Да, тогда второе приложение превращается в мини http-сервер.

1

Сообщение от Рыжий Лис Странно всё

если не секрет, что именно? (можно организовать иначе?)

0

Использование сокетов и самопальный бинарный протокол, который фиг отладишь.

Я бы использовал для общения между сервисами JSON-RPC или самодельную реализацию.

1

Рыжий Лис, JSON-RPC можно заменить Pyro? Прочитал документацию, очень похож результат, которого можно добиться, используя эти модули.

0

К сожалению, не подскажу. Если считаете, что можно, значит можно.

0

Рыжий Лис, последний вопрос, если можно (я ТС).
Т.е. сейчас все выглядит как-то так:
1. JS делает GET запрос web серверу на получение данных
2. Сервер делает запрос приложению. Для этого формирует пакет по (свой протокол) и отправляет в сокет
3. Приложение формирует пакет ответа и отправляет web серверу
4. web сервер отправляет ответ клиенту

Сильно ли отразится использование JSON-RPC на времени ответа, если заменить им обмен данными по сокету?

0

Думаю не сильно. Замерил скорость открытия сокета:
Что-то много намерил. В любом случае надо проверять и замерять задержки. Если раньше данные кодировались/декодировались в бинарный пакет, то теперь будут в json.

Вопрос целесообразности поддержания открытого соединения остаётся открытым. Можно поэкспериментировать, тот же requests из коробки поддерживает такую фичу.

Excellent news — thanks to urllib3, keep-alive is 100% automatic within a session! Any requests that you make within a session will automatically reuse the appropriate connection! Note that connections are only released back to the pool for reuse once all body data has been read; be sure to either set stream to False or read the content property of the Response object.

1