Winsock2.h:udp фрагментирование данных

Доброго времени суток!

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

P.S.: возможно кто-то даст ссылку, где можно посмотреть реализацию гарантированной доставки данных по UDP.

0

если это - требование, не завидую. или почему нельзя использовать TCP ? если нельзя, то нужно самому реализовать все то же, что уже имеется в TCP: разбиение и нумерация пакетов, отслеживание доставки, запросы на повторную передачу, сборка, ... зачем изобретать велик?

0

UDP протокол не гарантирует доставку. Все. Точка.
Если тебе нужна гарантия доставки, то используй TCP. Ну или пиши свой протокол поверх UDP - получится тот же TCP, только намного хуже по качеству

0

За дурака не принимайте только Я знаю, что не гарантирует! Потому так вопрос и ставится... Вы видимо самого вопроса не поняли... Если так, то попробуйте еще раз прочитать

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

0

Сообщение от Lowbacki За дурака не принимайте только

"я знаю, ты думаешь, что я дурак!"

а я попробую снова задать тот же вопрос: а вдруг ответят?

почему нельзя использовать TCP

у нас в одном проекте тоже используется UDP, но мы ничего не можем поделать: другая сторона не поддерживает ничего другого.

но если мы собираемся

использовать средства (функции) для фрагментации большого буфера (большой в том смысл, что не влезет в один UDP пакет) так, чтобы можно было самому дописывать некоторые данные (для обеспечения гарантии доставки) к полученным фрагментам в каждый UDP пакет,

значит все в наших руках, мы можем на каждой стороне делать что хотим. и при этом выбираем все же UDP. навернякак причина есть. скажи какая?

0

Какая разница в чём причина?! Какое это отношение имеет к делу?

0

Ну интересуется человек.
Может ты неправильный метод решения задачи выбрал ?
Например может тебе лучше SCTP использовать ? (http://ru.wikipedia.org/wiki/SCTP)

0

Просто поставлена школярская задача, т.е. не для практики в жизни. По существу может кто-нибудь помочь ?

0

Сообщение от Lowbacki Просто поставлена школярская задача, т.е. не для практики в жизни. По существу может кто-нибудь помочь ?

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

1

Не совсем понял, очередная отправленная на приемник пронумерованная "порция" данных - это (?)один(?) UDP пакет с номером части сообщения, которую он несёт?

0

Сообщение от Lowbacki Не совсем понял, очередная отправленная на приемник пронумерованная "порция" данных - это (?)один(?) UDP пакет с номером части сообщения, которую он несёт?

совершенно верно. нам известна физическая конфигурация сети, а также известно, что кусок длиной М проходит через любое устройство без разбивки или усечения. поэтому ни один пакет не должен быть длинее этой величины. зато имеется гарантия, что если пакет пришел, то он тут веь. в tcp, например, вы говорите
, и читаете, скажем, 512 байт. хотя нам известно, что согласно нашему протоколу следующее сообщение должно бы иметь длину 2000 байт. но где-то по пути встретилось устройство, которое работает с пакетами макс. длиной 512, и эти 2000 были им разбиты на 4 части. собирать их в кучу - задача принимающей стороны. tcp лишь гарантирует, что мы получим все пакеты в правильном порядке. нам необходимо все равно реализовать какой-то хидер, который будет описывать каждое сообщение. запутал я тебя?

0

Мне кажется у вас задача ставилась задача сложнее чем у меня..
Попробую спросить по-другому
В общем я думаю использовать функцию sendto() и передавать по одному udp-пакету приемнику. В каждом таком пакете находится partlen байт, из которых часть байт отвечают за гарантированную доставку этого пакета, а оставшаяся часть является частью сообщения, которое мы передаём.

Вопрос 1.
Таким образом, получаем вопрос
Дано: buffer - передаваеоме сообщение, buflen - его длина в байтах
Найти: partlen - длина в байтах
Вопрос 2.
И кстати, будет ли быстрее, если я буду подавать не по части данных, влезающих в один пакет, а по большей части? Имеется ввиду два варианта решения:
1) buflen == максимальной длине udp пакета, который точно придёт не разбившись по пути на несколько пакетов ни на одном устройстве
2) buflen == некоторой величине, что часть сообщения не влезет в один udp пакет. В этом случай нужно иметь ввиду, что
P(A)=e^k, где
P(A) - вероятность, что отправленный функцией sendto буфер buf придёт(не придётся делать
повторный запрос)
e - вероятность, что 1 отправленный udp-пакет придёт
k - количество udp-пакетов, на которое разбивает buf при отправке функцией sendto

