Механизм Push с использованием протокола с низкой задержкой

Question

Я разработчик Java EE.

Я хотел бы спросить, может ли кто-нибудь сообщить мне о сетевом протоколе с низкой задержкой, который может обрабатывать много последовательной информации.

Я пытаюсь реализовать нажимной механизм между двумя машинами, имеющими нагрузку данных, являющихся передача из машины А на машину В.

Любые предложения были бы более прием (о протоколе и/или толкающего механизма)

Я говорю о системе реального времени.

Толчок будет от сервера к клиенту (от 1 до многих).

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

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

благодарит

Answer 1

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

Я использовал сервер XMPP для этой цели, соединение с одним сокетом выполняется с сервером на весь срок службы проекта. Сервер отправляет строфы и клиент анализирует его и выполняет соответствующие действия.
Его весьма успешен для уведомлений пользовательских кнопочных,

Вы можете создать свой собственный сервер вместо того, чтобы использовать сервер XMPP, но если многие в миллионах, вы должны использовать сервер XMPP. Он лучше всего подходит для уведомлений в режиме реального времени.

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

Одним из преимуществ использования сокетов является то, что клиентам не обязательно быть на одном языке.

Хорошая отправная точка может быть http://biese.wordpress.com/2009/06/14/how-to-create-a-simple-java-socket-thread-server/

Answer 2

Это не простой вопрос, поскольку есть много частей к латентности. Если в вашем здании используется методология публикации подписки, вы должны посмотреть протоколы многоадресной рассылки или UDP.

Что вы хотите заказать? Являются ли эти устройства в одной и той же плоской сети, вы будете пересекать границы (брандмауэры, коммутаторы, маршрутизаторы)? Все эти мелочи являются частью большей картины.

Как только вы попадете в UDP и Multicast, вам придется иметь дело с потерей пакетов, повторной передачей пакетов, упорядочением сообщений, завершением сообщений и множеством других вещей, с которыми нужно иметь дело. Именно поэтому большинство из них покупают такие продукты, как Tibco и некоторые другие технологии передачи сообщений, чтобы справиться с этим.

Если вы ищете Wall St.типа, вы попадаете в рамки выделенных маршрутизаторов/прошивки.

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

Задержка также может быть временем, когда ваш код отвечает на какое-либо событие.

Edit 1:

IP Multicast является лучшим выбором, так как он достаточно хорошо изучен и маршрутизируемый через локальные сети если у вас есть приличная сетевая инфраструктура.

Я вижу проект с открытым исходным кодом JGroups, который выглядит как-то. Возможно, вы захотите посмотреть на Actors Remote Actors, у меня нет опыта работы с обоими из этих проектов, поэтому ваш пробег может отличаться.

Для коммерческого программного обеспечения я бы посмотрел на Tibco. Я больше не уверен в их упаковке продукта, но у них был Tib Rendezvous (Tib RV) и более старый продукт (не помню названия с моей головы), я использовал оба для обработки рыночных данных ,

Answer 3

О TIBCO RV, он использует протокол UDP, но может пересекать границы сети с помощью так называемого маршрутизатора deamon, так что это возможно.

Answer 4

Эта проблема обычно решается с помощью своего рода message queue.

В мире Java существует стандартный API для очередей сообщений, называемый JMS, и существует множество реализаций на выбор, включая коммерческие и с открытым исходным кодом. Моя компания недавно решила начать использовать RabbitMQ, так как она казалась самой гибкой и надежной в реализации, которую мы исследовали. HornetQ отличается тем, что является самой быстрой из известных реализаций JMS.

Есть также очереди сообщений, которые не являются реализацией JMS; часто они больше ориентированы на производительность и меньше на такие функции, как надежность. Интересные примеры включают OpenDDS и ZeroMQ.

Я предлагаю вам взглянуть на HornetQ. Я думаю, это должно быть очень близко к тому, что вам нужно.

EDIT: Я просто заметил, что вы не хотите использовать стороннюю реализацию, но для ее реализации. Это было бы плохой идеей. Не делай этого. Используйте хорошую стороннюю реализацию.