Как вы можете проверить, дошло ли сообщение до места назначения, я придумал свое решение, но, поскольку я не профессионал в этой теме, я хотел бы знать некоторые другие способы. Мои решения (на стороне клиента) для отправки пакета, если подтверждение не было получено в течение времени ожидания, затем отправить еще раз (на стороне сервера), если полученное сообщение верное, отправьте подтверждение, если не получено на другой стороне, отправьте снова . Это изображение схемы этого алгоритма, Изображение. Короче говоря, обе стороны отправляют сообщение дважды. любые другие идеи?
c # udp проверяет, достигнуто ли сообщение
comment
Почему бы не использовать TCP, который автоматически отправляет ACK'ы?
- person TheGeneral schedule 03.09.2018
comment
Связь на основе TCP может отправить ответ, подтверждающий, что сообщение было доставлено. В вашем случае я бы использовал TCP, а не UDP
- person smitty_werbenjagermanjensen schedule 03.09.2018
comment
Он хотел бы создать API для реализации его в различных проектах, таких как игры в реальном времени или потоковая передача, без необходимости использования TCP и UDP в действии, а просто использовать переменную, такую как WaitForFeedback, чтобы знать, есть ли критические по времени Информация.
- person Creţu Cosmin schedule 03.09.2018
Ответы (1)
Это зависит от вашего приложения. Но, глядя на прилагаемую диаграмму, вы предпочитаете TCP-связь.
Однако, если вы действительно хотите использовать UDP вместо TCP, вам нужно отказаться от ACK.
Предполагая, что вы постоянно передаете изображения в удаленное место назначения. И вы не беспокоитесь о некоторой потере кадров, если потоковая передача будет такой же быстрой, как и будет. С этим можно использовать UDP. Просто также подумайте, насколько надежна линия передачи (физический уровень), чтобы предсказать результат.
Но если ваше приложение не так критично по времени, но требует максимальной надежности, вы можете использовать TCP.
Для получения дополнительных сведений [посетите это]
Ниже приводится сравнение с UDP и TCP.
Протокол UDP - это чрезвычайно простой протокол, который позволяет отправлять дейтаграммы по IP. UDP предпочтительнее TCP для доставки критичных по времени данных, поскольку многие функции надежности TCP, как правило, достигаются за счет более высокой задержки и задержек, вызванных безусловной повторной отправкой данных в случае потери пакета.
В отличие от TCP, который предоставляет программисту один упорядоченный поток октетов для каждого подключенного однорангового узла, UDP предоставляет пакетный интерфейс без понятия подключенного однорангового узла. Дейтаграммы прибывают с адресом источника1, и программисты должны отслеживать концептуальные одноранговые «соединения» вручную.
TCP гарантирует2, что либо данный октет будет доставлен подключенному одноранговому узлу, либо соединение будет разорвано и программист уведомлен. UDP не гарантирует, что какой-либо конкретный пакет будет доставлен, и в случае потери пакетов уведомление не предоставляется.
TCP гарантирует, что каждый отправленный октет будет получен в том порядке, в котором он был отправлен. UDP не гарантирует, что переданные пакеты будут получены в каком-либо конкретном порядке, хотя базовые протоколы, такие как IP, подразумевают, что пакеты обычно будут приниматься в порядке передачи при отсутствии ошибок маршрутизации и / или аппаратных ошибок.
TCP не накладывает ограничений на размер передаваемых данных. UDP напрямую предоставляет программисту доступ к нескольким зависящим от реализации (но также стандартизированным) ограничениям размера пакета. Создание пакетов, размер которых превышает эти ограничения, увеличивает вероятность того, что пакеты будут либо фрагментированы, либо просто отброшены. Фрагментация нежелательна, потому что, если какой-либо из отдельных фрагментов дейтаграммы теряется, дейтаграмма автоматически отбрасывается. Определение безопасного максимального размера для дейтаграмм нетривиально из-за различных пересекающихся стандартов.
person
Leandro Keen Zapa
schedule
03.09.2018
Спасибо, Леандро, я думаю, что не разъяснил цель этого, я использовал TCP в прошлом для многих проектов, и я точно знаю, что он отлично работает, но то, что я пытаюсь сделать, - это api для использования на нескольких проекты, особенно онлайн-игры, а также потоковые приложения, как показано на рисунке WaitForFeedback. Я хочу иметь переменную для переключения с критической на некритическую информацию, я ищу другой способ, потому что я уже знаю, что с этой переменной, установленной на true, это будет включать много памяти и управление потоками.
- person Creţu Cosmin; 03.09.2018
@ CreţuCosmin, ладно. Итак, в вашем случае вы не хотели делать контрольную сумму, когда это не критично. Я думаю, что он не память ест, а загружает процессор. Однако, когда вы переходите к критическому, вы включаете контрольную сумму, и это время, когда вы хотите отправить обратно ACK и проверить, получен ли ACK? На самом деле это должно быть хорошо. Также вы можете попробовать открыть два сокета - TCP и UDP. Но это будет сложно, но непросто. Я знаю, что многие онлайн-игры уже используют это.
- person Leandro Keen Zapa; 03.09.2018
Правильно, TCP itsef немного сложно настроить, в то время как UDP - нет, возможно, мне удастся сделать API, а затем сделать его общедоступным для всех. Это будет просто вопрос отправки (message, criticalbool); В любом случае, я думаю, что нет ничего, что не реализует тайм-аут, не должно быть других более простых идей.
- person Creţu Cosmin; 03.09.2018
