Сугубо моё личное мнение:
Если планируется для бизнеса, то будет огромный плюс, открытые исходники клиентской части, при том, серверную можно будет оставить закрытую. Это сразу вынесет вас вперед перед конкурентами.
Вопрос передачи через 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, можно глянуть в его сторону, но он, вроде, в альфе еще.
Если планируется для бизнеса, то будет огромный плюс, открытые исходники клиентской части, при том, серверную можно будет оставить закрытую. Это сразу вынесет вас вперед перед конкурентами.
Пользуясь случаем спрошу, а есть ли стиль для 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, можно глянуть в его сторону, но он, вроде, в альфе еще.