Live dc++ forum
Форма входа
Логин:
Пароль:
Главная | Проблема пассивного режима в DC. Сервер-медиатор для клиента - Страница 3 - Форум | Пятница, 29.03.2024, 09:58
[ Новые сообщения · Участники · Правила форума · Поиск
  • Страница 3 из 3
  • «
  • 1
  • 2
  • 3
Форум » >> » ToDo » Проблема пассивного режима в DC. Сервер-медиатор для клиента
Проблема пассивного режима в DC. Сервер-медиатор для клиента
dolchegobanoДата: Воскресенье, 21.06.2009, 19:28 | Сообщение # 1
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
У меня есть ряд вопросов и кое-какие бредовые идеи smile
Почему бы хабу не взять на себя функции сервера-медиатора, который будет соединять пассивных юзеров друг с другом? Существует софт, который делает это: например пресловутый Скайп или вот такая штучка - http://wippien.com/mediator.php
Если в Грейлинке есть функция веб-сервера и возможность создания мини-хабов, то почему бы не научить Грейлинк доброму делу для братьев наших меньших — перенаправлению запросов между пассивными юзерами?
Сразу признаюсь — у меня очень поверхностные знания о сетевых технологиях, и я многого не понимаю. Программировать тоже не умею. Я просто продвинутый юзер smile Прошу просветить, если я заблуждаюсь.
На хабах бывает очень много пассивных юзеров, и с ними надо что-то делать. Если непосредственно на хаб будет большая нагрузка, то почему бы не перенести часть обязанностей на плечи (компы) юзеров с выделенным IP? Как это может выглядеть на практике: пассивный юзер ищет среди знакомых активного, который включит для него галочку в своём клиенте. Благодаря галочке пассивный друг сможет скачивать на этом хабе с других пассивов.
Есть другой вариант: админ хаба раздаёт пассивным юзерам право качать с других пассивов (типа VIP-пассивки smile То есть некая привилегия для обладателей большой шары, но не имеющих выделенного ипа. Может быть, сервер-медиатор будет реализован в виде обслуживающего бота.

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

У кого есть какие суждения по этой проблеме?


гей-хаб dchub://queers.dyndns.org
 
4e4akoДата: Пятница, 03.07.2009, 00:45 | Сообщение # 31
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote (hmury)
радуйся после апгрейда uTorrent до 1.9.x будешь качать и с пассивных пиров

уже юзал альфу - толку "0"
ни обхода шейпера (что наблюдается у скайпа частенько), ни увеличения коннектов sad
от ipv6 туннелинга толку и то больше..
 
hmuryДата: Пятница, 03.07.2009, 00:48 | Сообщение # 32
Генерал-лейтенант
Сообщений: 599
Репутация: 32
Статус: Offline
Quote (4e4ako)
уже юзал альфу - толку "0"

тут проблема с пирами. все должны проапгрейдить клиент на поддержку UDP-соединений sad
в дц++, даже если сделать, тоже пройдут годы, прежде чем станет заметен результат sad
 
4e4akoДата: Пятница, 03.07.2009, 00:55 | Сообщение # 33
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote (hmury)
клиент на поддержку UDP-соединений

bittorrent, если не изменяет память уже несколько лет поддерживает udp - для него и трекеры с udp анонсами делали..

в общем udp соединения были и много (uTP - флаг) - иногда даже больше чем обычных, но результата не было видно.

Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 01:52
 
IRainmanДата: Пятница, 03.07.2009, 01:03 | Сообщение # 34
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
http://clip2net.com/clip/m14997/1246567695-clip-16kb.png
и
STUN client version 0.94
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b
ps: провайдер: тоже акадо, Москва, точнее Зеленоград, подключение по эзернету, количество пользователей около 10тыс.
но это уже провайдерский нат

Добавлено (03.07.2009, 01:03)
---------------------------------------------
завтра ещё инфу с нескольких сеток по окрестностям выложу smile
а сейчас спааать


Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++


Сообщение отредактировал IRainman - Пятница, 03.07.2009, 00:58
 
4e4akoДата: Пятница, 03.07.2009, 14:20 | Сообщение # 35
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote
STUN client version 0.94
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b


однако вот что мне показал родимый мастдай:

Quote
C:\>netsh interface ipv6 show teredo
Параметры Teredo
---------------------------------------------
Тип : client
Имя сервера : teredo.ipv6.microsoft.com
Интервал обновления клиента: 60 секунд
Порт клиента : 34567
Состояние : offline
Ошибка : клиент за симметричным NAT

Добавлено (03.07.2009, 14:20)
---------------------------------------------

Quote
предлагаю скачать
http://prdownloads.sourceforge.net/stun/client.exe?download

и выполнить:
C:\NAT_TEST> client.exe stun.xten.com

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

 
SMTДата: Пятница, 03.07.2009, 14:49 | Сообщение # 36
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
Quote (4e4ako)
посмотрел пакетным снифером что он делает..
не похоже, что он работает "правильно" - т.к. пакеты получил только с 1 адреса(на который и отправлял), а ведь для полноценного теста нужно 2 внешних сервера?
или я че то напутал?

а я покопался в исходниках этого сервера-клиента. случай, когда сессия может быть продолжена с другого IP, у них называется "Full-Cone NAT". так называемый "Port Restricted Nat" означает, что пакеты должны приходить с того же IP и на тот же порт назначения, пакет с которого открыл NAT. это усложняет процесс, но не делает его невозможным.
 
IRainmanДата: Пятница, 03.07.2009, 15:18 | Сообщение # 37
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
Quote
А, ну у меня IPv4 SNAT & DNAT. Ядро 2.6.24 Realtime. Провайдер - NBN (NetByNet). Это с компа за роутером.

STUN client version 0.94
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Error connection reset - host not reachable
Message header length doesn't match message size: 68 - 4294967295
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b



Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++
 
4e4akoДата: Пятница, 03.07.2009, 15:46 | Сообщение # 38
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote (SMT)
означает, что пакеты должны приходить с того же IP...

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

тестилка от Мюнхенского университета информатики:
http://nattest.net.in.tum.de/ показала тоже самое "port restricted"

Quote
Your NAT-Box has the following properties:

Port restricted NAT detected
Preserves port number Does not support hairpin of media
No UPnP-Device found.

no UPnP device found

Testing UDP...

UDP Hole Punching successful

Testing TCP...sending testing request...

TCP HolePunching (low TTL) not successful

Testing TCP...sending testing request...

TCP HolePunching (high TTL) successful
Testing TCP...sending fake FTP-Request...

PORT 192,168,0,1,67,48
TCP HolePunching (FTP-ALG) not successful

а я тут подумал а как же таймауты? если соединение разорвано на stun сервере это еще не значит, что шлюз провайдера все еще не ждет ответа от него.. который stun сервер через секунду ему и посылает думая, что он устанавливает новое соединение...

хм.. что то намудрили мы тут )))

Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 17:31
 
