Open Source - контест лог под Линукс

**ER1CS** · 13.04.2009, 19:47

Сообщение от EW1CK

некоторые провайдеры взяли моду запрещать открытие соединения извне, вслучае если клиент работает с динамическим IP адресом.

Если адреса фэйковые - то это и нормально. Это не они запрещают, это у них другой возможности нет.
Выход тут один - клиент-сервер.

Добавлено через 7 минут

Сообщение от RX9TX

GPRS конечно хватит

Тут вопрос во времени и протоколе. Тот же p2p через гпрс, особенно с внешним инициатором линка - для меня например загадка как сможет работать.

**VE3EUT** · 13.04.2009, 20:09

Еще концептуальный вопрос ко всем, но даже наверное к RX9TX, нужны ли нам разные перспективы для Run и S&P, а так же разные перспективы для каждого мода и диапазанона.
Перспектива в терминах RCP это набор окошек с сохраненным расположением, размером и т.д. Их количество может различаться, их можно будет самому двигать, менять размеры и т.д.
Вопрос, нужны ли нам разные сохраненные значения на Run и S&P ? Думаю да.
Для каждого мода - думаю да.
Для каждого диапазона - думаю что нет.

Пожалуйста дайте знать, если считаете по-другому.

Добавлено через 4 минуты

Сообщение от Peter

Тот же p2p через гпрс, особенно с внешним инициатором линка - для меня например загадка как сможет работать.

Должна быть возможность исхитриться, иначе бы torrents.ru не работал

**RX1AL** · 13.04.2009, 20:18

Сообщение от EW1CK

С Flamingo никогда не работал, надо посмотреть что за оно.

Артур, ссылка на библиотеку нужна? Скину здесь... Там все подробно и примерами:

http://weblogs.java.net/blog/kirillcool/ - Flamingo 4.0 official release
http://hexapixel.com/projects/ribbon - SWT Ribbon

Проект то создан, да вот репозиторий пока не создали... Жду подтверждения от админа... Праздники видать...

**ER1CS** · 13.04.2009, 20:29

Сообщение от EW1CK

иначе бы torrents.ru не работал

Если про торренты - то это я так понял с низким ID - так там запросы от закрытого клиента идут к тем у кого открыт порт. а если все с закрытым - то обмена нет. т.е. тот же клиент-сервер.

**R8TX** · 13.04.2009, 20:36

Сообщение от EW1CK

Еще концептуальный вопрос ко всем, но даже наверное к RX9TX, нужны ли нам разные перспективы для Run и S&P, а так же разные перспективы для каждого мода и диапазанона.
Перспектива в терминах RCP это набор окошек с сохраненным расположением, размером и т.д. Их количество может различаться, их можно будет самому двигать, менять размеры и т.д.
Вопрос, нужны ли нам разные сохраненные значения на Run и S&P ? Думаю да.
Для каждого мода - думаю да.
Для каждого диапазона - думаю что нет.
Пожалуйста дайте знать, если считаете по-другому.

Если я правильно понял, должен ли изменяться каким-то образом вид окон при переключении между раном и поиском? Нет конечно. Должно изменяться ПОВЕДЕНИЕ окна ввода QSO в зависимости от run/sp, как в ММ, например при ране при пустых полях позывного и номера Enter выдает общий вызов, а при заполненном поле позывного - позывной и номер, при заполненных полях позывного и номера - TU QRZ? При поиске при пустом поле номера Enter выдает свой позывной, при заполненном - свой номер. Есть еще тонкости с положением курсора в одном из полей. Это называется Enter Sends Message (ESM), и этот режим должен быть отключаемым, чтобы не обидеть тех кто работает только через F-клавиши, а не через Enter. Вообще Вам надо отработать с десяток тестов в ММ, быстро понимаешь как все должно работать

**RX1AL** · 13.04.2009, 20:52

Сообщение от Peter

Если про торренты - то это я так понял с низким ID - так там запросы от закрытого клиента идут к тем у кого открыт порт. а если все с закрытым - то обмена нет. т.е. тот же клиент-сервер.

Не совсем так... Наша проблема возникает только тогда, когда есть транспарентный синхронный файерволл. Но для него тоже есть средство, уже давно - UDP and TCP Hole Punching для режима Р2Р. Или вообще использование стека IPv6, там таких заморочек нет. Подробнее здесь, как экскурс:

http://m.linuxjournal.com/article/9004
http://kennethhunt.com/archives/001284.html

Далее то, как это делается практически:
http://www.cyberciti.biz/tips/howto-...striction.html
http://lists.planet-lab.org/pipermai...er/001647.html

