UDP протокол :)

[Артэс]

Здравствуйте. Возвращаясь к вопросу о UDP протоколе, кое-кого попрошу воздержаться от комментов типа "ааа ты 2 года назад спрашивал" и т.п.

Быть может существуют общие принципы системы 100% гарантии передачи данных через UDP протокол? Пока есть задумка, сделать очередь для сообщений. Перед отправкой, сообщение помещается в этот массив очереди, затем посылается, и ожидается ответ от клиента. Если ответ об успешном получении сообщения пришел - двигаемся дальше по массиву очереди, если нет - переотправляем сообщение опять. Таким образом, даже если связь пропадет на несколько секунд, а потом появится, клиент получит все сообщения, которые были помещены в массив очереди. Ну а в случае превышения очереди, скажем, 100 сообщений, дисконнект и мессага о том, что слишком долго были в лаге

Правильно ли так?

[veniside]

> принципы системы 100% гарантии передачи данных

100% гарантии даёт только бог. Перекопает экскаватор вам оптоволокно, и привет.

А так, доставку с подтвеждением можно сделать десятком разных способов. Вопрос зачем, и на сколько это будет эффективно. Вряд ли у вас получится это сделать лучше, чем у ТСП, а делать хуже, имхо, особого смысла нет.

[f.hump]

все уже придумано
http://udt.sourceforge.net/doc.html

[waleri]

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

[Rock-n-Rolla]

Сообщение от Артэс

Быть может существуют общие принципы системы 100% гарантии передачи данных через UDP протокол? Пока есть задумка, сделать очередь для сообщений. Перед отправкой, сообщение помещается в этот массив очереди, затем посылается, и ожидается ответ от клиента. Если ответ об успешном получении сообщения пришел - двигаемся дальше по массиву очереди, если нет - переотправляем сообщение опять. Таким образом, даже если связь пропадет на несколько секунд, а потом появится, клиент получит все сообщения, которые были помещены в массив очереди. Ну а в случае превышения очереди, скажем, 100 сообщений, дисконнект и мессага о том, что слишком долго были в лаге

слишком сложно.

Отправляем UDP-пакет, ждём 15 секунд, если подтвеждение не пришло, отправляем ещё раз, после 5 попыток делаем вывод о том, что адресат недоступен.

Либо просто посмотреть как это делается в TCP и реализовать тоже самое.

[Артэс]

Сложно? Вроде нет

Делаю активную сетевую игру, там в цикле, 20 раз в секунду посылаются пакеты. Может быть послано 5 сообщений текстовых (чат), дабы они не терялись, думаю лучше с очередью.

[LynXzp]

Конечно не сложно, только так будут медленно передаваться данные.

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

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

Одно но. Велосипед хорошо, только вряд ли TCP хуже.

Кроме того если, например, скорость высокая, но потери тоже не редкость можно сразу высылать по 2 пакета с одними и теми же сообщениями. В крайнем случае - постоянно высылать все сообщения на которые не пришли подтверждения. (лучше так не делать, а то вдруг полудуплекс и ты забьешь всю сеть пакетами - ни одного подтверждения ес-но не получишь)