SMTДата: Пятница, 03.07.2009, 17:36 | Сообщение # 39
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
Quote (4e4ako)
+с того же порта на который вы отправляли данные.. но тогда это ничем не отличается от установленного и поддерживаемого соединения..
т.е. для соединения двух пассивов в таком режиме они будут долбить шлюзы друг друга пока не получится установить коннект? веселая теория ^ ^

теория имхо такая

1. Full-Cone NAT, random port

клиент1 посылает на STUN UDP-пакет с порта xx, он через NAT меняет порт на yy и STUN рапортует, что внешний IP=z.z.z.z, порт сменён с xx на yy.
клиент1 через хаб говорит клиенту2 ConnectToMe z.z.z.z:yy

2. Port Restricted NAT, preserved port

клиент1 слушает UDP-порт xx, клиент2 порт yy. на ADC-хабах UDP-порт известен для всех активных клиентов, NMDC-хабы видимо не будут поддерживаться

клиент1 посылает клиенту2 через хаб ConnectToMe xx и бросает пакет на порт yy клиенту2.
пакет создаёт NAT-правило:
внешний IP=клиент2-роутер, внешний порт=yy, внутренний порт=xx, внутренний IP=клиент1

клиент2 посылает пакет клиенту1 с порта yy на порт xx и создаёт в своём NAT аналогичное правило

