Я не имею в виду, как подключиться к сокету. Что я должен знать о программировании UDP?
Чего мне действительно нужно знать?
"я должен предположить, если я отправлю 200 байт я может получить 120 и 60 байт отдельно?"
Когда вы отправляете дейтаграммы UDP, ваш размер чтения будет равен вашему размеру записи. Это связано с тем, что протокол UDP представляет собой протокол дейтаграммы, а протокол TCP поток. Однако вы можете записывать данные только до размера MTU до того, как пакет может быть фрагментирован или удален маршрутизатором. Для общего использования в Интернете безопасный MTU составляет 576 байт, включая заголовки.
"я должен беспокоиться о другом соединение, передающее мне плохие данные о тот же порт?"
У вас нет подключения, у вас есть порт. Вы будете получать любые данные, отправленные на этот порт, независимо от того, откуда он. Это зависит от вас, чтобы определить, имеет ли он правильный адрес.
Если данные не поступают, как правило, долго может я (обычно) не видеть данные для (250 мсек? 1 секунда? 1,75 сек.)
Данные могут быть потеряны навсегда, данные могут быть отложены, и данные могут выйти из строя. Если какая-либо из вас вас беспокоит, используйте TCP. Написание надежного протокола поверх UDP - очень нетривиальная задача, и нет оснований для этого почти для всех приложений.
Я должен беспокоиться о другом соединение, передающее мне плохие данные о тот же порт?
Да, вы должны беспокоиться об этом. Любое приложение может отправлять данные на ваш открытый порт UDP в любое время. Одним из больших применений UDP является многопользовательская связь, в которой вы мультиплексируете связь с несколькими одноранговыми узлами на одном порту, используя обратный, переданный обратно во время recvfrom, чтобы различать одноранговые узлы.
Однако, если вы хотите избежать этого и принимать только пакеты из одного однорангового узла, вы можете фактически называть connect в своем UDP-сокете. Это приведет к тому, что стек IP отклонит пакеты, исходящие из любого хоста: port combo (socket), отличного от того, с которым вы хотите поговорить.
Второе преимущество вызова connect в вашем UDP-сокете состоит в том, что во многих ОС он значительно улучшает скорость/задержку. Когда вы вызываете sendto в несвязанный сокет UDP, ОС фактически временно подключает сокет, отправляет ваши данные и затем отключает сокет, добавляя значительные накладные расходы.
Третье преимущество использования подключенных UDP-сокетов заключается в том, что оно позволяет получать сообщения об ошибках ICMP обратно в ваше приложение, такие как маршрутизация или неизвестный хост из-за сбоя. Если сокет UDP не подключен, ОС не будет знать, куда доставлять сообщения об ошибках ICMP из сети, и они будут молча отбрасывать их, что потенциально может привести к зависанию вашего приложения, ожидая ответа от разбитого хоста (или ждет вашего выберите тайм-аут).
Ваш пакет может не попасть туда.
Ваш пакет может попасть туда дважды или даже чаще.
Ваши пакеты могут быть не в порядке.
У вас есть ограничение по размеру ваших пакетов, наложенных базовыми сетевыми уровнями. Размер пакета может быть довольно небольшим (возможно 576).
Ничто из этого не говорит "не использовать UDP". Однако вы должны знать все вышеизложенное и подумать о том, какие варианты восстановления вы можете захотеть.
Фрагментация и повторная сборка происходят на уровне IP, поэтому вам не нужно беспокоиться об этом (Wikipedia). (Это означает, что вы не будете получать разделенные или усеченные пакеты).
UDP-пакеты имеют контрольную сумму для данных и заголовка, поэтому получение фиктивных данных маловероятно, но возможно. Возможны также потерянные или дублированные пакеты. В любом случае вы должны проверить свои данные.
Нет контроля перегрузки, поэтому вы можете подумать, что если вы планируете забивать трубки большим количеством пакетов UDP.
UDP - это протокол без установления соединения. Отправка данных через UDP может доходить до приемника, но также может потеряться во время передачи. UDP идеально подходит для таких вещах, как трансляция и потоковое аудио или видео (т.е. Упавший пакет никогда не является проблемой в этих ситуациях.) Поэтому, если вам нужно обеспечить, чтобы ваши данные попадали на другую сторону, придерживайтесь TCP.
UDP имеет меньше накладных расходов, чем TCP, и поэтому быстрее. (TCP необходимо сначала создать соединение, а также проверить пакеты данных для повреждения данных, которые требуют времени.)
Фрагментированные пакеты UDP (т.е. пакеты, превышающие примерно половину килобайта), вероятно, будут удалены маршрутизаторами, поэтому разделите ваши данные на маленькие чанки перед отправкой. (В некоторых случаях ОС может позаботиться об этом.) Обратите внимание, что это всегда пакет, который может это сделать, или нет. Половинные пакеты не обрабатываются.
Задержка на больших расстояниях может быть довольно большой. Если вы хотите сделать повторную передачу данных, я бы пошел с чем-то вроде 5-10 раз времени ожидания агерса над текущим соединением. (Вы можете измерить задержку, отправив и получив несколько пакетов.)
Надеюсь, это поможет.
Я не буду последовать примеру других людей, которые ответили на это, все они, похоже, подтолкнули вас к TCP, и это не для игр вообще, за исключением, может быть, для информации о входе/чате. Отпустите в порядке:
Нужно ли беспокоиться о плохих данных в моем сокете?
Да. Хотя UDP содержит чрезвычайно простую контрольную сумму для маршрутизаторов и т.д., Она не на 100% эффективна. Вы можете добавить свое собственное контрольное устройство, но большую часть времени UDP используется, когда надежность уже не является проблемой, поэтому данные, которые не соответствуют, должны быть просто удалены.
Я должен предположить, что если я отправлю 200 байтов, я могу получить 120 и 60 байтов отдельно?
Нет, UDP - это прямая запись и чтение данных. Однако, если данные слишком велики, некоторые маршрутизаторы будут усекаться, и вы потеряете часть данных навсегда. Некоторые сказали примерно 576 байт с заголовком, я лично не использовал бы более 256 байт (хороший круглый номер журнала2).
Должен ли я беспокоиться о другом соединении, отправляющем мне плохие данные на один и тот же порт?
UDP прослушивает любые данные с любого компьютера на порту, поэтому в этом смысле да. Также обратите внимание, что UDP является примитивным, и необработанный формат может использоваться для подделки отправителя, поэтому вы должны использовать какой-то "ключ", чтобы слушатель мог проверить отправителя на свой IP.
Если данные не поступают обычно, как долго я могу (обычно) не видеть данные за (250 мс? 1 секунда? 1,75 с??)
Данные, отправленные по UDP, обычно являются одноразовыми, поэтому, если вы не получаете данные, тогда их можно легко игнорировать... однако иногда вы хотите "полунадежный", но вы не хотите, чтобы "заказывали надежные" TCP использует, 1 секунда - хорошая оценка падения. Вы можете пронумеровать свои пакеты при ротации и написать свое собственное сообщение ACK. Когда пакет получен, он записывает номер и отправляет обратно поле бит, позволяя отправителю узнать, какие пакеты он получил. Вы можете прочитать этот незавершенный документ для получения дополнительной информации (хотя он еще не закончен, он все еще дает достоверную информацию):
Большую вещь, которую нужно знать при попытке использовать UDP:
Ваши пакеты могут не все делать это по линии, а это значит, что будет возможное повреждение данных.
Если вы работаете над приложением, в котором 100% данных должно прибыть надежно для обеспечения функциональности, используйте TCP. Если вы работаете над приложением, где допустима некоторая потеря (потоковое мультимедиа и т.д.), Переходите на UDP, но не ожидайте, что все произойдет от одного из каналов до другого.
В дополнение к рекомендации don.neufeld использовать TCP.
Для большинства приложений TCP проще реализовать. Если вам необходимо поддерживать границы пакетов в потоке TCP, хорошим способом является передача двухбайтового заголовка перед тем, как данные будут делить сообщения. Заголовок должен содержать длину сообщения. На принимающей стороне просто прочитайте два байта и оцените значение. Затем просто подождите, пока вы не получите столько байтов. Затем у вас есть полное сообщение и готовы получить следующий 2-байтовый заголовок.
Это дает вам некоторые преимущества UDP без проблем с потерянными данными, прибытием пакета вне заказа и т.д.
Один из способов взглянуть на разницу между приложениями, подходящими для UDP и TCP, - это то, что TCP хорош, когда доставка данных "лучше поздно, чем никогда", UDP хорош, когда доставка данных "лучше никогда, чем поздно".
Еще один аспект заключается в том, что беззаконный, наиболее эффективный характер большинства приложений на основе UDP может сделать масштабирование немного легче. Также обратите внимание, что UDP может быть многоадресной, а TCP не может.
И не предполагайте, что если вы отправите пакет, он попал туда.
Если на пути существует ограничение размера пакета, наложенное каким-то маршрутизатором, ваши UDP-пакеты могут быть без умолку усечены до такого размера.
Две вещи:
1) Вы можете получать или не получать то, что было отправлено
2) Все, что вы получаете, может быть не в том порядке, в котором оно было отправлено.