#tcp #spring-integration #multicast
#tcp #spring-интеграция #многоадресная рассылка
Вопрос:
Справочная информация: у меня есть система, в которой обычно каждый пользователь подключается к серверу через длительное TCP-соединение. У каждого пользователя есть свой собственный закрытый ключ для подключения к серверу через это TCP-соединение. Когда пользователь отправляет сообщение на сервер, сервер передает это сообщение обратно некоторым или всем другим пользователям через их активные TCP-соединения.
Проблема: для некоторого набора этих пользователей мы хотим, чтобы они могли взаимодействовать с сервером через многоадресную рассылку, поэтому я создаю для этого многоадресный <-> TCP прокси-сервер (мы не контролируем код для исходного сервера, поэтому редактирование его для обработки многоадресного трафика невозможно). Этот прокси-сервер будет взаимодействовать с пользователями через многоадресную рассылку и взаимодействовать с сервером через TCP-соединения. Для каждого пользователя, отправляющего сообщения прокси-серверу, прокси-сервер должен иметь отдельное TCP-соединение с сервером, которое использует закрытый ключ этого конечного пользователя для подключения к серверу. Я пытаюсь настроить эти потоки связи в Spring Integration, но я изо всех сил пытаюсь выяснить, возможна ли эта настройка вообще в этой среде или мне лучше написать что-то специально для этой цели.
Прямо сейчас самая большая часть, с которой я борюсь, находится на стороне TCP. Концептуально, в части user-> server у меня есть адаптер приемника многоадресной рассылки, который разветвляется на два потока: один для создания новых соединений с информацией, полученной в сообщении многоадресной рассылки, и один для отправки данных по уже созданному соединению. Есть ли способ создавать эти TCP-соединения в одном потоке, а затем каким-то образом сохранять эту информацию о соединении, чтобы она использовалась другим потоком? Эти установленные соединения также необходимо будет использовать для получения сообщений на стороне сервера-> пользователя. Я изо всех сил пытаюсь понять, как правильно выполнить это в рамках фреймворка.
Пожалуйста, дайте мне знать, если есть какая-либо дополнительная информация, которую я мог бы предоставить, которая была бы полезна для ответа на этот вопрос, я знаю, что это довольно странная ситуация, которую я пытаюсь разрешить здесь.
Комментарии:
1. Неясно, с какой проблемой вы столкнулись; это не должно быть сложно, исходя из вашего описания; может быть, добавьте какой-нибудь код, чтобы показать, что вы пробовали?
2. Часть моей проблемы в том, что я даже не уверен, как запустить это в коде. Я думал, что обработчик исходящих TCP-сообщений будет использовать фабрику соединений, и я подумал, что, возможно, создание пользовательской фабрики соединений будет правильным способом установить другое соединение в зависимости от того, с какого устройства конечного пользователя поступает трафик, но я не был уверен, как передавать атрибуты сообщения в это устройство.фабрика соединений для каждого из этих потоков сообщений. Внутри фабрики соединений должен быть какой-то кэш соединений. Также не уверен, как использовать эту фабрику для входящих подключений.
3. Похоже, что лучшим подходом была бы настраиваемая фабрика соединений; это может быть основано на,
ThreadAffinityClientConnectionFactoryно вместо привязки одного соединения к потоку вы бы изменили связанное соединение в зависимости от того, от какого клиента поступил запрос.4. Я взглянул на этот код, который определенно кажется ближе к тому, что мне нужно, но мне все еще нужно получить информацию о соединении клиента из многоадресных сообщений в этот пользовательский ClientConnectionFactory для установления этих соединений, и я не вижу, как это сделать, пока. Прокси-сервер должен иметь возможность хранить эту информацию о соединении, чтобы пользователям больше не нужно было беспокоиться о накладных расходах на подключение со своих устройств после первоначальной регистрации.
5. Может быть, поток соединений просто сохраняет эту информацию в конце в каком-то кэше / репозитории, а поток данных будет использовать фабрику соединений, которая использует ссылку на этот кэш / репозиторий для создания соединений? Но мне все равно нужно будет прочитать идентификатор пользователя из сообщения данных, чтобы определить, какую информацию о подключении из кэша использовать, поскольку ожидается, что пользователи будут часто подключаться к сети и выходить из нее, и иногда разные устройства будут использовать один и тот же закрытый ключ для аутентификации. Кроме того, спасибо за всю вашу помощь в этом.