caxapa.ru :: TCP - сначала устанавливается сессия, потом шлются пакеты. Каждый пакет подтверждается. Надёжно. Обе стороны могут видеть, какие данные уже подтверждены корреспондентом. UDP - будто ты просто отправляешь пакет (кадр) байт по последовательному интерфейсу. Никакой сессии, никакого подтверждения. Просто данные ушли. А получил ли их корреспондент

Nikolay_Po (Вчера, 15:57, просмотров: 38) ответил Лaгyнoв на Модуль запрограммирован на соединение как TCP-клиент. С внешним сервером. Тот вроде работает как TCP-сервер. У меня нет никаких возможностей проверить со своей стороны. А если у меня UDP, то всё это так и будет?

TCP - сначала устанавливается сессия, потом шлются пакеты. Каждый пакет подтверждается. Надёжно. Обе стороны могут видеть, какие данные уже подтверждены корреспондентом. UDP - будто ты просто отправляешь пакет (кадр) байт по последовательному интерфейсу. Никакой сессии, никакого подтверждения. Просто данные ушли. А получил ли их корреспондент - его проблемы.

UDP проще в реализации. Не требует установления соединения - просто послал пакет на адрес/порт и он сразу дошёл. Есть два минуса UDP - потерянный пакет будет просто тихо потерян. Приёмник не поймёт, какой это пакет по счёту, примет как очередной, даже если очередной был пропущен. И второй минус - из-за большого количества файерволов и трансляторов адресов, особенно, в сегменте мобильной сети, связи UDP может вообще не состояться, если файервол или NAT не разпознают пакеты как какой-то известный (и разрешённый) протокол. С TCP им проще - они, по крайней мере, видят, что установлена сессия и обмен идёт в рамках неё.

Ответить

- Я общаюсь с модулем только по rx/tx. Есть еще вывод где уровень сигнализирует об установлении соединения. Его я вижу. То есть вероятно, что у меня всё же TCP. Но вот буфер по rx меня убил. :-) Придется как с модемом sim800 порции слать. там порции были по 1280 байт, здесь поменьше будут. На стороне сервера надо будет людям напрягаться из кусочков по 768 байт лепить десятки килобайт. :-) - Лaгyнoв(Вчера, 16:07)
  - Да, придётся. Хоть TCP, хоть UDP - железке нужен буфер. И если он 1кБ на TCP, вряд ли он будет иным для UDP - и там, и там, буферизация требуется одинаково. Ну, может, байт на 8 будет больше запас. - Nikolay_Po(Вчера, 16:11)
  - А как без буфера-то? Если TCP на линии с потерями или просто с малой скоростью, как быть? Просто выкидывать данные, полученные по UART? Конечно, должен быть буфер. 1 КБ - вполне вменяемый размер для таких зверушек. - SciFi(Вчера, 16:10)
    - и опять же. Как славно было с модемом sim800. Когда он мои 1280 байт отправит, то предлагает мне слать следующую порцию. А здесь кто предложит? Получается, что погромист на сервере должен мне этот диалог обеспечить. Я ему порцию - он мне в ответ подтверждение и предложение слать дальше. Правильно я понимаю? - Лaгyнoв(Вчера, 16:31)
      - CH9121 непонятная штука. Не видно способа узнать, когда давать ему следующий килобайт, чтобы он не споткнулся. - SciFi(Вчера, 17:09)
      - ESP8266 лишь <2кбайта пл TCP отправлял через AT-команды. Думаю и прозрачный канал там тоже был лимитирован... видимо, к такому надо быть готовым в отношении всех слабых букашек. - POV(Вчера, 16:33)
        
        Потенциально одно TCP соединение может требовать до 64К ОЗУ чисто под буфер передаваемых данных. У букашек такой роскоши нет, так что хочешь-нехочешь, а где-то как-то оно будет урезано. - LightElf(Вчера, 18:56)
        
        У меня мега328 и ENC28 - ограничил аппаратно размер ethernet пакетов ~300 байт. Так оно лучше дышит - много лишнего отфильтровывается ;) - Гyдвин(Вчера, 17:04)

Кибернетика, автоматика, протоколы