Блог

Главная - Вопросы по программированию - Протокол с небольшими (est) накладными расходами по GPRS

Протокол с небольшими (est) накладными расходами по GPRS

#sockets #tcp #network-programming #udp #data-transfer

#сокеты #tcp #сетевое программирование #udp #передача данных

Вопрос:

Наша компания разработала станции, которые собирают данные на сельскохозяйственном поле. Эти поля могут находиться в глуши, поэтому станции используют GSM / GPRS с SIM-картой, которая автоматически переключается на самого сильного провайдера.

Каждые 5 минут устанавливается подключение к Интернету для отправки данных на сервер. Данные имеют структуру с длиной пакета, командой, данными датчика и проверкой crc. Но эти структуры данных отправляются с http post на URL.

Для 480 байт данных используется около 2550 байт трафика данных. В протоколе HTTP много накладных расходов. Поскольку нам нужно отправить только 480 байт данных, у нас 80% накладных расходов на post через http. Сейчас у нас несколько сотен станций, и это число растет. Таким образом, затраты на трафик данных быстро растут.

Мы хотим переделать передачу данных. Данные отправляются микропроцессором microchip на станциях.

Наша цель — максимально снизить накладные расходы при гарантированной доставке данных. Итак, я изучил TCP и UDP.

TCP имеет обнаружение сбоев и восстановление, но имеет более высокие издержки. UDP имеет меньшие накладные расходы, но там не гарантируется, что данные доставляются без сбоев.

Моя первая идея — создать сервер, который прослушивает TCP-порт. И станции отправляли данные по протоколу TCP. В основном из-за гарантированной доставки данных.

С UDP мы должны сами разрабатывать проверку и повторную отправку данных, но структура данных наших записей уже подготовлена для выполнения проверок.

Так что я действительно сомневаюсь, что делать. И я пытаюсь получить ответ на эти вопросы:

  • Сколько байтов потребуется TCP и UDP для отправки (и доставки) 480 байт данных?

  • Являются ли TCP и UDP лучшими способами для отправки 480 байт данных или есть более разумное решение с еще меньшими накладными расходами?

Комментарии:

1. Экспериментируйте и тестируйте . Если вы можете измерить, сколько данных отправляется вашим текущим методом, вы должны быть в состоянии измерить, как это происходит при использовании TCP или UDP. И не забудьте протестировать с плохим приемом и плохими проводными соединениями, чтобы проверить, как это работает, когда требуется много повторных передач и попыток.

2. Да, мы можем это измерить. Поставщик sim-карты предоставляет нам подробную информацию об отправленных и полученных байтах для каждого соединения. Поэтому мы должны сначала запрограммировать решение. Теперь мы выбираем TCP.

Ответ №1:

Сколько байтов потребуется TCP и UDP для отправки (и доставки) 480 байт данных?

A (типичный) Длина заголовка TCP составляет 20 байт, хотя с помощью опций он может быть (немного) длиннее. Если все 480 байт отправляются в одном сегменте TCP, вы получите 480 20 20 (IP-заголовок) = 520 байт перед служебными данными уровня 2.

UDP имеет 8-байтовый заголовок, поэтому для UDP у вас будет 480 8 20 = 508 байт.

Однако вам следует учитывать, что TCP является потоковым протоколом. Чтение из сокета TCP похоже на чтение из двоичного файла — вам нужно будет самостоятельно разделить этот поток на отдельные сообщения, используя какой-то разделитель или добавляя длину сообщения к каждому сообщению.

UDP, с другой стороны, работает с отдельными сообщениями. Чтение из сокета UDP будет возвращать сообщения по одному за раз.

Являются ли TCP и UDP лучшими способами для отправки 480 байт данных или есть более разумное решение с еще меньшими накладными расходами?

UDP и TCP являются транспортными протоколами самого низкого уровня в Интернете. HTTP и другие протоколы высокого уровня построены поверх них. Если размер данных критичен, необработанные TCP и UDP имеют настолько низкие накладные расходы, насколько это возможно без использования необработанных сокетов и встраивания ваших данных непосредственно в IP-пакеты.

Комментарии:

1. SOCK_SEQPACKET Для надежности, подобной TCP, также используются UDP-подобные дейтаграммы. И, учитывая вариант использования, описанный в OP, надежность может быть большой проблемой (возможно, даже больше, чем накладные расходы TCP и UDP).