Клиент и сервет, keep-alive TCP соединение. Формат общения: 1. Запрос-ответ (запрос клиентом по его же инициативе) 2. Подписка клиентом (тем же запрос-ответ) на событие на сервере. Нотификацию по событию отправляет сервер клиенту, отправляет по собственной инициативе. Вопрос: реально ли это сделать на одном соединении? Я никак не могу придумать как это все засинхронизировать...
Не только реально, но и достаточно стандартно. Пишешь заголовок для сообщений: byte type uint16 length ... и усё.
s0larian Не понял, при чем тут заголовки? Вопрос в том, что если в любой момент времени любая сторона по своей инициативе может решить что-то отправить, то как сделать так чтобы не произошло рассинхронизации? Например - клиент шлет запрос на сервер. Сервер в этот момент шлет нотификационное сообщение. Клиент читает нотификационное сообщение, думая что это ответ на только что отправленный запрос.
Ааа... byte type - это тип пакета? То есть нотификация или ответ на запрос... Да, похоже на правду... Курю...
ну как вариант - делать идентификатор. К примеру, отправляется команда х, где первые 4 байта - это ID команды/сессии. Когда приходит ответ y, он тоже содержит этот же ID. А вообще, команды разные - как можно спутать ответ сервера с запросом??? Ведь формат общения один. А если при принятии пакета ты понятия не имеешь, какая у него структура, то это конечно жесть
Можно глянуть в сторону ISO 8583. Там как раз - идентификаторы, связывающие запрос-ответ - типы сообщений - длины сообщений в заголовке. Еще интересная идея - битовая маска (удобно при переменном кол-ве полей) По этому протоколу в рамках одного ТСР соединения даже у некоторых банков в РФ проходит до нескольких сотен сообщений в минуту. Между запросом и ответом до десятков секунд (т.к. гонятся по всему миру, обрабатываются на весьма специфичном оборудовании/софте). Это я к вопросу синхронизации. Есть сессии типа запрос-ответ. Просто "нотификации". Эхо-тесты итд. На клиенте и сервере, как правило, очереди используются. Причем выбираются сообщения с учетом приоритета.
