Вопрос по UDP.

[Виктор]

Доброго все времени суток.Мне поставили задачу написать программу передачи файлов по UDP в С++ причем связь является односторонней т.е. сервер посылает клиенту данные файла но ответа от него никакого не получает.В связи с этим возникает правомерный вопрос а реально ли это вообще рализовать если учесть что UDP не надежный протокол и данные могут не дойти что критично для копирования файлов.

[Алексей++]

не, без обратной связи нереально. Получатель должен хотя бы ID файла вернуть - что вот, мол, да, получил я его.

[Виктор]

Спсибо за ответ теперь осталось убедить начальника в том что это нереально)))

[Алексей++]

Виктор,  убедить очень просто, дать ему почитать про особенности протокола какую нибудь бумажку. http://ru.wikipedia.org/wiki/UDP

[Михалыч]

Зависит от важности данных и организации обмена. У меня был вариант (вынужденная мера, однако нет ничего более постоянного, чем что-то временное до сих пор работает, и неплохо) когда контроллер отправлял по UDP данные копъютеру на обработку, без какого либо подтверждения получения оных от него Но! Контроллер был "самодостаточным" т.е. работал прекрасно без верхнего уровня, полностью автоматически. Данные (а их было немного, около 150 float-параметров) отправлял регулярно, каждую секунду, по принципу: нате получите, не получили, плевать, я через секунду еще пришлю... Причем летели ВСЕ данные, и те которые изменились за этот промежуток, и остальные

[Алексей++]

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

[Михалыч]

И я про тоже самое Все зависит от задачи... Мне раз в секунду было - за глаза достаточно А если мониторить, например, уровень грунтовых вод - то реальным временем может быть съем данных раз в 2-3 часа - тоже себе такое "реальное время" и данные будут актуальны.
Так что, кто знает, что там за "файл" у клиента.

[Михалыч]

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

[Sla]

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

[Алексей++]

Михалыч, а если это шпиёнские данные ? ) Америка будет недовольна, если пропадут пакеты

[Михалыч]

Ну да... и передавать вместе с файлом контрольную сумму, на которую отдельно завести контрольную сумму - далее рекурсия
Кто гарантирует ее целостность, как и файла?
Так можно потихоньку еще один TCP сочинить

[Михалыч]

Хорошо, если вся посылка данных будет укладываться в один ethernet-пакет. Тогда еще ничего - потеряли и нет его... А если их будет несколько? И в середине парочка недолетит? Только контроль на уровне "кусочков" поможет. Если я правильно помню поле данных в пакете от 40 до 1500 байт.

[Алексей++]

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

[Виктор]

Так в том то и проблема что требуется  чтобы все файлы передались нормально)))Одного я понять не могу зачем делать передачу файлов на UDP если по сути  для их нормальной передачи приходится описываать тот же TCP.(Не ужели настолько велик выйгрышь в скорости)

[Виктор]

Еще раз всем спасибо за ответы)

[RXL]

Кстати, верхним пределом пакета советую не увлекаться, т.к. MTU всего пути может быть меньше (например, при использовании туннелирования): возможна фрагментация IP пакета и, если установлен бит DF, то пакет будет отброшен.
http://ru.wikipedia.org/wiki/GRE_%28%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%29#.D0.9F.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D0.BC.D0.B0_DF-.D0.B1.D0.B8.D1.82.D0.B0

[Алексей++]

если файл по TCP передаётся во много раз дольше, чем устанавливается связь, то лучше всё таки TCP применить - меньше гемору. ИМХО )

Мы применили UDP только раз - сообщения очень короткие, но правильность доставки важна. TCP-соединение же долго устанавливается, несколько секунд. У нас по UDP и отправляется, и подтверждение возвращается

[lapulya]

Алексей1153++,
 

TCP-соединение же долго устанавливается, несколько секунд.

Если ты про конкретно свою сеть, то ок, в общем же случае это неправда (причем очень большая, да еще и в обе стороны, т.е. как в большую, так и в меньшую)

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

Итого, надо подойти к начальнегу и сказать что это технически невозможно (при исходном условии).

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

[RXL]

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

[Алексей++]

lapulya, RXL, все вопросы не ко мне, а к нашим железячникам, колдующим над SIM300 Говорят, у них так

[darkelf]

Алексей1153++ странно, т.к. установ связи TCP это всего 3 пакета: SYN, SYN/ACK, ACK.

[Алексей++]

Ну я сам на железном уровне не занимался этим. У них там сначала по GPRS установка соединения происходит - наверное отсюда тормоз. Деталей не знаю