PS Есть и другие открытые библиотеки...

RX9TX:
Асхат, спасибо... Теперь вроде определились... с моментами и окошками. Я сижу делаю наброски уже...

EW1CK, Peter:
В универе мы используем TCP NAT Traversal/Hole-Punching Library - http://nutss.gforge.cis.cornell.edu//stunt.php - STUNT. Проблем с ней до сих пор не было никаких. Думаю и в нашем случае будет оптимально.

**ER1CS** · 13.04.2009, 21:09

Сообщение от RX1AL

http://kennethhunt.com/archives/001284.html

Там полюбому нужен сервер.
C IP V6 плотно не сталкивался, но каким он тут боком - совершенно непонятно, так как расчитываем не на локалку, в которой хоть V6, хоть IPX можно поднять. А провайдер может спокойно рубить всё что ему не подходит, что правильно.

**RX1AL** · 13.04.2009, 21:14

Сообщение от Peter

Там полюбому нужен сервер.
А провайдер может спокойно рубить всё что ему не подходит, что правильно.

Сервер, в случае Р2Р нужен не всегда... так как клиент сам может выступать тем же сервером/роутером. Что будет удобнее в нашем случае, такую схему и реализуем. Можно сделать так, чтобы и на лету в зависимости от коллизий перестраивалась. Такое тоже можно на Р2Р реализовать. В плане работы черз провайдера, а не когда мы имееем локальную сеть (где хоть на коаксиале одноранговую сеть можно иметь), можно использовать MiniVPN, SocialVPN библиотеки. Ни один провайдер не запретит организовывать свои туннели...

**ER1CS** · 13.04.2009, 21:15

Сообщение от RX1AL

http://nutss.gforge.cis.cornell.edu//stunt.php

Спасибо! Интересно. Надо посмотреть как это рубить, если раньше пропускал

Добавлено через 3 минуты

Сообщение от RX1AL

так как клиент сам может выступать тем же сервером/роутером

В общем то я же описывал выше - если он не фэйковый как минимум.

Сообщение от RX1AL

Ни один провайдер не запретит организовывать свои туннели...

Смотрим выше.

В общем вы определитесь - p2p или клиент-сервер. Это две большие разницы, которые влияют на то, что в итоге вы напишите.

**RX1AL** · 13.04.2009, 21:23

Peter:
На провайдере всегда открыт порт скайпа, а его можно и использовать тоже, через PAT сделать редирект на внутренний порт и все работает.
Не думаю, что стоит сейчас так серьезно заморачиваться на эту тему. Гораздо важнее проработать выбор архитектуры самой сети... чем то, на какой библиотеке это будет сделано. При этом схема сети и архитектура должна быть такой, чтобы учесть все наши сценарии. Даже в самом пиковом случае...

Естесственно определимся, прежде, чем стартовать... Артур скажет свое слово, другие тоже. В итоге и будет выбор. Пока взвешиваем все за и против той или иной реализации.

PS Такое практически не рубится...

Если только вообще все порты не запретить. Так и на это есть ответ, уже тестировали: на стандартном 80 порту все живет на ура... Думается в нашем случае таких вещей не возникнет...

**ER1CS** · 13.04.2009, 21:31

Сообщение от RX1AL

Такое практически не рубится... Если только вообще все порты не запретить.

Рубится всё, зависит от уровня обработки пакета. Но тут не место имхо для обсуждения этого.

Сообщение от RX1AL

выбор архитектуры самой сети

Так архитектура сети и зависит от p2p или клиент-сервер. Про то, что иметь одну актуальную точку с данными намного приятнее чем 10-20 с переменным статусом - я уж не говорю.

**RX1AL** · 13.04.2009, 21:38

Peter:
Пётр, нам никто не мешает иметь и в Р2Р отдельно взятый центральный сервер, зато будем иметь в плюсах и все остальные возможности пира тоже...

PS А обрубить конечно можно все...

**ER1CS** · 13.04.2009, 21:43

Сообщение от RX1AL

нам никто не мешает иметь и в Р2Р отдельно взятый центральный сервер

Да, логично. Получается повышение надёжности но увеличение траффика при дублировании. Согласен. Если серверная часть ещё будет уметь работать как просто сервер и хранить данные.

**RX1AL** · 13.04.2009, 21:53

Peter:
Серверная часть просто обязана это делать. А увеличение трафика? Ничего страшного в этом нет. За все надо платить. Но надежность приобретаем, а это немало.

ПС Артур думается, согласится с такими доводами тоже.