Несмотря на то, что http имеет некоторые накладные расходы, если это становится важной частью использования ваших данных, то я подозреваю, что ваш API слишком «болтлив», и, возможно, следует рассмотреть меньшее количество сообщений (каждое из которых несет больше полезной нагрузки).
Следующий пункт будет; Как мы можем уменьшить пропускную способность для данного количества полезной нагрузки? Сжатие является опцией, но может быть проблемой на некоторых платформах. Другой - использовать формат сериализации, который по своей сути плотный и эффективный для обработки (с точки зрения циклов ЦП, поскольку вы используете устройства с низким энергопотреблением). Для этой цели идеально подойдет что-то вроде «буферов протокола».
protobuf-net - CF-совместимая реализация буферов протокола для .NET; сборка CF не имеет всех хороших функций WCF (потому что CF не поддерживает их), но она может работать очень эффективно.
Кроме того, если вы делаете , переходите на http, то следует учитывать MTOM, так как это уменьшает накладные расходы на кодирование двоичных данных (то есть то, что будет использовать protobuf-net).
Переход на UDP может быть вариантом, но я бы попробовал что-то вроде http + protobuf-net + MTOM first (в сочетании с менее "болтливым" API), и посмотрите как это складывается.
Следует также отметить, что текущая (загружаемая) версия protobuf-net имеет некоторые "изломы" с CF; это работает, но не так быстро и так далее, как могло бы быть (из-за ограничений в метапрограммировании на CF). Продукт "v2" (еще не выпущенный) обращается ко всем этим пунктам, позволяя полностью статическое (и быстрое) выполнение на CF. И лучше всего, это бесплатно.