Разработка мобильного веб-сервера и клиента для сжатия трафика - PullRequest
4 голосов
/ 30 ноября 2011

Я был немного озадачен тем, как лучше это сделать.

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

Одним из подобных решений является: T-Booster

Проблема : Я запутался в том, как отправить сжатый http-запрос из клиентского приложения, какую технологию использовать для сервера и как лучше ее реализовать. Предполагая, что сервер обрабатывает тысячи запросов одновременно, как это повлияет на все приложение?

Комментарии приветствуются. Спасибо.

Ответы [ 2 ]

4 голосов
/ 05 декабря 2011

Подход I: Основные критерии: Свобода, безопасность и свобода архитектурного проектирования

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

Плюсы:

  1. Настройте содержимое полезной нагрузки с минимальными заголовками и отправьте его на сервер.
  2. Относительно защищенный от перехватчиков, также дополнительный уровень шифрования не принесет вреда, кроме как при необходимости.
  3. Сжатие уровней буксировки уменьшает общую полезную нагрузку.
  4. Не зависит от сторонней библиотеки кодировщика / декодера, если только вы не используете библиотеки GZIP / шифрования. Следовательно, его можно переносить на разные платформы.
  5. Поскольку сторонние библиотеки не используются, при условии отсутствия gzip и алгоритмов шифрования, нет проблем с коммерческим лицензированием.

Минусы:

  1. Сложно поддерживать пользовательский язык, должен поддерживаться архитектурой, дизайном и javadoc's
  2. Относительно большое время для создания полезной нагрузки, если используется несколько компрессоров, а именно. настраиваемая языковая кодировка, библиотека сжатия и шифрования GZIP.

Пример: По этой ссылке Opera Mini читать раздел по Функциональность .

.

Подход II: Основные критерии: Строгие сроки реализации проекта

Для быстрой оплаты проекта используйте сторонние компрессоры, такие как GZIP, и стандартные форматы обмена контентом веб-сервисов, такие как SOAP и JSON.

Плюсы:

  1. Быстрая интеграция, соблюдение стандартных подходов, облегчающих разработку компонента веб-сервера
  2. Нет времени, затрачиваемого на изобретение колеса, как, как говорят, время, затрачиваемое на разработку архитектуры и разработку собственного языка.

Минусы:

  1. Сжатие уровня осуществляется сторонними библиотеками, в которых фактический контент может не сжиматься. Библиотека будет просто перестраиваться, как в теории Шеннона / скорости-искажения.
  2. Сжатие работает одинаково на младших / старших устройствах, поэтому потребление памяти кучи может быть блокирующим на устройствах с низкой памятью.
  3. Зависимость от сторонних библиотек, вы никогда не знаете, когда поддержка была отозвана.
  4. Вы можете оказаться в порочном круге коммерческого лицензирования при использовании сторонних библиотек, если вы не используете библиотеки с открытым исходным кодом.

Пример: http://developers.sun.com/mobility/apis/articles/wsa/

.

Редактировать: Некоторые очень полезные ссылки

  1. InformIT
  2. DevX
  3. Дизайн мобильных веб-сервисов
  4. Предоставление веб-услуг мобильным пользователям: архитектурный дизайн портала m-service
0 голосов
/ 04 декабря 2011

Я не разработчик J2ME, но хотел бы поделиться своим мнением как разработчика Java. Если вы общаетесь со своим веб-сервером, то я предполагаю, что вы будете вызывать веб-службу (SOAP или REST). Я сделал что-то подобное с веб-сервисом для SOAP, чтобы некоторое время назад сжать данные. Вот то, что я следовал. http://www.predic8.com/soap-compression-howto.htm

...