0

Сообщение от novi4ok если нумерация нарушалась, приемник передавал запрос на подтверждение, в котором сообщал номер последнего полученного куска.

Хмм.... Что-то представляется не больно то удачным. Пример: сообщение 12345, разбито на кусочки 1, 2, 3, 4, 5. На приемный конец успешно пришли кусочки 1, 3, 4, 5. Кусочек 2 потерялся где-то по дороге. Что должен передать приемник, и что потом должен сделать передатчик?

0

В итоге мучает меня как с самого начла когда создавал тему в основном только один вопрос: какая максимальная длина buflen udp-пакета, который точно придёт не разбившись по пути на несколько пакетов ни на одном устройстве.

просто я думаю делать так:
1) разбил сообщение на части длиной partlen=buflen-headerlen, где headerlen - длина заголовка, который я сам буду дописывать к очередной части перед её отправкой;
2) беру очередную часть, записываю её в буфер buf, дописываю в buf заголовок(обеспечивающий гарантию доставки)
3) отправляю: sendto(buf,buflen,...);
Дальше возможны варианты: либо ждать пока придёт подтверждение о приходе отпраленного пакета, либо через некторый таймаут ждать от приемника номера не пришедших и последний пришедший.
4) через определённый таймаут

0

Сообщение от Lowbacki В итоге мучает меня как с самого начла когда создавал тему в основном только один вопрос: какая максимальная длина buflen udp-пакета, который точно придёт не разбившись по пути на несколько пакетов ни на одном устройстве.

Ежели мой склероз мне не изменяет, все сети должны пропускать датаграммы размером 576 байт, не разбивая их на более мелкие. [Ну, за исключением совсем уже экзотических сетей.] Из этой величины вычти: 20 байт - размер IP заголовка, 8 байт - размер UDP заголовка, итого 548 байт останется на твои пользовательские данные. Как ты их заполнишь твоим протокольным заголовком (без него ты вряд ли обойдешься, как уже говорилось), собственно данными и, возможно, контрольной суммой, - решать тебе.....

1

Сообщение от CheshireCat Хмм.... Что-то представляется не больно то удачным. Пример: сообщение 12345, разбито на кусочки 1, 2, 3, 4, 5. На приемный конец успешно пришли кусочки 1, 3, 4, 5. Кусочек 2 потерялся где-то по дороге. Что должен передать приемник, и что потом должен сделать передатчик?

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

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

Добавлено через 2 минуты

Сообщение от Lowbacki В итоге мучает меня как с самого начла когда создавал тему в основном только один вопрос: какая максимальная длина buflen udp-пакета, который точно придёт не разбившись по пути на несколько пакетов ни на одном устройстве. просто я думаю делать так: 1) разбил сообщение на части длиной partlen=buflen-headerlen, где headerlen - длина заголовка, который я сам буду дописывать к очередной части перед её отправкой; 2) беру очередную часть, записываю её в буфер buf, дописываю в buf заголовок(обеспечивающий гарантию доставки) 3) отправляю: sendto(buf,buflen,...); Дальше возможны варианты: либо ждать пока придёт подтверждение о приходе отпраленного пакета, либо через некторый таймаут ждать от приемника номера не пришедших и последний пришедший. 4) через определённый таймаут

