Есть задача: Множеству клиентов, раздавать один файл.
Предполагаю использовать boost::asio::ip::udp::socket.
Рассылаемый файл больше объема пакета. Файл будет разбиваться на блоки. Клиенты помимо UDP, подключаются по TCP для получения информации о файле: кол-во пакетов, ID пакетов, запрос определенного пакета.
Так же, нужно реализовать возможность, перехвата пакетов(которые являются частью одного и того же файла) передаваемыми для других программ клиентов, дабы снизить нагрузку на исходящий трафик программы Сервера.

С протоколом UDP не работал. Толком не представляю с чего начать.
По ходу общения буду задавать конкретные вопросы.
Давайте обсудим этот вопрос в слух.

Это сообщение отредактировал(а) andrew_121 - 23.6.2008, 05:28

В документации к библиотеке есть пример юдп клиента и сервера...


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


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

Lazin:

И не надо. Пакеты записываются по мере поступления.

Для этого каждый пакет содержит контрольную сумму блока. И TCP, для запроса мертвого пакета.

Т.е. Клиент номер 1, получает файл 1.bin, клиент 2, позже начинает получать тот-же файл. Но по ходу получения пакетов которые он запрашивает, он перехватывает пакеты предназначавшиеся для 1-го клиента.

перехватить UDP пакет не сложно, но вот программе разобраться, что это именно то, что ей нужно, намного сложнее... представь сколько у тебя будет этих пакетов  
проще, если клиент №1 будет сначала опрашивать клиента №2, потом №3 и тд.. на наличие файла(или нужной части файла), а потом уже просить сервер...

Для этого, пакет содержит всю необходимую информацию.


Согласен. Но обмен между клиентами запрещен.

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


а почему, если не секрет...
просто если делать так как ты говоришь, то получается что-то не то..
допустим у нас N клиентов, каждый из них получает М пакетов в секунду, тогда каждый клиент должен обрабатывать N * М пакетов, тоесть всего в системе будет обрабатываться N^2 * М пакетов в единицу времени...

Клиенты сети платят за трафик.

Интересно.
А есть ли возможность, при обмене между клиентами, регистрировать обьем переданной информации от Клиента1 к Клиенту2 ?
Для информирования сервера. Ну чтоб он знал, реально полученный обьем клиентом. Даже если часть обьема получена от обмена между клиентами?


Это сообщение отредактировал(а) andrew_121 - 24.6.2008, 20:34

А кто мешает? Пусть клиенты, когда обращаются за файлами к серверу, сообщают ему, кто, когда и сколько скачал с них.

С принципом определился.
Как правильно разложить задачу по этапам?
С чего начать реализацию?
Что посоветуете почитать?

Интересовался - НЕЛЬЗЯ!
Обьясните плз.
Каким образом клиент и сервер заставить общаться?
В примерах boost::asio несколько вариантов сервера. Какой использовать? В чем разница?

это невозможно
каждый клиент определяется уникальной парой {IP, порт}
достаточно на стороне сервера для каждого клиента реализовать отображение {IP, порт} -> смещение
где смещение определяет текущую позицию в передаваемом файле

MAKCim - Пакеты передаются по UDP, а контроль по TCP.

andrew_121, 
и что?

MAKCim - Блин... А что-то не то говорю?
Ну объясни. Я насколько понимаю, один UDP пакет, могут поймать все клиенты, и по информации в нем, определить, свой-чужой.

нет
клиенты сидят на разных портах

А я что не могу их настроить на один порт?!

Это сообщение отредактировал(а) andrew_121 - 24.6.2008, 22:06

нет
пара {IP, порт} уникальна
если IP = const, то порты должны быть различными
если порт = const, IP адреса должны быть различными

А каким образом можно послать пакет таким образом, чтоб его поймали все, и по информации в заголовке определи свой-чужой?

Ну в примерах показаны разные способы организации сервера:
1. С одним объектом asio::io_service и соответственно с одним потоком, который обслуживает сразу несколько соединений(сокетов)
2. принцип "один сокет - один поток - один asio::io_service"
3. еще чтото...
В принципе, никто не запрещает комбинировать эти варианты...

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

Вроде как говорил что надо экономить трафик?
Хз как таким путем он будет экономится...
А так - это слишком сильно напоминает мне eMule и ему подобные программы

для начала определимся: где находятся клиенты? (на локальном узле, в локальной сети или в глобальной сети) 
во вторых, зачем усложнять себе жизнь? или условие задачи состоит в том, чтобы использовать комбинацию TCP + UDP?

Это сообщение отредактировал(а) MAKCim - 24.6.2008, 22:33

pan2004

Исходящий трафик сервера. Если один пакет получат сразу несколько клиентов, то исходящий трафик сервера меньше.
MAKCim - По миру.

тогда единственная возможность это многоадресная передача в глобальной сети
но эта возможность скорее теоретическая

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

