Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
«Все коммуникации происходят напрямую от пользователя к пользователю… совершенно неприемлемо для мобильных устройств и в мобильных сетях, из-за высокого расхода батареи и трафика.» — то есть, расход траффика и батареи — результат передачи данных от пользователя к пользователю? А как быть, если тот же объем данных передадут с сервера пользователю?
то есть, расход траффика и батареи — результат передачи данных от пользователя к пользователю?Да.
А как быть, если тот же объем данных передадут с сервера пользователю?Могут применяться PUSH-уведомления и фильтры, да и соединение придется поддерживать одно, а значит, keep-alive'ить нужно только его одного, что приводит, в конечном итоге, к понижению расхода энергии батареи.
Что, серьезно передача 1 Мб траффика от клиента и 1 Мб от сервера дадут разный расход траффика? Откуда берется паразитный траффик при передаче от клиента по сравнению с передачей от сервера?
Нет, передача 1МБ потратит то же количество энергии, однако, например, если какой-то пользователь сети запрашивает информацию у вас, в случае с P2P ему придется подключиться к вашему IP, ваше устройство должно будет принять соединение и ответить, а в случае с серверной архитектурой, радио-модулю вашего устройства не придется просыпаться, т.к. прямого соединения на устройство не будет, только на сервер. Такие оптимизации приводят к значительному сохранению энергии.
То есть объем траффика зависит от протокола, а не от передачи «клиент-клиент» или «клиент-сервер»?
Он в любом случае зависит от протокола. С использованием серверной децентрализованности, зачастую, удается избежать излишних подключений и передачи данных для передачи технической информации.
Хочу заметить, что P2P не во всех мобильных сетях разрешен. Я не имею ввиду протокол, я имею ввиду прямое соединение мобильных абонентов одного оператора и делается это без DPI и фаерволлов.
А что там может быть кроме жирного NAT'а? (вопрос без сарказма, просто интересно)
Я наверное не верно выразился. Есть опция позволяющая мобильникам общаться в одной соте, не доходя до GGSN/PGW. Такой траффик не проходит через наты и фаерволлы, биллинговые, а также DPI устройства. Как ни странно, она обычно выключена. Иначе сеть станет не подконтрольной оператору и p2p траффик между мобильниками не будет посчитан. Вот этот траффик я имел ввиду под p2p выше, а не тот, что проходит через ggsn/pgw.
По мне так должен быть гибрид P2P и Серверного P2P. Пользователь выбирает «основной» клиент, который будет всегда запущен — он будет выполнять роль «личного сервера» (например, на десктопе). Именно он отвечает за соединение P2P к таким же «основным клиентам» других пользователей IM. И к нему уже коннектятся «миниклиенты» — те же мобильные клиенты, или просто клиенты на других компах.
В такой ситуации плюсы почти всех видов IM (и историю можно хранить, и независимость от центрального сервера, и можно фильтровать чётко сколько данных идёт на какие клиенты, чтобы не перегружать мобильные), но есть один минус — устройство, на котором запущен «основной» клиент, должно быть постоянно онлайн.
В такой ситуации плюсы почти всех видов IM (и историю можно хранить, и независимость от центрального сервера, и можно фильтровать чётко сколько данных идёт на какие клиенты, чтобы не перегружать мобильные), но есть один минус — устройство, на котором запущен «основной» клиент, должно быть постоянно онлайн.
Ну, ответ напрашивается сам — домашний роутер. Например, в Mikrotik есть гипервизор, уже есть готовые образы с Asterisk и Tor. Возможно, если выберут какой-то единый стандарт, то и производители роутеров подтянутся.
PS: кстати, ИМО, проблема постоянно активного устройства решается, если просить производителей роутеров внедрять такой «основной клиент» в прошивки своих, собственно, роутеров. Но для этого данный клиент должен будет набрать достаточно большую популярность, плюс возникнет проблема с его обновлением (решаемо, но роутероделы не любят особо с такими вещами заморачиваться). А большую популярность клиент не наберёт пока не будет оных постоянно активных устройств… Порочный круг какой-то.
Да, идея хорошая, но чтобы IM получил развитие — он должен получить популярность, а это прямое следствие простоты «развёртывания». Тот же Skype поставит любая домохозяйка, а настраивать несколько клиентов на нескольких устройствах (пусть так же просто) вряд ли кто станет.
Да что говорить, простыми торрент-клиентами пользуются уже более-менее продвинутые пользователи, обычные пытаются что-то найти и скачать просто по ссылке.
Да что говорить, простыми торрент-клиентами пользуются уже более-менее продвинутые пользователи, обычные пытаются что-то найти и скачать просто по ссылке.
Собственно о чём и речь чуть выше. Если вообразить на мгновение, что в прошивках роутеров уже зашит «основной клиент», можно сделать просто — человек скачивает с сайта «автонастройщик», который автоматом ищет оный «основной клиент» в локалке на роутере (либо инсталирует его на тот же компьютер, где запущен, если не нашёл «пустой») и запускает уже «микроклиент», который также автоматом настраивает. Присваивает какой нить ID-шник (обязательно надо, чтобы ID-шник мог конвертироваться в адрес «основного клиента» либо хранил в какой-нить DHT-таблице связь!), настраивает пароль «основного клиента» — и вуаля, у пользователя теперь есть привычные «логин» и «пароль», при помощи которого он законнектится к «основному клиенту» откуда угодно.
Т.е. это что-то типа собственного Jabber-сервера?
Чем вам не нравится так архитектура Skype? P2P кушает батарею? Так не используйте P2P на телефоне, используйте релеи. Опасаетесь за раскрытие своего IP-адреса? Тоже используйте релеи. Оффлайн-сообщения можно хранить на специальных серверах, вроде бы это уже в самом Skype сделано. Шифруете каким-нибудь ключом, сгенерированным тем же Diffie-Hellman-ом и храните хоть всю переписку там.
Мне, в целом, нравится архитектура Skype, однако не нравится сам он как мессенджер. Многие считают Tox панацеей, однако я не считаю, что он станет популярным, именно из-за высокого потребления на мобильных устройствах из-за его полной P2P-архитектуры. Именно поэтому я и хочу узнать мнение хабравчан.
Я скажу так: я таскаю Antox на мобиле, и не заметил, чтобы он прямо сажал батарейку.
Слегка просаживает, да, но несущественно — на уровне IM+, на самом деле.
Слегка просаживает, да, но несущественно — на уровне IM+, на самом деле.
С чего бы большое потребление? на мобильных он будет использовать только TCP Relay
Аналогично. Больше всего бесит как испоганили поиск контактов. В старом добром скайпе была куча фильтров и все можно было проконтролировать.
Может лучше положиться на архитектуру с супернодами?
Т.е. телефоны и слабые устройства — обычные ноды, а что-то с хорошим коннектом/аптаймом/мощностью — хранит у себя историю какого-то количества обычных нод.
Т.е. телефоны и слабые устройства — обычные ноды, а что-то с хорошим коннектом/аптаймом/мощностью — хранит у себя историю какого-то количества обычных нод.
Имхо оптимальным был бы гибрид p2p и серверного — серверный на уровне меньшим чем у джаббера и мыла.
Глобальная система авторизации и контакта как у tox, но для работы нужны сервера — для связи и авторизации и аккаунт не привязан к серверу
они будут использоваться для оффлайн сообщений, синхронизации, бэкапа, но если у тебя есть бэкап (оффлайн клиент) ты можешь восстановить все, что у тебя есть даже при падении всех серверов сразу и восстановлении чистых. По сути сервера — релеи с хранилищем.
Авторизоваться можешь на любом сервере — он по сути оповещает остальные что тебе слать сюда и если что подтягивает с других серверов новые данные, которые ему положил клиент.
Хотя сейчас меня устраивает джаббер.
Глобальная система авторизации и контакта как у tox, но для работы нужны сервера — для связи и авторизации и аккаунт не привязан к серверу
они будут использоваться для оффлайн сообщений, синхронизации, бэкапа, но если у тебя есть бэкап (оффлайн клиент) ты можешь восстановить все, что у тебя есть даже при падении всех серверов сразу и восстановлении чистых. По сути сервера — релеи с хранилищем.
Авторизоваться можешь на любом сервере — он по сути оповещает остальные что тебе слать сюда и если что подтягивает с других серверов новые данные, которые ему положил клиент.
Хотя сейчас меня устраивает джаббер.
Хорошая мысль.
Если посмотреть какие схемы работают сейчас, довольно эффективно работает схема «jabber + свой домен».
Есть jabber сервисы, которые позволяют «приземлять» домен на их серверы.
Кто хочет независимости, используют свой домен.
Кто просто хочет общаться, регятся на общем домене сервиса.
На какой сервер слать данные, прописывается в dns.
Обычные пользователи вряд ли будут все поголовно регить домены и указывать, куда слать сообщения.
Т.е. единственная проблема — dns, как высокий порог вхождения.
Но можно сделать свою замену dns — DHT «данные юзера — адрес_сервера», как у торрентов.
Я бы предложил две сущности:
— серверы-клиенты, как у xmpp (чтобы хранить оффлайн сообщения и историю)
— DHT с данными пользователя и его сервера, защищенные его паролем/ключом (возможно, там же хранить зашифрованный ростер).
Как сейчас есть ноды и релеи tor, можно запускать IM-ноды, и пускать к себе юзеров.
Получаем плюсы децентрализованности и возможность поменять IM-провайдера без потери адреса.
Если посмотреть какие схемы работают сейчас, довольно эффективно работает схема «jabber + свой домен».
Есть jabber сервисы, которые позволяют «приземлять» домен на их серверы.
Кто хочет независимости, используют свой домен.
Кто просто хочет общаться, регятся на общем домене сервиса.
На какой сервер слать данные, прописывается в dns.
Обычные пользователи вряд ли будут все поголовно регить домены и указывать, куда слать сообщения.
Т.е. единственная проблема — dns, как высокий порог вхождения.
Но можно сделать свою замену dns — DHT «данные юзера — адрес_сервера», как у торрентов.
Я бы предложил две сущности:
— серверы-клиенты, как у xmpp (чтобы хранить оффлайн сообщения и историю)
— DHT с данными пользователя и его сервера, защищенные его паролем/ключом (возможно, там же хранить зашифрованный ростер).
Как сейчас есть ноды и релеи tor, можно запускать IM-ноды, и пускать к себе юзеров.
Получаем плюсы децентрализованности и возможность поменять IM-провайдера без потери адреса.
Да, гибрид был бы наиболее жизнеспособен.
P2P нужен по сути только для первичного хэндшейка между клиентами (обмен ключами). После этого можно проводить обмен зашифрованными сообщениями через сервер. Плюшки хранения истории в клауде и пуш нотификаций становятся относительно безопасными.
Имея доступ к серверу по-прежнему можно отследить факт обмена сообщениями и интенсивность переписки, но контент недоступен.
P2P нужен по сути только для первичного хэндшейка между клиентами (обмен ключами). После этого можно проводить обмен зашифрованными сообщениями через сервер. Плюшки хранения истории в клауде и пуш нотификаций становятся относительно безопасными.
Имея доступ к серверу по-прежнему можно отследить факт обмена сообщениями и интенсивность переписки, но контент недоступен.
А для P2P разве не нужен «белый» IP с «открытыми» портами хотя бы с 1 стороны? У нас тонна проваидеров у которых абоненты за NATом.
Жду статью «Какую архитектуру сотовой связи вы считаете приемлемой?», а то нет вменяемой безопасной альтернативы сотовой связи.
А вообще у меня есть мечта сделать сотовую связь типа меш сетей где оплата будет не деньгами а собственным процом и батарейкой для поддержания работы сети. Ну и соответственно кто хочет тот зарабатывает, а кто не хочет тот платит.
А вообще у меня есть мечта сделать сотовую связь типа меш сетей где оплата будет не деньгами а собственным процом и батарейкой для поддержания работы сети. Ну и соответственно кто хочет тот зарабатывает, а кто не хочет тот платит.
Для начала нужно определиться, что предпочтительнее — анонимность или удобство и скорость работы. «Делаем быстро, качественно, дешево — выбирайте любые два».
Опять же, пользователей множество и все они разные. Идеальной, с моей точки зрения, могла бы быть система с использованием возможностей «умного дома» (или хотя бы иметь дома постоянно включенный сервер, но использовать его только для обмена сообщениями — нерационально), когда стационарный сервер с малым энергопотреблением и широким функционалом обслуживает еще и систему обмена данными. Сообщения могут храниться на сервере, на нем же список адресов серверов и клиентов (в зависимости от реализации).
Непонятно, зачем для повседневного общения требуется анонимность айпишника. Хочется использовать шифрование — это можно сделать на стороне клиентов. Если же нужна именно полная анонимность — для этого есть множество вариантов.
В общем, с моей точки зрения, мессенджер должен обеспечивать в первую очередь удобное пользование, надежность и, как вариант, возможность шифровать конфиденциальные разговоры. Обеспечение анонимности — задача несколько другого плана.
Опять же, пользователей множество и все они разные. Идеальной, с моей точки зрения, могла бы быть система с использованием возможностей «умного дома» (или хотя бы иметь дома постоянно включенный сервер, но использовать его только для обмена сообщениями — нерационально), когда стационарный сервер с малым энергопотреблением и широким функционалом обслуживает еще и систему обмена данными. Сообщения могут храниться на сервере, на нем же список адресов серверов и клиентов (в зависимости от реализации).
Непонятно, зачем для повседневного общения требуется анонимность айпишника. Хочется использовать шифрование — это можно сделать на стороне клиентов. Если же нужна именно полная анонимность — для этого есть множество вариантов.
В общем, с моей точки зрения, мессенджер должен обеспечивать в первую очередь удобное пользование, надежность и, как вариант, возможность шифровать конфиденциальные разговоры. Обеспечение анонимности — задача несколько другого плана.
В общем, с моей точки зрения, мессенджер должен обеспечивать в первую очередь удобное пользование, надежность и, как вариант, возможность шифровать конфиденциальные разговоры. Обеспечение анонимности — задача несколько другого плана.
Верно. То есть идеальным было бы совмещение всех трёх вариантов: выделенный сервер, децентрализованные сервера, P2P. А пользователь сам бы настраивал свой клиент в меру своей компетенции и паранойи. По умолчанию, например, устанавливается как Skype — логин/пароль, далее, готово. Не нравится — открыл расширенные настройки и сконфигуриловал как нравится.
Если откровенно не нравится централизованный сервер тем, что развитие зависит от держателя оного центрального сервера. А если вдруг его владелец выкатит какое-то изменение, которое не понравится остальным? А если вообще вдруг пропадёт, и сервер умрёт?
А как тогда сохранить простоту настройки? Интеллектуальный алгоритм поиска децентрализованных серверов?
Простой вариант — списки популярных серверов, зашитые в инсталлятор (как в клиентах dc++).
Вариант посложнее — список берется из DHT.
Вариант посложнее — список берется из DHT.
Собственно проблема только с начальным бутстрапингом. Для этого на сайте/сайтах скачки будет прямо в инсталляторе прописаны некие актуальные на момент скачки ноды. При обновлении — клиент же будет обновляться — обновляется и этот список начального бутстрапинга. А потом уже проще будет — бутстрапинг прошёл, и клиент сам хранит актуальные ноды.
Как вариант — список актуальных серверов на Вики.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какую архитектуру IM вы считаете приемлемой?