Теперь обязаны дать разъяснегия все остальные поисковики, такие как, гугл, яху, рамблер, меил.ру и прочие, так как они точно также проиндексироаали эти же документы и выдают в выдаче.
mesh все-таки весьма затратна для мобильных гаджетов. Но даже p2p мессенджеры не могут решить проблему высокого энергопотребления. Tox вот постоянно над этим думает, но пока не сильно продвинулся. Нужно что-то несколько иное. Необходим баланс.
Спасибо за статью. Но так и не понял чем этот проект отличается от x2go или xrdp. Вроде бы все тоже самое, за исключением того, что x2go не использует rdp
1. Какой? Там только хеши.
2. А кто даст гарантию, что для rhm администраторы будут создавать отдельные белые списки?
Опять же, если rhm не единичный, и/или будет масштабироваться, то кто будет обновлять постоянно белые списки?
>2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
Здесь противоречие с белыми списками. Если знакомы с VoIP SIP, то вспомните к чему приводят подобные вещи без проксирования.
1. повторюсь, единовременно в сети существуют десятки тысяч нод DHT/OpenDHT… Чтобы не было ни одной надо полностью закрыть весь доступ во внешнуюю сеть.
2. > Наша структура построена на централизованном типе p2p.
в таком случае здесь и речи быть не может о p2p. В вашем случае это обычная клиент-серверная структура. Где есть сервер и есть клиенты.
1. сеть tox и opendht существуют независимо, при этом ежеминутно активны десятки тысяч хостов.
2. DHT не требует передачи трафика через клиентов, а является только таблицей адресов, точнее хешей. Своего рода адресная книга
3. github.com/TokTok/c-toxcore/tree/master/toxcore здесь живая реализация. И да, пробивка NAT через STUN/TURN здесь может и работает, но явно без задействования внешних, дополнительных серверов.
4. в вашей реализации требуется отдельная сущность «remote helper manager(RHM)». Вопрос в том, зачем плодить сущностей когда все придумано до нас?
github.com/qTox/qTox/releases/tag/v1.14.1 — 18 марта 2018
вы о каком-то другом токсе?
2. А кто даст гарантию, что для rhm администраторы будут создавать отдельные белые списки?
Опять же, если rhm не единичный, и/или будет масштабироваться, то кто будет обновлять постоянно белые списки?
>2. В рамках коннекта к rhm — да, согласен. Но дальнейшее подключение между оператором и клиентом идет непосредственно по p2p
Здесь противоречие с белыми списками. Если знакомы с VoIP SIP, то вспомните к чему приводят подобные вещи без проксирования.
2. > Наша структура построена на централизованном типе p2p.
в таком случае здесь и речи быть не может о p2p. В вашем случае это обычная клиент-серверная структура. Где есть сервер и есть клиенты.
2. DHT не требует передачи трафика через клиентов, а является только таблицей адресов, точнее хешей. Своего рода адресная книга
3. github.com/TokTok/c-toxcore/tree/master/toxcore здесь живая реализация. И да, пробивка NAT через STUN/TURN здесь может и работает, но явно без задействования внешних, дополнительных серверов.
4. в вашей реализации требуется отдельная сущность «remote helper manager(RHM)». Вопрос в том, зачем плодить сущностей когда все придумано до нас?
mirror.yandex.ru/rosa
mirror.yandex.ru/astra
РОСА точно не для военных, а для широчайшего круга пользователей