LINUX.ORG.RU

Клиент-серверное ПО. Модель управления соединениями.

 , ,


0

1

Пишу тз для клиент-серверного приложения и есть дилемма при выборе модели управления соединениями.

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

Команды представляют собой структурированные данные известной длины. после их передачи соединение завершать не нужно.

Для приложения критичен онлайн клиента.

Варианты:

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

Минусы:
a) может так случиться что первое соединение закрыто, а новые соединения еще не созданы (еще только создаются). Сервер видит что нет ниодного соединения и читает что клиент в оффе и на сервере придется пилить костыли чтобы обработать это. Даже если создавать больше 1 соединения первоначально, то неисключено что эти соединения будут завершены прежде чем будет создано хотябы 1 новое.

b) Данные и команды придется передавать по одним и тем же соединениям. Нужно устанавливать какие-то приоритеты(???)

2) Разделяем соединения на типы: 1 командное которое будет ВСЕГДА онлайн пока приложение онлайн и остальные соединения только для передачи данных. Политика работы с соединениями для передачи данных такая же как и в 1) По командному соединению, соответственно, передаем команды.

Минусы: создаем дополнительное соединение которое будет занимать ресурсы сервера

-------------------------------------------------------------
Есть экзотические варианты, но там совсем уж...

Какую модель используют на практике?
Какие подводные камни?
Хотелось бы критики


Критикую. Два соединения звучат как неоправданный геморрой, на практике так не делают со времен FTP.

Команды могут подождать, пока передастся блок данных? Тогда хай ждут, потом передашь. Команды должны прерывать поток данных и обрабатываться поскорее? Тогда сочини протокол, который будет их мультиплексировать почаще.

Если очень хочешь жонглировать лишними тредами и соединениями — расстарайся и очень сильно это обоснуй.

P.S. В процессе может возникнуть соблазн заюзать TCP Urgent Data — не делай этого. Разве что уже есть какой-то готовый и годный протокол, который не придется сочинять и специфицировать и который уже может вышеупомянутое мультиплексирование с использованием Urgent, в противном случае не надо. Чем проще, тем лучше.

t184256 ★★★★★ ()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

В процессе может возникнуть соблазн заюзать TCP Urgent Data — не делай этого

Этот соблазн я уже преодолела

Команды могут подождать, пока передастся блок данных?

Подождать могут

Если очень хочешь жонглировать лишними тредами и соединениями — расстарайся и очень сильно это обоснуй.

Дополнительное командное соединение можно ввести как гарантированный признак онлайна клиента (решаем проблему когда 1 соединение закрыто, а другое еще не создано) и заодно туда же пишем команды.
Я бы не задумывалась о том чтобы создавать дополнит соединение если бы были данные о том как быстро создадутся новые соединения, что невозможно прогнозировать. Можно только на сервере ввести понятие времени ожидания соединения и по его прошествии объявлять клиента как оффлайн.
Идею командного соединения я подсмотрела у одного клиента соцсетей. Там по 1 соединению гнались запросы на поиск, измнения данных пользователя, данные трекинга и пр..., а тяжелые медиаданные передавались по другому соединению (я заметила только одно что сейчас кажется странным).

nyka ()
Ответ на: комментарий от anonymous

я не работала с ним, сейчас просмотрела что Buffers и http2 использутется. зачем такого монстра тащить за собой?!
Серверная часть должна быть типа хайлоад.
Buffers не нужен, команды очень просто пакуются в малюсенькие бинарные пакеты, а http2 кажется страным тут использовать

nyka ()
Ответ на: комментарий от nyka

Выравнивание размера команды по самой большой сделай.

И вот у тебя уже фиксированная длина. От лишних 100 байт ты не умрешь, а разбор сообщений станет доступен даже для песенку.

По поводу хайлоада, на http2 лично видел 20к рпс, при не лучшем бэкенде. Имхо, http2 не есть проблема, но если его рассматривать - то можно и в сторону ws посмотреть.

nihirash ★★★ ()