Вопрос передачи через multucast udp частично решен в uftp, кроме ручного указания скости.
А так все верно, нюансов масса. Но и простора для творчества.
Например, первичная передача через multicast, затем передача потерянных данных по принципу ringsync, или, например, частичная синхронизация в рамках одного свитча, затем запрос остальных частей в источнике.
Скажите пожалуйста, а нельзя ли для этих целей (передача данных) использовать multicast? Кажется, что для минимизации трафика самое оно.
Извиняюсь, если в статьях был ответ на это предложение.
Классная разработка, из открытых, наверное, уникальная на текущий момент:
VNC не умеет видео-кодеки;
chrome remote desktop сильно повязан на хроме и инфраструктуре гугла;
Хотя если не ошибаюсь, многие вещи как раз взяты из хрома (и это прекрасно!)
Пара комментариев, если позволите:
1) Не стоит делать свое шифрование (The #1 rule of cryptography is «Don't invent your own.» );
2) Стоит больше внимания уделить работы через Интернет (Stun/Turn);
Я не испытываю иллюзий, что в какой-то перспективе официально опубликуют код.
В докладе вскользь упомянули, что в качестве congestion control они используют гугловский BBR, вот уж что интересно было бы глянуть. Кроме ядра линкуса и QUIC-a никто так и не сделал в открытых проектах. А выглядит очень любопытно.
Гугл со своим libjingle, а так же ZeroTier говорят, что 6-8% не пробиваются, остальные могут работать напрямую.
Хотя у меня другая статистика ~75% только, но все же не 10.
А можете пояснить по поводу эфемерного ключа в X3DH.
Я не могу понять, какой смысл его подписывать. В рамках X3DH он все равно перемешивается с Identity и такая подпись кажется избыточной.
У меня вопрос юридический, не совсем по теме, но все же в контексте.
В России, я, как физ.лицо, могу ли легально (с точки зрения законов) использовать криптографию, при передаче информации другому физ.лицу?
В приступе ностальгии я вспомнил, что давно-давно и школе/институте была сборка quake I и quake II на одной дискете и на двух соответственно. Там была вроде одна карта и боты.
У себя нашел только Q2, а про Q1 в инете все ссылки дохлые.
Может у кого-то есть в архиве? Хочу у себя сохранить, истории для :)
А вообще с довернем интересная штука.
Я так радовался, что все мессенджеры вводили e2e шифрование. Все было замечательно пока не дело не дошло до действительно важной информации. Мне надо было жене переслать информацию о карточке включая номер, дату, cvv. Я пришел к интересному для себя выводу: да никогда я не отправлю эту информацию по viber, whatsapp или даже signal. Не доверяю и все тут. Алгоритмам доверяю, а приложениям — нет.
Так что один маркетинг, смайлиики слать можно и без шифрования.
Как уже выше обозначили, если 2 компьютера находятся за NAT-ом, то для прямого соединения необходима третья сторона. Не обязательно, чтобы это был ваш выделенный сервер. Достаточно любого IM, например xmpp. Задача: доставить каждой из машин данные для подключения, т.е. IP (белый который NAT, и порт).
Но надо иметь ввиду, что не каждый NAT позволяет провести UDP hole punch. Не стоит его рассматривать как гарантированный канал.
Можно попробовать соединиться с помощью примера icedemo из комплекта PJSIP. После этого понять стоит ли в эту строну копать или нет.
Интересный вариант: организовать канал через toxcore, но в случае с Tox децентрализация дает о себе знать — соединение происходит не мгновенно.
Есть аналог hamachi — ZeroTier, можно глянуть в его сторону, но он, вроде, в альфе еще.
Как обычно проблема в деньгах.
За таким месседжером должна стоять крупная организация, готовая это дело финансировать, но на текущий момент очевидно, с точки зрения бизнеса — это бесперспективно, раз таких предложений нет.
Есть альтернатива — это сообщество open source. Но у OS проблема в отсутствии денег, им занимаются в свободное от работы время.
Мне симпатичен Tox, я внимательно слежу за его развитием. Но им надо научится зарабатывать на нем деньги.
Главный вопрос как?
Они уже собрали краудфанеринг на $5000, но это месяц работы разработчика. И единожды.
Пользуясь случаем спрошу, а есть ли стиль для mapbox схожий с яндекс.картами? На мой взгляд они самые читаемые.
Вопрос передачи через multucast udp частично решен в uftp, кроме ручного указания скости.
А так все верно, нюансов масса. Но и простора для творчества.
Например, первичная передача через multicast, затем передача потерянных данных по принципу ringsync, или, например, частичная синхронизация в рамках одного свитча, затем запрос остальных частей в источнике.
Спасибо за развернутый ответ
Скажите пожалуйста, а нельзя ли для этих целей (передача данных) использовать multicast? Кажется, что для минимизации трафика самое оно.
Извиняюсь, если в статьях был ответ на это предложение.
VNC не умеет видео-кодеки;
chrome remote desktop сильно повязан на хроме и инфраструктуре гугла;
Хотя если не ошибаюсь, многие вещи как раз взяты из хрома (и это прекрасно!)
Пара комментариев, если позволите:
1) Не стоит делать свое шифрование (The #1 rule of cryptography is «Don't invent your own.» );
2) Стоит больше внимания уделить работы через Интернет (Stun/Turn);
В докладе вскользь упомянули, что в качестве congestion control они используют гугловский BBR, вот уж что интересно было бы глянуть. Кроме ядра линкуса и QUIC-a никто так и не сделал в открытых проектах. А выглядит очень любопытно.
А есть статистика по процентам tcp/udp/relay?
Хотя у меня другая статистика ~75% только, но все же не 10.
Я не могу понять, какой смысл его подписывать. В рамках X3DH он все равно перемешивается с Identity и такая подпись кажется избыточной.
В России, я, как физ.лицо, могу ли легально (с точки зрения законов) использовать криптографию, при передаче информации другому физ.лицу?
У себя нашел только Q2, а про Q1 в инете все ссылки дохлые.
Может у кого-то есть в архиве? Хочу у себя сохранить, истории для :)
Хорошо, я основную мысль понял.
Возможно у меня и правда паранойя. Любопытно, а вы бы переслали подобную информацию, например по whatsapp?
Я так радовался, что все мессенджеры вводили e2e шифрование. Все было замечательно пока не дело не дошло до действительно важной информации. Мне надо было жене переслать информацию о карточке включая номер, дату, cvv. Я пришел к интересному для себя выводу: да никогда я не отправлю эту информацию по viber, whatsapp или даже signal. Не доверяю и все тут. Алгоритмам доверяю, а приложениям — нет.
Так что один маркетинг, смайлиики слать можно и без шифрования.
А кроме гугловского Webm есть еще конкуренты?
Но надо иметь ввиду, что не каждый NAT позволяет провести UDP hole punch. Не стоит его рассматривать как гарантированный канал.
Можно попробовать соединиться с помощью примера icedemo из комплекта PJSIP. После этого понять стоит ли в эту строну копать или нет.
Интересный вариант: организовать канал через toxcore, но в случае с Tox децентрализация дает о себе знать — соединение происходит не мгновенно.
Есть аналог hamachi — ZeroTier, можно глянуть в его сторону, но он, вроде, в альфе еще.
За таким месседжером должна стоять крупная организация, готовая это дело финансировать, но на текущий момент очевидно, с точки зрения бизнеса — это бесперспективно, раз таких предложений нет.
Есть альтернатива — это сообщество open source. Но у OS проблема в отсутствии денег, им занимаются в свободное от работы время.
Мне симпатичен Tox, я внимательно слежу за его развитием. Но им надо научится зарабатывать на нем деньги.
Главный вопрос как?
Они уже собрали краудфанеринг на $5000, но это месяц работы разработчика. И единожды.