Jabber и дорогие данные (XML его мусор)

Question

Я работаю в проекте, в котором Jabber имеет коммуникационную платформу.

Дело в том, что мне нужны клиенты (много клиентов), чтобы общаться друг с другом не только для сигнализации, но и для обмена данными между ними.

Представьте, что клиент A имеет 3 доступных сервиса. Клиент B может запросить у A начать отправку ему информации от каждой службы (например, потоковой службы), пока клиент B не скажет A, чтобы остановить службы.

Эти сервисы могут отправлять только один символ с интервалом 100 мс или 1000 символов с интервалом 100 мс или даже отправлять некоторые данные, когда это необходимо.

Когда приходит информация, отправленная B, она должна знать, какому сервису соответствует, какое действие и значения (пример), поэтому я использую json поверх jabber.

Моя проблема в том, что я трачу много трафика с протоколом jabber xmpp, просто чтобы отправить сообщение с телом вроде:

{"s": "x", "x": 5} // каждые 100 мс (5 представляет любое число)

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

Я знаю, что есть какое-то сжатие, которое я могу сделать, но мне интересно, если вы порекомендуете что-то еще, что не может иметь такого количества xml за моим сообщением, и все же, используя jabber.

Большое спасибо за вашу помощь.

С наилучшими пожеланиями,

Эдуардо

Answer 1

Похоже, за исключением значительной передачи данных, XMPP хорошо подходит для вашего приложения.

Как вы, наверное, знаете, XMPP никогда не был предназначен или предназначен для использования в качестве большого канала для передачи данных. Большинство приложений, которые включают передачу значительных данных, таких как передача файлов и голос / видео, используют XMPP только для согласования отдельного потока «вне полосы». Вы говорите, что это может вызвать проблемы из-за брандмауэров и веб-клиентов.

Если ваше приложение в основном передает текст, то вам действительно стоит попробовать сжатие ... оно предлагает значительную экономию пропускной способности, если это ваш самый ограниченный ресурс. Недостатком является то, что потребуется больше клиентской и серверной памяти (по умолчанию около 300 КБ, но это может быть уменьшено при незначительной потере сжатия).

В качестве альтернативы вы можете посмотреть туннелирование вашей базы данных, кодированной с использованием In-Band Bytestreams . У меня нет ваших образцов данных, или я не знаю, как вы их упаковываете для транспортировки, и это может оказаться хуже или лучше. Я бы сказал, что будет лучше, если вы удалите JSON и превратите его в более эффективный двоичный формат. Данные Base64 сжимаются не так хорошо, и примерно на 33% больше, чем необработанные данные. Экономия была бы в том, что я мог бы удалить JSON и любые другие посторонние обертки, сохраняя данные в потоке XMPP.

В конце концов, масштабирование большинства приложений затруднительно, какие бы технологии вы ни использовали. Это требует, прежде всего, понимания - вы не должны ничего менять, не проверив это сначала, и вы должны заранее протестировать, чтобы выяснить, что вы должны изменить. Вы должны проанализировать вашу систему на предмет основных узких мест (действительно ли это пропускная способность клиента ??). По моему опыту, редко сам XML был прямым узким местом. Однако, в конечном счете, все эти вещи уникальны для вашего приложения, дать общий совет в масштабе не так просто.

Answer 2

Нет, Xml - это не мусор. Он читабелен, очень расширяем и очень хорошо сжимается.

XMPP поддерживает сжатие потока, и это сжатие потока (в основном zlib) работает очень хорошо по всем моим тестам. Поэтому, если для вас важно оптимизировать количество байтов, которые вы отправляете по проводам или используете низкую пропускную способность, используйте сжатие потоков, когда вы используете сокеты. Когда вы находитесь на Bosh, вам нужно использовать либо сервер, который поддерживает HTTP-сжатие, либо промежуточный прокси-сервер, чтобы включить сжатие. Но имейте в виду, что у BOSH также много издержек со всеми заголовками HTTP.