Здравствуйте, а подскажите пожалуйста хорошую доку по настройке прокси серевера для сокетов... Хочу настроить пиринговую систему через НАТ маршрутизацию.... помогите плз.

можно поподробнее о НАТ маршрутизации и "пиринговой системе" ... ?
( слова интересные )

Ну в общем юзаю я пиринговую систему с сервера все работает, а вот юзаю я ее через нат уже не работает... а точнее у p2p работает тока чат, но надо чтоб еще и файлы качались....

извиняюсь, просто вас очень трудно понять.
вы можете, еще раз перечитать мой вопрос, и наконец ОТВЕТИТЬ на него ?
какую "пиринговую систему" вы используете ?
почему вы не почитаете документацию о том как работать с ней из-за локальной сети ? ( все пакеты п2п , о которых я знаю поставляют инструкции по использовании этого ПО в условиях локальной сети )

да как таковой инструкции нет, пиринг локальный, т.е. нет такогового его названия... не то ядро стырино с dc++ не то с eMule чтото свое провайдер замутил... но ни кому не говорит как юзать через сокет прокси.... просто меня интересует, почему чат работает через nat а файллисты не качаются и файлы вообще в целом не качаются... т.е. чтото Point to Point какойто? я вот о чем голову ломаю... :(

вот к нему с вопросами и вперед.

Понял спасибо.

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

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

только постарайтесь говорить как-то попонятнее.


СУВ

оригатхо!

А Зачем? Тут и так в принуипе все ясна, нат занимается тем что меняет в ип пакете ип отправителя, тем самым отправляя запрос на соединения с клиентом п2п хаба (а не самим  хабом) мы не можем нормально работать, так как в пакете не тот адрес, и соединить точка точка не возможно (в разных подсетях). А вот тут труба, как это обойти честно говоря не знаю, и хочеться сказать что это не реально, но помоему все таки как то можно, ща придут Гуру и все расскажут, ждем.... 

Добавлено через 2 минуты и 5 секунд
Обойти это можно конечно используя как раз как было сказано автором Маршрутизацию, но тут ессно много своих Но

Это сообщение отредактировал(а) angel_ - 10.4.2007, 15:44

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

Конечно Вы правы и быть уверенным на 100 % не реально, НО скорее всего пров использует прогу которая волей неволей но работает по станлартной схеме п2п сеток, поэтому и написал топик выше.

А Зачем ? ФИльтровать собственные внутресетевые ресурсы? Это же не Паразитные Нетбиос.....

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

не имеет смысл это просто блокировать ?
сейчас вообще идет ополчение против p2p сетей.

p2p сети относяться к внутресетевым ресурсам провайдера, он сам обычно ставит и регистрирует хабы, зачем ему фильтровать свой же траф? (а если он будет зафильтрован, люди просто уйдут к конкурентам ) война за абонента в России сейчас идет полным ходом, поверьте мне....

ПРЕДПОЛОЖИТЕЛЬНЫХ причин данной проблемы можно найти много, и я не перечислял их все.
Но Вы сами не ЗНАЕТЕ их, ровно также как и я, и у вас нет никакой однозначной причины утверждать, что кто-то из нас более прав, 
если Вы конечно не являетесь обладателем достоверной информации о его провайдере.
Позволяю себе предположить, что информацией этой Вы не обладаете, более того, Вы даже не знаете его провайдера ( хммм... если Вы не из ФАПСИ  или лично с ним не знакомы )

Поэтому предлагаю: если Вы хотите решить проблему, переключайте ваше внимание на Maksys, и спрашивайте его наводящие вопросы, вместо развивания разговоров ни о чем.

С.У.В.

Ни че вы тут нафлудили...
Короче говоря... хаб  для передачи данных по технологии поинт то поинт юзает при каждой загрузке различные порты... файрвол ваще не реально настроить так как порты  рандомно открываются....
Я не думаю что пров что то в этом клиенте переделал... это у всех пиринговых сетей такая маза на внешку не канает через НАТ... я думаю может здесь еще перенаправление портов заюзать надо, но динамически.... и почему порты открываются как попало тоже не ясно... чат работает по одному единственному порту, а вот передачата файллистов и данных по разным... Оутпосом проверял...

Maksys, из вашего параграфа на 6.5 строк я вижу нужной и новой информации:

• 1. программа использует порт <не знаю какой> для чата
• 2. порты для перевода файлов открываются рандомно

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

Ладно вопрос такой:
Для того чтобы пиринг работал обязательно использовать прямой доступ без редиректа? или возможно сделать чтото вроди сокет сервера который бы редиректил запросы? относительно всех пиринговых сетей..

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

Короче говоря нужно использовать Socket 5 для редиректа запросов.

Maksys, мы к сожалению разговариваем совершенно разными языками. И мне опять придется вас немного покритиковать:
Самое грустное - я тщетно пытаюсь получить от вас реакции на свои слова, но вы не "слушаете", а просто пишите что-то от себя каждый раз, без связи с моим предыдущим постом/вопросом. Так "вместе" проблемы не решаются. Поэтому, я вам здесь выписываю все возможные варианты человеческим языком. Вы поковыряйтесь, выбирите что вам подходит, и делайте что вам подходит.

Для успешного соединения, нужно, чтобы сообщения с клиента доходили до серванта, и наоборот.
1. Когда и клиент и сервер на внешних сетях, маршрутизаторы передают все сообщения без проблем ( если нет блокировки/фильтрации ). Это - не ваша ситуация.

Если вы ( сервер TCP/UDP ) находитесь на одной внутренней ( не проходящей маршрутизатор, напр. 10.1.1.0/24) сети, а клиент на другой внутренней сети ( тоже не проходящей маршрутизатор, напр. 10.1.2.0/24), то единственный образ соединения к вам клиента - через NAT на маршрутизаторе, или ДО него.

Если же вы сидите во внутренней сети, а клиент в нормальной, внешней, с "реальным IP адресом", до можно использовать:

• socks 5 прокси.
• можно также успешно использовать ssh port forwarding. но тогда нужно, чтобы каждый клиент имел ssh доступ к маршрутизатору, и на каждый "хаб" нужно будет создавать группу портов для перенаправления.

В обоих случаях нужно знать какими портами будет пользоваться сервер для получения первых сообщений, или просто маршрутизатор должен переносить ВСЕ сообщения из внешней сети на ваш "сервер" p2p, это иногда называют "виртуальный сервер", т.е. выбирается во внутренней сети один такой, и все прямые обращения перенаправляются к нему через DNAT.

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

т.е. тут 2 случая:
2. если этот центральный порт сообщает о случайно выбранном порте и к нему нужно подключиться. это механизм похожий на portmap в службах RPC, его часто p2p приложения используют.
В таком случае вам нужно настроить фаервол на маршрутизаторе пропускать клиентские запросы, которые происходят сразу после подключения на этот "центральный порт", т.н. related packets, и тогда можно их обрабатывать и перенаправлять тоже. 

3. если этот центральный порт не сообщает о порте, но сам сервер подключится на какой-то заранее установленный порт на клиенте ( т.е. клиент в данном соединении будет функционировать логически как сервер), то в таком случае нужно делать SNAT с сервера.

Удачи.


С.У.В.

  оки... кажется понял....