Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Сети > boost::asio - UDP Server Что, как, с чего начать?

Автор: andrew_121 23.6.2008, 03:07

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

Автор: Lazin 23.6.2008, 07:55

В документации к библиотеке есть пример юдп клиента и сервера... Цитата(andrew_121 @  23.6.2008,  03:07 ) Рассылаемый файл больше объема пакета. Файл будет разбиваться на блоки. Клиенты помимо UDP, подключаются по TCP для получения информации о файле: кол-во пакетов, ID пакетов, запрос определенного пакета. Вопрос, а почему-бы не отправлять все по TCP?  UDP не гарантирует что пакеты придут в том-же порядке, не гарантирует их целостность, в итоге ты реализуешь в своей программе функционал который предоставляет протокол TCP "из коробки", зачем? Цитата(andrew_121 @  23.6.2008,  03:07 ) Так же, нужно реализовать возможность, перехвата пакетов(которые являются частью одного и того же файла) передаваемыми для других программ клиентов, дабы снизить нагрузку на исходящий трафик программы Сервера. тут подробнее, кто передает, кто перехватывает... не очень понятно, и стоит ли оптимизировать здесь что-то...?

Автор: andrew_121 23.6.2008, 09:18

Lazin: Цитата(Lazin @  23.6.2008,  07:55 ) UDP не гарантирует что пакеты придут в том-же порядке И не надо. Пакеты записываются по мере поступления. Цитата(Lazin @  23.6.2008,  07:55 ) не гарантирует их целостность Для этого каждый пакет содержит контрольную сумму блока. И TCP, для запроса мертвого пакета. Цитата(Lazin @  23.6.2008,  07:55 ) кто передает, кто перехватывает Т.е. Клиент номер 1, получает файл 1.bin, клиент 2, позже начинает получать тот-же файл. Но по ходу получения пакетов которые он запрашивает, он перехватывает пакеты предназначавшиеся для 1-го клиента.

Автор: Lazin 23.6.2008, 09:50

Цитата(andrew_121 @  23.6.2008,  09:18 ) Т.е. Клиент номер 1, получает файл 1.bin, клиент 2, позже начинает получать тот-же файл. Но по ходу получения пакетов которые он запрашивает, он перехватывает пакеты предназначавшиеся для 1-го клиента.  перехватить UDP пакет не сложно, но вот программе разобраться, что это именно то, что ей нужно, намного сложнее... представь сколько у тебя будет этих пакетов   проще, если клиент №1 будет сначала опрашивать клиента №2, потом №3 и тд.. на наличие файла(или нужной части файла), а потом уже просить сервер...

Автор: andrew_121 23.6.2008, 10:53

Цитата(Lazin @  23.6.2008,  09:50 ) перехватить UDP пакет не сложно, но вот программе разобраться, что это именно то, что ей нужно, намного сложнее... Для этого, пакет содержит всю необходимую информацию. Цитата(Lazin @  23.6.2008,  09:50 ) проще, если клиент №1 будет сначала опрашивать клиента №2, потом №3 и тд.. на наличие файла(или нужной части файла), а потом уже просить сервер...  Согласен. Но обмен между клиентами запрещен.

Автор: Lazin 23.6.2008, 11:17

Цитата(andrew_121 @  23.6.2008,  10:53 ) Для этого, пакет содержит всю необходимую информацию. я имел ввиду что это сильно усложнит логику программы Цитата(andrew_121 @  23.6.2008,  10:53 ) Согласен. Но обмен между клиентами запрещен. а почему, если не секрет... просто если делать так как ты говоришь, то получается что-то не то.. допустим у нас N клиентов, каждый из них получает М пакетов в секунду, тогда каждый клиент должен обрабатывать N * М пакетов, тоесть всего в системе будет обрабатываться N^2 * М пакетов в единицу времени...

Автор: andrew_121 23.6.2008, 11:26

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

Автор: bsa 23.6.2008, 14:36

Цитата(andrew_121 @ 23.6.2008,  11:26) А есть ли возможность, при обмене между клиентами, регистрировать обьем переданной информации от Клиента1 к Клиенту2 ? Для информирования сервера. Ну чтоб он знал, реально полученный обьем клиентом. Даже если часть обьема получена от обмена между клиентами? А кто мешает? Пусть клиенты, когда обращаются за файлами к серверу, сообщают ему, кто, когда и сколько скачал с них.

Автор: andrew_121 23.6.2008, 15:02

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

Автор: andrew_121 24.6.2008, 13:04

