Структурирование сокетных коммуникаций для минимизации передачи данных - PullRequest
1 голос
/ 28 июля 2011

Я работаю над проектом, который будет использовать клиентское устройство в сети с ограниченной пропускной способностью (сотовой). Я не очень знаком с сокетными коммуникациями, но я выяснил, как использовать Java в качестве сервера (из этого учебника), и Python - это язык клиента.

Я буду отправлять от ограниченного числа команд (менее 50), которые говорят "сделать команду", но мне также иногда потребуется отправить более длинный набор, который дает клиенту будущее правило / условие. Я думаю о том, чтобы послать один байт для каждой из команд, причем один из байтов означает, что это еще не все. Будет ли это правильным способом, или я должен продолжить запись в выходной сокет (я предполагаю, что это utf-8, что составляет 3 байта / символ, если я не ошибаюсь).

Спасибо за ввод, Джеймс

Ответы [ 2 ]

1 голос
/ 28 июля 2011

Есть две вещи, которые вы должны иметь в виду при попытке оптимизировать пропускную способность сети.

Во-первых, вам нужно передавать около 40 байтов служебной информации каждый раз, когда вы хотите поговорить с партнером. Это просто присуще IP. Попытка свести связь к одному байту часто является ложной экономией. То, что вы должны делать, - это использовать лучшее из двусторонней передачи: объедините сообщение с таким количеством дополнительных данных, которое может понадобиться партнеру * в дальнейшем. В ограниченной степени алгоритм Nagle уже позаботился об этом для наивных служб, задерживая пакет до тех пор, пока одноранговый узел фактически не укажет, что он готов к большему количеству данных, и этого обычно достаточно.

Во-вторых, при типичных масштабах MTU практически невозможно разработать несжатый двоичный протокол, который более экономичен по сравнению с более простым протоколом, который туннелируется с использованием сжатия общего назначения. Не существует "упакованного двоичного http", потому что кодировка передачи gzipped ascii в любом случае превзойдет его. Когда пропускная способность является проблемой, всегда включайте сжатие. Осталось только убедиться, что ваш протокол «легко» сжать.

1 голос
/ 28 июля 2011

UTF-8 не является фиксированным числом байтов - символ UTF-8 может быть 1 - 16 байтов.

Не думайте о ваших командах как о тексте, думайте о них как о целых числах до 255- Нет кодирования или порядка байтов или чего-либо.chr(command), где команда является целым числом в этом диапазоне, будет нормально работать, не беспокоясь о кодировке, если вы не пытаетесь ее отобразить.

Если вы хотите отправить минимальные данные, да, вы можете отправитьодна команда на байт.Если у вас действительно 64 или менее команд, вы можете использовать 7-й бит, чтобы обозначить «идет другая команда», а 8-й бит, чтобы обозначить «следующий байт запускает правило / условие».

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

...