Мы хотим передавать данные с сервера клиентам, но можем использовать только HTTP (порт 80). Что является лучшим решением для обмена сообщениями? Одна из идей — Comet. Существуют ли другие идеи или фреймворки, которые предлагают, скажем, JMS через HTTP. (Да, ActiveMQ тоже его поддерживает, но ИМХО нечетко. И JXTA тоже поддерживает, но конфигурация сложная. Предпочтительнее что-то простое.)
Лучшее решение для Java HTTP push (обмен сообщениями)
Ответы (5)
Самым простым решением по многим причинам является использование подхода на основе Comet (как вы упоминаете). Это означает, что клиенты (которым вы хотите «отправлять» сообщения) открывают долгоживущие HTTP-соединения. Эти соединения остаются открытыми до тех пор, пока не истечет время ожидания или пока вы не отправите клиенту сообщение. Как только это происходит, клиент открывает новое соединение.
Прямое подключение к клиентам может быть проблематичным по многим причинам: они могут быть за брандмауэрами, которые это запрещают, они могут быть за прокси-серверами и так далее.
Если ваши клиенты не являются реальными серверами (в этом случае вы действительно являетесь клиентом), пусть они свяжутся с вами и отправят ответ на имитацию push.
person
cletus
schedule
13.11.2009
Это правильно? Когда сообщение поступает в браузер, открывается новое соединение?
- person djna; 13.11.2009
Клиент должен быть запрограммирован на открытие нового соединения. Если это не так, сервер не имеет возможности общаться с клиентом.
- person cletus; 13.11.2009
Мне жаль. Проблемы с пониманием. Клиент открыл долгоживущее HTTP-соединение. Сервер отправляет сообщения туда, верно? Затем вы говорите, что эти соединения остаются открытыми до тех пор, пока не истечет время ожидания, или вы не отправите клиенту сообщение. Как только это происходит, клиент открывает новое соединение. Похоже, мы открываем второе соединение. Почему? Сообщение, которое мы только что получили, содержало нужные нам данные, не так ли?
- person djna; 13.11.2009
Новое соединение предназначено для прослушивания следующего сообщения. Идея здесь состоит в том, чтобы постоянно поддерживать открытое соединение с сервером, которое просто ждет, пока сервер что-то с ним сделает. Это позволяет серверу (фактически) инициировать связь. Как только сервер использует соединение для отправки сообщения, необходимо открыть новое соединение для следующего сообщения. Все это предполагает, что у нас есть клиент, которому сервер должен иметь возможность передавать данные. Альтернативой является опрос изменений через регулярные промежутки времени, но это может привести к задержке доставки события клиенту.
- person Kris; 13.11.2009
(Извините за трудность, но это просто не соответствует моему опыту). Соединение живет долго, сервер периодически выдает данные, поток браузера высасывает эти данные и отображает их. Я не понимаю, почему нам нужно открывать больше связей. Прямо сейчас у меня обновляются измерения в реальном времени в моем браузере и только одно соединение (я думаю).
- person djna; 13.11.2009
Мы использовали COMET в сочетании с JMS, используя WAS Web 2.0 Feature Pack; фактически сервер подписался на JMS, а COMET отправил сообщение в браузер. как разработчик, он «чувствовал», что браузер подписывается на JMS. Это «просто сработало», поэтому мы не стали искать альтернативы.
Я мог бы представить реализацию JMS на чистом JavaScript в браузере, использующую HTTP в качестве транспорта, но мое мнение состоит в том, что это будет очень тяжеловесно. Я не знаю таких реализаций.
person
djna
schedule
13.11.2009
Альтернативный подход к уже обсуждавшимся (например, Comet и т. д.) заключается в реализации опроса в клиенте. Недостатком этого подхода является то, что у вас неизбежно возникает задержка с момента сообщения/события до момента, когда клиент его получит. Если ваше приложение очень чувствительно к таким задержкам, опрос отключен.
Если определенная задержка (минимум порядка нескольких секунд) приемлема, опрос в меньшей степени является злоупотреблением протоколом HTTP. Он также более устойчив к временным проблемам с сетью, поскольку сервер по умолчанию ставит сообщения в очередь и не расстраивается, если клиент недоступен по расписанию.
person
Kris
schedule
13.11.2009
На самом деле нет большой разницы между опросом и долгоживущими соединениями. В обоих случаях вы инициируете опрос, и он вернется немедленно или с некоторой задержкой. Чем дольше задержка, тем меньше соединений вам нужно открыть. Во всех случаях такие проблемы, как прерванные или неотвеченные звонки, просто ведут к следующему опросу. Внутри HTTP/1.1 соединение (TCP) обычно остается открытым.
- person eckes; 05.07.2011
Я создал пример приложения с использованием Comet, Raphael, Bayeux, Java и Maven с PaaS Cloudbees и написал об этом сообщение в блоге, надеюсь, оно будет кому-то полезно.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
person
Felipe Oliveira
schedule
22.02.2011
Ссылка не работает.
- person Vinicius Rocha; 28.03.2014