у вас какие сценарии возможны? сами ли вы их определяете, или "поставлены в обстоятельства"? всегда ли передачу инициирует одна и та же сторона?

0

Сам определяю (пишу и клиент, и сервер). Сценарии... Не совсем понял. Просто хочу написать две функции Send и Recv. Первая гарантировано отправляет сообщение, а вторая принимает его соответствующим образом.

у вас какие сценарии возможны? сами ли вы их определяете, или "поставлены в обстоятельства"? всегда ли передачу инициирует одна и та же сторона?

И сервер, и клиент будут использовать функции и Send, и Recv, но они только "говорят" что отправить или куда принять.

0

Сообщение от novi4ok приемник подтверждает каждый полученный кусок. если передатчик не получает подтверждения в течение определенного времени, он просто повторяет последний переданный.

Вероятно, имелось в виду "тот кусок, на который не получено подтверждение"? Потому что иначе, например (смотрим пример выше) если не получено подтверждение на кусок 2, а "последний переданный" - кусок 5, то это будет пустая долбежка никому не нужного куска. Можно, конечно же, после каждого переданного куска ждать по таймауту прихода подтверждения именно на него. Но это серьезно снизит скорость передачи - поскольку придется рассчитывать на наихудший случай, передачу через "медленную" сеть, а время таймаута в "медленной" сети может быть намного! больше времени собственно передачи куска. А если не повезет и подтверждение не дойдет (где-то потеряется)? Повторная передача успешно принятого приемником куска и опять таймауты...
Кстати, Lowbacki надо уметь обрабатывать и такой сценарий: переданы куски 12345, на прием они пришли в порядке 13425 - ибо в сетях со сложной топологией датаграммы могут путешествовать по извилистым путям, в т.ч. с существенно разным временем доставки от передатчика к приемнику.
А, например, такой сценарий: передаем 12345, прием: 1325 (кусок 2 пришел позже 3, кусок 4 потерян) ?

0

Сообщение от CheshireCat Вероятно, имелось в виду "тот кусок, на который не получено подтверждение"? Потому что иначе, например (смотрим пример выше) если не получено подтверждение на кусок 2, а "последний переданный" - кусок 5, то это будет пустая долбежка никому не нужного куска. Можно, конечно же, после каждого переданного куска ждать по таймауту прихода подтверждения именно на него.

именно так и было сделано.

Добавлено через 3 минуты

Сообщение от Lowbacki Сам определяю (пишу и клиент, и сервер). Сценарии... Не совсем понял. Просто хочу написать две функции Send и Recv. Первая гарантировано отправляет сообщение, а вторая принимает его соответствующим образом. И сервер, и клиент будут использовать функции и Send, и Recv, но они только "говорят" что отправить или куда принять.

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

0

Кстати, Lowbacki надо уметь обрабатывать и такой сценарий: переданы куски 12345, на прием они пришли в порядке 13425 - ибо в сетях со сложной топологией датаграммы могут путешествовать по извилистым путям, в т.ч. с существенно разным временем доставки от передатчика к приемнику. А, например, такой сценарий: передаем 12345, прием: 1325 (кусок 2 пришел позже 3, кусок 4 потерян) ?

Для этого каждый переданный пакет будет иметь свой номер и на примеике они будут собиратсья в соответствующем порядке: приём 1325=>123_5 => запрос повтора 4-го

Добавлено через 28 минут
Рассмотрим ситуацию.
1) передатчик будет отправлять функцией sendto(buf, buflen,...) части своего сообщения длиной, например, buflen==1500байт.
2) По ходу доставки на приемник отправленный с передатчика один udp-пакет разобьётся например на 4 пакета

Какие возможны варианты на приемнике? В том смысле, что надо ли приемнику учитывать возможное дробление пакета по пути? Или переданный пакет (те самые 1500байт) либо придёт, либо не придёт?

0