Цитата(bsa @  23.6.2008,  14:36 ) А кто мешает? Пусть клиенты, когда обращаются за файлами к серверу, сообщают ему, кто, когда и сколько скачал с них.  Интересовался - НЕЛЬЗЯ! Обьясните плз. Каким образом клиент и сервер заставить общаться? В примерах boost::asio несколько вариантов сервера. Какой использовать? В чем разница?

Автор: MAKCim 24.6.2008, 21:00

Цитата(andrew_121 @  23.6.2008,  09:18 ) Но по ходу получения пакетов которые он запрашивает, он перехватывает пакеты предназначавшиеся для 1-го клиента.  это невозможно каждый клиент определяется уникальной парой {IP, порт} достаточно на стороне сервера для каждого клиента реализовать отображение {IP, порт} -> смещение где смещение определяет текущую позицию в передаваемом файле

Автор: andrew_121 24.6.2008, 21:02

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

Автор: MAKCim 24.6.2008, 21:10

andrew_121,  и что?

Автор: andrew_121 24.6.2008, 21:38

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

Автор: MAKCim 24.6.2008, 21:56

Цитата(andrew_121 @  24.6.2008,  21:38 ) один UDP пакет, могут поймать все клиенты нет клиенты сидят на разных портах

Автор: andrew_121 24.6.2008, 22:04

Цитата(MAKCim @  24.6.2008,  21:56 ) клиенты сидят на разных портах А я что не могу их настроить на один порт?!

Автор: MAKCim 24.6.2008, 22:16

Цитата(andrew_121 @  24.6.2008,  22:04 ) А я что не могу их настроить на один порт?! нет пара {IP, порт} уникальна если IP = const, то порты должны быть различными если порт = const, IP адреса должны быть различными

Автор: andrew_121 24.6.2008, 22:20

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

Автор: pan2004 24.6.2008, 22:22

Цитата(andrew_121 @  24.6.2008,  13:04 ) Каким образом клиент и сервер заставить общаться?В примерах boost::asio несколько вариантов сервера. Какой использовать? В чем разница? Ну в примерах показаны разные способы организации сервера: 1. С одним объектом asio::io_service и соответственно с одним потоком, который обслуживает сразу несколько соединений(сокетов) 2. принцип "один сокет - один поток - один asio::io_service" 3. еще чтото... В принципе, никто не запрещает комбинировать эти варианты... Добавлено через 2 минуты и 13 секунд Цитата(andrew_121 @  24.6.2008,  22:20 ) А каким образом можно послать пакет таким образом, чтоб его поймали все, и по информации в заголовке определи свой-чужой? Вроде как говорил что надо экономить трафик? Хз как таким путем он будет экономится... А так - это слишком сильно напоминает мне eMule и ему подобные программы

Автор: MAKCim 24.6.2008, 22:32

Цитата(andrew_121 @  24.6.2008,  22:20 ) А каким образом можно послать пакет таким образом, чтоб его поймали все, и по информации в заголовке определи свой-чужой?  для начала определимся: где находятся клиенты? (на локальном узле, в локальной сети или в глобальной сети)  во вторых, зачем усложнять себе жизнь? или условие задачи состоит в том, чтобы использовать комбинацию TCP + UDP?

Автор: andrew_121 24.6.2008, 22:38

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

Автор: MAKCim 24.6.2008, 22:48

Цитата(andrew_121 @  24.6.2008,  22:38 ) По миру.  тогда единственная возможность это многоадресная передача в глобальной сети но эта возможность скорее теоретическая вот скажи, почему бы просто не воспользоваться TCP для взаимодействия с клиентами?    самый простой и эффективный вариант

Автор: andrew_121 24.6.2008, 22:56

Цитата(MAKCim @  24.6.2008,  22:48 ) тогда единственная возможность это многоадресная передача в глобальной сети но эта возможность скорее теоретическая В смысле? Цитата(MAKCim @  24.6.2008,  22:48 ) вот скажи, почему бы просто не воспользоваться TCP для взаимодействия с клиентами?  smile  Потому что я при выборе протокола, гдето вычитал, что датаграмму и UDP пакет могут получить несколько клиентов. И в соответствии с информацией в тобой созданном заголовке, решить: свой-чужой.

Автор: andrew_121 25.6.2008, 05:18

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

Автор: MAKCim 25.6.2008, 09:29

Цитата(andrew_121 @  24.6.2008,  22:56 ) В смысле? в том смысле, что все маршрутизаторы, через которые проходит пакет, должны быть маршрутизаторами многоадресной передачи http://www.pulsewan.com/data101/ip_multicast_basics.htm Цитата(andrew_121 @  24.6.2008,  22:56 ) Потому что я при выборе протокола, гдето вычитал, что датаграмму и UDP пакет могут получить несколько клиентов ага и какой же адрес ты будешь указывать при отправке пакета?