В смысле?


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

Вот что еще нарыл:
http://ru.wikipedia.org/wiki/RUDP
http://ru.wikipedia.org/wiki/SCTP

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


ага
и какой же адрес ты будешь указывать при отправке пакета?   

Это сообщение отредактировал(а) MAKCim - 25.6.2008, 09:33

и почему я подумал, что у тебя все клиенты на одной машине  

Да, не эрудирован.
Помогите разобраться.

MAKCim, Вот то что мне нужно!!!  
Как мне его заюзать? С чего начать?


Это сообщение отредактировал(а) andrew_121 - 25.6.2008, 13:58

"то" это что?
многоадресная передача?

MAKCim, Ну ДА. А что не так?

тут

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

Я вернулся. Ездил по делам.
Что там по поводу - "MBone". Расскажи плиз по подробнее...

Вы второй DirectConnect или Torrent придумываете ?

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

В некоторых системах используют еще такую фишку - кешируют популярные чанки (куски) на клиентских тачках, которые не запрашивали даже эти куски. Например вышел фильм "Особо Опасен", его начало тянуть большое количество человек, сервачек заставляет всех подключенных клиентов выкачивать кусочки этого фильма, несмотря на то, что клиентам он не нужен, но тем самым начинают "плодиться" альтернативные источники. В итоге ты будешь лить фильм уже не с одного сервера, а с 20-30 компов.

Да, это прекрасная мысль, я это понимаю. Но одно из условий: Между клиентами не должно быть ни какого обмена.(Не байта)
Вот и мучкаюсь.
Может есть какие нибудь мысли? Поделитесь...

Тут есть проблемка тогда. Если брать мультикастинг или броадкастинг, то это работает только внутри одного хаба/маршрутизатора. У меня дома вообще получается, что в этот сегмент попадает только 4-5 компьютеров моего подъезда, т.е. те что висят со мной на одном хабе. По этой же причине сниффер может ловить только траффик с этих компьютеров (это если не юзать ARP Poisoning).

Отсюда могу сделать заключение, что при текущих условиях твоя задача выполнима частично.

Нужно по миру!
Ну не уж то нет какого нить выхода?!!!

Sourceforge использует mirrors (зеркала), чтобы снизить нагрузку,
Blizzard использует torrent для снижения нагрузки при раздаче файлов.

Велосипеда не получится.

SABROG Гм... Что же сделать? А что можешь рассказать про MBone ?

Вот тут немного есть http://book.itep.ru/4/44/igmp_449.htm

Опять же эта технология скорее всего будет работать только для тех у кого есть реальный IP адрес. А если целыми домашними сетями с одного IP сидит народ то какой смыл.

А UDP обычно используют потому, что он обеспечивает быстрое установление соединения и потеря пакетов практически никак не отразится на музыке или видео. Т.ч. смысла использовать для передачи файлов не вижу.



Это сообщение отредактировал(а) SABROG - 22.7.2008, 17:32

Ну не уж-то нет возможности реализовать это нормальными средствами?
Должен же быть какой-то стандартный протокол. Не может быть чтоб мне единственному это понадобилось !!!


Это сообщение отредактировал(а) andrew_121 - 23.7.2008, 09:26

Все реализовывают, но опять же, кто ? VLC - video lan client, потоковое вещание, где потеря пакетов не смертельна, ну подумаеш выпадет 1 из 24 кадров в секунду, ты даже этого не заметишь.

Все что касается IGMP будет работать только в том случае, если оборудование провайдера как сервера, так и всех его клиентов будет позволять подписку на мультикастинг. Это проблема именно железа.

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

Надо слать пакеты бродкастом - если они все внутри одной подсети.

Это понятно. Но нужно по миру. хз что делать...............

Вариантов - нет. Тогда только по списку.

использовать принцип Mbone
на каждом клиенте запускаем демон, который открывает 2 порта
первый порт используется для получения пакета инициализации со списком (в бинарном виде) IP адресов узлов сети
второй порт используется непосредственно для передачи пакетов
задача демона - передать данные клиенту на этом узле и диспетчерезировать их дальше по цепочке следующему узлу, на котором работает этот же демон
если он аварийно завершается до того как пакет будет доставлен, ядро сгенерирует ICMP пакет, по которому можно определить факт завершения и перейти к следующему узлу цепочки
если пакет получен, осуществляется передача пакета дальше
после успешной отправки идет передача пакета подтверждения отправки на узел-родитель
если демон не получил подтверждения в течении определенного таймаута (вычисляется) выбирается очередной узел из списка
если демон завершает работу не аварийно, идет передача пакета диспетчерезации на первый порт узла-родителя
при следующей передаче будет использован следующий IP адрес

MAKCim, Приогромное спасибо  
Осталось только ТЗ изменить. Согласятся ли...???

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

semibug, Да. Но идея умерла так и не родившись. Читайте выше...