Голосование за лучший протокол для данного сценария

Похоже, вам лучше всего подойдет протокол HTTP. Он имеет низкие накладные расходы, уже хорошо принятый. Использует TCP [что является требованием для мобильной связи], имеет согласование сеанса [хорошо, соединение разумно, а не фактическое состояние сеанса]

Используйте другой протокол для совместного использования видео и аудио, но установите соединение с http один.

Использование SOAP / веб-сервисов не было бы оптимальным из-за требуемой обработки. Из личного опыта клиенты веб-сервиса на мобильных машинах проще, но необходимая обработка утомительна и может создать узкое место в вашем приложении. [Мобильные машины не очень хорошо обрабатывают потоки]

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

Ваши требования:

• Сервер и клиент. клиентом обычно является мобильный телефон. : Ага
• Подключил через интернет. : Да, зависит от того, как настроена сеть вашего устройства
• Сервер и клиент хотят общаться друг с другом. : Yep
• Обмен текстом, мультимедиа между клиентом и сервером. : HTTP хорошо работает с текстом и изображениями, но вам нужно переключиться на что-то ненадежное, например UDP для видео.
• Текст может иметь стандартный формат. это предрешено. : Да
• Требования реального времени: Это невозможно, но можно попробовать.
• Сессия обычно длится 5-15 минут. В некоторых случаях менее минуты. примите 5 минут в качестве продолжительности сеанса: есть заголовки, чтобы сеанс оставался открытым
• Протокол должен соответствовать стандартам. : RFC Something
• Он должен быть эффективным. : Единственная обработка, которую вам нужно выполнить, - это построчный синтаксический анализ Key: data.

Кроме того, я забыл упомянуть, что SOAP / Webservices - это XML поверх HTTP.

Используйте вариант 1, используйте ASN.1 в качестве протокола! (Иногда называется двоичным XML.) В результате получаются небольшие структурированные сообщения, понятные другим. Это популярный стандарт, и когда вы читаете это сообщение, вы просто использовали его. : -)

ASN.1 является частью нескольких Интернет-протоколов.

Выберите вариант 1 и используйте буферы протокола Google для автоматического создания кода на основе определения протокола (т. Е. Это дает вам некоторую согласованность / стандартизацию, но при этом остается эффективным).

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

Также HTTP / 1.1 поддерживает конвейер и повторное использование соединений для последующих запросов. Это снижает нагрузку на сервер по установке и разрыву соединений.

Во-первых, избегайте SOAP, если вы хотите установить клиент на мобильный телефон и получить легкое решение. SOAP - это свинья, тратящая впустую ЦП и полосу пропускания. Это тоже не самое простое решение.

Если вы планируете реализовать клиентов в браузере (с использованием javascript), решение на основе JSON - очевидный путь, по которому следует идти, и он также прост. Чтобы получить представление о том, как это будет выглядеть, прочтите эту статью:

• http://www.ibm.com/developerworks/web/library/wa-ajaxintro11.html

Вы можете найти больше ресурсов на json. org

Вероятно, вы можете использовать JAX-RS просто как прославленную реализацию сервлета. (Многие из нас говорят, что JAX-RS 311 выглядит так, как должна была быть спецификация сервлета с самого начала ... что не совсем так просто, но ...)

О "одной ветке на сообщение"

Вариант 1 - хороший вариант, если вы можете сделать его более эффективным для ваших целей. Но я бы предпочел вариант 2, если вариант 1 не требуется. Вариант 2 хорошо реализован и имеет хорошую поддержку. Он не должен создавать новые потоки каждый раз, если вы используете HTTP 1.1

. Но если вам нужно только передать текст, вы можете использовать свой вариант 1 и некоторое сжатие текста. Хотя есть небольшие накладные расходы на распаковку текста, их должно быть слишком много. Но это уменьшит использование полосы пропускания мобильных устройств.

Option 7 Why don't you go for XMPP?

• It's a standard

• it allows messages in both directions.

• you may use existing XMPP infrastructure (clients might connect using their Google Talk accounts for instance) or easily build your own using open source XMPP servers

• I also like the fact, that you basically only write client code (as the server is also an XMPP client) - assuming server and client are both written in same language, you may even use the exact same code.

• file transfers are supported.

• easily extensible to your needs

• it's buzzing (Google Wave) ;)

The only thing people might argue about is its efficiency - or the efficency of XML in general. I don't think it's a problem though.

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

Поскольку вас интересует эффективность, вы можете найти некоторые показатели по различным протоколам удаленного взаимодействия Java здесь: http: // daniel. gredler.net/2008/01/07/java-remoting-protocol-benchmarks/[1223 visible

Потребность в реальном времени (если принять буквально ) сокращает множество вариантов: протокол HTTP не работает в реальном времени, и поэтому все, что выше него (включая SOAP и REST ) разделяет ту же слабость. Если это строгое требование, вам следует взглянуть на протокол RTP или что-то еще, что (по крайней мере) не поддерживает квитирование.