c # udp проверить, достигнуто ли сообщение - PullRequest
0 голосов
/ 03 сентября 2018

Как вы можете проверить, пришло ли сообщение к месту назначения, я придумала свое решение, но, поскольку я не являюсь профессионалом в этой теме, я бы хотела узнать о некоторых других способах. Мое решение состоит в том, чтобы (на стороне клиента) отправить пакет, если подтверждение не было получено в течение времени ожидания, а затем отправить еще раз (на стороне сервера), если полученное сообщение является правильным подтверждением отправки, если не получено на другой стороне, то отправьте снова , Это изображение схемы этого алгоритма, Изображение . Короче говоря, обе стороны отправляют сообщение дважды. какие-нибудь другие идеи?

1 Ответ

0 голосов
/ 03 сентября 2018

Это зависит от вашего приложения. Но, глядя на прилагаемую диаграмму, вы предпочитаете TCP-связь.

Однако, если вы действительно хотите использовать UDP вместо TCP, вы должны отказаться от ACK.

Предполагается, что вы постоянно передаете изображения в удаленное место назначения. И вам не нужно беспокоиться о потере кадров, пока потоковая передача будет такой же быстрой, как и будет. Вы можете использовать UDP с этим. Также подумайте, насколько надежна линия передачи (физический уровень) для прогнозирования результата.

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

Для получения дополнительной информации [посетите это]

Ниже приведено сравнение с UDP и TCP

.

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

В отличие от TCP, который предоставляет программисту по одному упорядоченному потоку октетов на подключенный одноранговый узел, UDP предоставляет интерфейс на основе пакетов без понятия подключенного однорангового узла. Приходят дейтаграммы, содержащие адрес источника1, и ожидается, что программисты будут отслеживать концептуальные «соединения» одноранговых узлов.

TCP гарантирует2, что либо данный октет будет доставлен подключенному узлу, либо соединение будет разорвано, и программист получит уведомление. UDP не гарантирует, что какой-либо данный пакет будет доставлен, и в случае потери пакетов уведомление не предоставляется.

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

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

...