Комментарии 22
Интересно, что мешает использовать DHT, и ту же систему, что применяется в tox?
DHT не отменяет необходимость в STUN, TURN и hole punching
Если я не ошибаюсь, сеть DHT подразумевает наличие постоянно запущенного приложения. В наших реалиях — средство управление запускается по мере необходимости оказать или получить помощь.
Плюс торрентоподобные сети подразумевают возможность ретрансляции трафика через других участников сетей. Уверен клиентам это понравилось бы.
Ну и да, как отметили чуть выше, STUN или аналогичный способ определения своего внешнего IP все же необходим.
Плюс торрентоподобные сети подразумевают возможность ретрансляции трафика через других участников сетей. Уверен клиентам это понравилось бы.
Ну и да, как отметили чуть выше, STUN или аналогичный способ определения своего внешнего IP все же необходим.
1. сеть tox и opendht существуют независимо, при этом ежеминутно активны десятки тысяч хостов.
2. DHT не требует передачи трафика через клиентов, а является только таблицей адресов, точнее хешей. Своего рода адресная книга
3. github.com/TokTok/c-toxcore/tree/master/toxcore здесь живая реализация. И да, пробивка NAT через STUN/TURN здесь может и работает, но явно без задействования внешних, дополнительных серверов.
4. в вашей реализации требуется отдельная сущность «remote helper manager(RHM)». Вопрос в том, зачем плодить сущностей когда все придумано до нас?
2. DHT не требует передачи трафика через клиентов, а является только таблицей адресов, точнее хешей. Своего рода адресная книга
3. github.com/TokTok/c-toxcore/tree/master/toxcore здесь живая реализация. И да, пробивка NAT через STUN/TURN здесь может и работает, но явно без задействования внешних, дополнительных серверов.
4. в вашей реализации требуется отдельная сущность «remote helper manager(RHM)». Вопрос в том, зачем плодить сущностей когда все придумано до нас?
В случае если в любой момент есть хотя бы одно запущенное приложение DHT сети — согласен, проблем нет. Что если запуск происходит в момент недоступности последних известных узлов?
«Без задействования дополнительных серверов» — да, когда есть внешний хост DHT сети — вопрос о своем внешнем IP решается сам собой, бесспорно. Но если такой возможности нет, что делать, с чего начать? На это и была нацелена статья.
Наша структура построена на централизованном типе p2p. Ей и проще управлять и собирать статистику соединений, а так же интегрировать в панель ожидающих подключения клиентов.
«Без задействования дополнительных серверов» — да, когда есть внешний хост DHT сети — вопрос о своем внешнем IP решается сам собой, бесспорно. Но если такой возможности нет, что делать, с чего начать? На это и была нацелена статья.
Наша структура построена на централизованном типе p2p. Ей и проще управлять и собирать статистику соединений, а так же интегрировать в панель ожидающих подключения клиентов.
1. повторюсь, единовременно в сети существуют десятки тысяч нод DHT/OpenDHT… Чтобы не было ни одной надо полностью закрыть весь доступ во внешнуюю сеть.
2. > Наша структура построена на централизованном типе p2p.
в таком случае здесь и речи быть не может о p2p. В вашем случае это обычная клиент-серверная структура. Где есть сервер и есть клиенты.
2. > Наша структура построена на централизованном типе p2p.
в таком случае здесь и речи быть не может о p2p. В вашем случае это обычная клиент-серверная структура. Где есть сервер и есть клиенты.
1. средство управление запускается по мере необходимости оказать или получить помощь — оно не висит в памяти без необходимости. Таким образом, скажем в часы минимальной нагрузки(скажем ночью или ближе к утру по Москве) — да, есть такая вероятность, что ни одного приложения не будет запущено вовсе. А вероятность доступности последнего известного узла — еще меньше.
2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
Кажется, понял. Предлагается завязаться не на свою DHT, а на некую общую. Да, как вариант. Но есть 2 момента:
1. Придется уделить огромное внимание безопасности
2. Как быть с клиентами у которых для бух.компов выход в сеть только по белым спискам? Их в топку?
1. Придется уделить огромное внимание безопасности
2. Как быть с клиентами у которых для бух.компов выход в сеть только по белым спискам? Их в топку?
1. Какой? Там только хеши.
2. А кто даст гарантию, что для rhm администраторы будут создавать отдельные белые списки?
Опять же, если rhm не единичный, и/или будет масштабироваться, то кто будет обновлять постоянно белые списки?
>2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
Здесь противоречие с белыми списками. Если знакомы с VoIP SIP, то вспомните к чему приводят подобные вещи без проксирования.
2. А кто даст гарантию, что для rhm администраторы будут создавать отдельные белые списки?
Опять же, если rhm не единичный, и/или будет масштабироваться, то кто будет обновлять постоянно белые списки?
>2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
Здесь противоречие с белыми списками. Если знакомы с VoIP SIP, то вспомните к чему приводят подобные вещи без проксирования.
1. Любая открытая сеть — потенциально опасна
2. Гарантий нет, но есть возможность, а это уже +, чего не скажешь о dht
3. Абсолютно нет противоречия. Перелистайте статью — в случае, когда прямое соединение установить не удается, мы идем через релей, т.е сервер ретрансляции трафика.
Но Ваша позиция мне понятна, спасибо!
2. Гарантий нет, но есть возможность, а это уже +, чего не скажешь о dht
3. Абсолютно нет противоречия. Перелистайте статью — в случае, когда прямое соединение установить не удается, мы идем через релей, т.е сервер ретрансляции трафика.
Но Ваша позиция мне понятна, спасибо!
А бенчмарки будут? Фпс хотя бы и лэтэнси по обычному интернет каналу и по локалке?
Бенчмарки чего? Самой системы управления? Или установки соединения? Если вопрос касается только установки соединения — не более пары секунд, в зависимости от канала.
Если говорить о качестве самой работы, то очень многое зависит от клиентского аппаратного обеспечения. Но в среднем достаточно комфортно.
Если говорить о качестве самой работы, то очень многое зависит от клиентского аппаратного обеспечения. Но в среднем достаточно комфортно.
Кстати, про reliable UDP — эдак вы еще и до управления congestion window дойдёте и получится почти полноценный TCP :-)
Работаю с online.sbis && reg — было интересно почитать, что там под капотом, спасибо.
Среди наболевшего:
— API развивать будете в сторону работы с ЭЦП/сертификатами?
— планируете как-нибудь ограничить аппетиты sbis plugin в плане оперативки? В диспетчере постоянно наблюдаю значение в 700-800 Мб, пару раз за гигабайт переваливало. Причем периодически не может переварить и давится, помогает только «тремя пальцами», что грустно.
Среди наболевшего:
— API развивать будете в сторону работы с ЭЦП/сертификатами?
— планируете как-нибудь ограничить аппетиты sbis plugin в плане оперативки? В диспетчере постоянно наблюдаю значение в 700-800 Мб, пару раз за гигабайт переваливало. Причем периодически не может переварить и давится, помогает только «тремя пальцами», что грустно.
А нам в радость рассказать об этом. В ближайшее время удаленный помощник портируется на linux и os x системы. Дальнейшее развитие проекта еще на стадии обсуждения.
Про СБИС Плагин — это, конечно, не по теме статьи, однако могу лишь намекнуть, что разрабатывается его новая реализация. Надеюсь, вы оцените! ;)
Про СБИС Плагин — это, конечно, не по теме статьи, однако могу лишь намекнуть, что разрабатывается его новая реализация. Надеюсь, вы оцените! ;)
А есть статистика по процентам tcp/udp/relay?
Как понял тут описан транспортный уровень, а интересна именно реализация захвата видео и управления, что для этого используется?
Недавно связался с Тензором, дабы получить электронную подпись и после всего установленного шлака для этих целей, я обнаружил, что ваш софт установил в доверенные корневые центры сертификации самоподписной сертификат на адрес 127.0.0.1. Право даже не знаю, в голову одни маты лезут. Это тоже от боли при p2p разработки?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вся боль p2p разработки