неудобно то, что оба случая реализуются разными алгоритмами, избыточность получается

 
4e4akoДата: Пятница, 03.07.2009, 18:10 | Сообщение # 40
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote (SMT)
клиент1 слушает UDP-порт xx, клиент2 порт yy. на ADC-хабах UDP-порт известен для всех активных клиентов, NMDC-хабы видимо не будут поддерживаться

в коннекттоми все равно придется еще дописывать с какого порта клиент2 должен инициировать подключение.. дабы если все будут ломиться на один порт будет работать коряво..

ну главное научить клиентов узнавать за каким типом НАТа они и в зависимости от этого - правильно отсылать\получать команды "коннекттоми".

Сообщение отредактировал 4e4ako - Пятница, 03.07.2009, 18:44
 
SMTДата: Пятница, 03.07.2009, 18:57 | Сообщение # 41
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
Quote (4e4ako)
в коннекттоми все равно придется еще дописывать с какого порта клиент2 должен инициировать подключение

в любом случае, в adc-команды можно дописывать любые свои параметры, как и в INF-тег клиента. nmdc фильтрует всё лишнее

Quote (4e4ako)
дабы если все будут ломиться на один порт будет работать коряво..

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

 
4e4akoДата: Пятница, 03.07.2009, 19:13 | Сообщение # 42
Майор
Сообщений: 87
Репутация: 2
Статус: Offline
Quote (SMT)
я думал наоборот, один слушающий udp-сокет будет эффективнее.

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

 
SMTДата: Пятница, 03.07.2009, 19:22 | Сообщение # 43
Генерал-лейтенант
Сообщений: 514
Репутация: 28
Статус: Offline
Quote (4e4ako)
я имел ввиду что если все будут ломиться на этот порт, то клиент-2 не сможет одновременно передавать данные с одного порта для нескольких клиентов-1.. или мои познания еще не доросли до понимания сетевых протоколов?

udp-сокет не имеет таких ограничений. src ip/port прибиндены. dst ip/port указываются с каждым пакетом
 
IRainmanДата: Пятница, 03.07.2009, 22:53 | Сообщение # 44
Рядовой
Сообщений: 16
Репутация: 2
Статус: Offline
ммм, смотрю дело движется
Quote
теория имхо такая…

даже не имхо а точно
единственное уя вот чего не пойму
что если будет такая ситуация: конечный юзер сидит за роутером, а роутер в свою очередь подключён к сетке, где соответсвенно имеется второй(провайдерский) НАТ т.е. надо как то цепочки предусмотреть…
с ADC будет проще, но всё равно цепочка получится

Quote
неудобно то, что оба случая реализуются разными алгоритмами, избыточность получается

это да

ps:
Primary: Address Restricted Nat, random port, will hairpin
Return value is 0x2
это с роутера DLINK DI-524, IP выделенный
чувствуется что все кто сидит за роутерами проблем не испытают


Официальный сайт FlylinkDC++
Блог разработчиков FlylinkDC++
 
dolchegobanoДата: Понедельник, 16.11.2009, 12:41 | Сообщение # 45
Сержант
Сообщений: 34
Репутация: 0
Статус: Offline
ну так как продвигается работа над проблемой пассивного режима?
***
В последнее время для обмена файлами с друзьями (тоже сидящими за натом) я пользуюсь Gbridge - весьма простая и эффективная софтина. Неужели нельзя прикрутить что-то подобное к дц-клиенту или хабу?


гей-хаб dchub://queers.dyndns.org
 
Форум » >> » ToDo » Проблема пассивного режима в DC. Сервер-медиатор для клиента
  • Страница 3 из 3
  • «
  • 1
  • 2
  • 3
Поиск:


В движке поковырялся LiveDC :p © 2024
Сделать бесплатный сайт с uCoz