Автор: Lazin 25.6.2008, 09:35

Цитата(andrew_121 @  24.6.2008,  22:38 ) MAKCim - По миру Цитата(andrew_121 @  23.6.2008,  09:18 ) Т.е. Клиент номер 1, получает файл 1.bin, клиент 2, позже начинает получать тот-же файл. Но по ходу получения пакетов которые он запрашивает, он перехватывает пакеты предназначавшиеся для 1-го клиента.  и почему я подумал, что у тебя все клиенты на одной машине

Автор: andrew_121 25.6.2008, 12:58

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

Автор: andrew_121 25.6.2008, 13:31

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

Автор: MAKCim 25.6.2008, 16:02

Цитата(andrew_121 @  25.6.2008,  13:31 ) MAKCim, Вот то что мне нужно!!!  "то" это что? многоадресная передача?

Автор: andrew_121 25.6.2008, 16:32

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

Автор: MAKCim 25.6.2008, 16:58

http://www.kohala.com/start/papers.others/draft-ietf-mboned-intro-multicast-03.txt

Автор: MAKCim 26.6.2008, 10:42

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

Автор: andrew_121 21.7.2008, 18:04

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

Автор: SABROG 22.7.2008, 10:56

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

Автор: andrew_121 22.7.2008, 11:25

Цитата(SABROG @  22.7.2008,  10:56 ) Например вышел фильм "Особо Опасен", его начало тянуть большое количество человек, сервачек заставляет всех подключенных клиентов выкачивать кусочки этого фильма, несмотря на то, что клиентам он не нужен, но тем самым начинают "плодиться" альтернативные источники. В итоге ты будешь лить фильм уже не с одного сервера, а с 20-30 компов. Да, это прекрасная мысль, я это понимаю. Но одно из условий: Между клиентами не должно быть ни какого обмена.(Не байта) Вот и мучкаюсь. Может есть какие нибудь мысли? Поделитесь...

Автор: SABROG 22.7.2008, 11:53

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

Автор: andrew_121 22.7.2008, 13:55

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

Автор: SABROG 22.7.2008, 14:44

Цитата(andrew_121 @ 22.7.2008,  13:55) Нужно по миру! Ну не уж то нет какого нить выхода?!!! Sourceforge использует mirrors (зеркала), чтобы снизить нагрузку, Blizzard использует torrent для снижения нагрузки при раздаче файлов. Велосипеда не получится.

Автор: andrew_121 22.7.2008, 15:50

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

Автор: SABROG 22.7.2008, 17:30

Цитата(andrew_121 @ 22.7.2008,  15:50) SABROG Гм... Что же сделать? А что можешь рассказать про MBone ? Вот тут немного есть http://book.itep.ru/4/44/igmp_449.htm Опять же эта технология скорее всего будет работать только для тех у кого есть реальный IP адрес. А если целыми домашними сетями с одного IP сидит народ то какой смыл. А UDP обычно используют потому, что он обеспечивает быстрое установление соединения и потеря пакетов практически никак не отразится на музыке или видео. Т.ч. смысла использовать для передачи файлов не вижу.

Автор: andrew_121 23.7.2008, 09:24

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

Автор: SABROG 23.7.2008, 10:29

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

Автор: MAKCim 16.8.2008, 22:44

Цитата(SABROG @  22.7.2008,  10:56 ) Насчет MBone. Могу себе такое представить, пользователь докачал фильм, отключился не успев передать остальные куски дальше по-цепочке и все встало. тогда идет передача целевого IP адреса клиенту, от которого был получен кусок данных для данного клиента сам же он успешно выходит из сети

Автор: Олег2005 21.8.2008, 15:01

Цитата(andrew_121 @  24.6.2008,  21:20 ) А каким образом можно послать пакет таким образом, чтоб его поймали все, и по информации в заголовке определи свой-чужой?  Надо слать пакеты бродкастом - если они все внутри одной подсети.

Автор: andrew_121 23.8.2008, 03:45

Цитата(Олег2005 @  21.8.2008,  15:01 ) Надо слать пакеты бродкастом - если они все внутри одной подсети. Это понятно. Но нужно по миру. хз что делать...............

Автор: Олег2005 23.8.2008, 09:33

Цитата(andrew_121 @  23.8.2008,  02:45 ) хз что делать...............  Вариантов - нет. Тогда только по списку.

Автор: MAKCim 23.8.2008, 10:42

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

Автор: andrew_121 25.8.2008, 22:50

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

Автор: semibug 4.6.2009, 20:07

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

Автор: andrew_121 6.6.2009, 10:51

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)