nirvimel

Как устроена архитектура P2P приложений?

Идея, на которой построено большинство P2P сетей называется DHT (Distributed hash table) (рус), эталонной реализацией этой идеи является Kademlia (рус).

Каждому клиенту будет необходимо узнать адреса других клиентов. Как они смогут получить друг у друга актуальный список?

Не существует никакого общего списка, в котором были бы перечислены все пиры сети. Невозможно мгновенно (за один запрос) получить информацию об интересующем пире (существует ли он вообще? активен ли? каков его реальный IP для подключения), но эту информацию можно достать из сети за несколько запросов: Кто знает Х? Кто знает кого-то, кто мог бы знать X? Кто знает кого-то, кто мог бы знать кого-то, кто мог бы знать X? и.т.д.

Если приложение действительно децентрализованное, у него ведь не должно быть какого-то пира, который всегда будет знать список более актуальный, чем другие, верно?

Именно так.

Или всё таки, должны быть в сети какие-то доминирующие пиры?

Не доминирующие, а правильнее сказать "первоначальные", чьи адреса жестко прописаны в каждом экземпляре клиентского софта. Они обеспечивают так называемый bootstrap новых пиров при их первом заходе в сеть. В дальнейшем, находясь в сети, пир держит в памяти необходимый набор маршрутов (очень небольшую долю от всей сети) для поддержания контакта с сетью и больше не нуждается в наличии и функционировании "первоначальных".

Тогда если они разом каким-то образом падают, вся система должна сама выбрать других доминантов?

Их падение никак не повлияет на функционирование сети и уже подключенных к ней пиров. Но новые пиры "по холодному" не смогут подключиться никак, если ни один из "первоначальных" пиров не будет доступен.

Нужно как минимум прочитать заголовок PNG (а точнее IHDR chunk, который идет первым), в нем указаны ширина и высота в пикселах. Без доступа к содержимому файла это определить невозможно.

Свои права на домены и публичные аккаунты (которые могут быть использованы для продвижения товара/услуги или для массового распространения позитивной/негативной информации о товаре/услуге/компании) могут предъявлять только владельцы прав на торговую марку (trade mark). Кто первым зарегистрировал торговую марку, тот и может заявлять права на все домены и публичные аккаунты, созвучные ей. Сам факт владения доменом, не дает права претендовать на все публичные аккаунты с созвучными именами.

P.S.: Думаю, тег Юриспруденция будет уместен для подобного рода юридических вопросов.

Маскировка IP == Проксирование трафика.
Вам придется пропускать весь трафик скачиваемого файла через какой-то свой узел (не обязательно веб-хостинг), IP которого и будет виден конечному пользователю. Теоретически, это - единственный возможный способ. Но вот реализация этого может быть самая различная. Одну такую возможность описал Алексей С. . Другая альтернатива - настройка reverse-proxy на VPS. Классикой тут считается Nginx. Преимущества такого варианта:

• Очень низкий расход ресурсов - кроме трафика по сути ничего не потребляется, ни CPU, ни RAM.
  
• Минимальная задержка ответа сервера. Ответ скрываемого сервера + пинг до прокси, больше ничего.
  
• Сколько угодно параллельных потоков без перерасхода потоков ОС, памяти и прочих накладных расходов.
  
• Возможность развертывания на очень дешевом VPS. Подбор можно вести только по bandwidth и traffic limit.
  

Простая (ограниченная) защита от парсинга: Блоки, в которых отображаются защищаемые данные, выводить на странице в виде картинок, генерируемых на сервере. Например, каждое отдельное чисто/строку в маленькой PNG. Еще лучше слепить все в одну большую картинку (вперемешку), а на странице, в соответствующих позициях, вместо текста вставить img теги, в каждом указать смещение и размер соответствующего блока на большой картинке.

Если все, чем вы занимаетесь в web, сводится к CRUD, тогда роль бекенда в вашей работе может сводиться к:

1. Аутентификация юзера.
   
2. Проверка прав доступа.
   
3. Валидация данных от юзера.
   

Когда вы столкнетесь с более тяжелыми приложениями с некоторой бизнес логикой (даже!), тогда вы поймете, что фронэнд занимает такую долю в проекте, какую долю занимает кнопка "Пуск" во всей ОС Windows.

Возможно зашифрован ваш браузер. В моем браузере эта страница ни разу не зашифрована.

Собрание секты верующих в приватный режим браузера в этом треде. Волшебная кнопка "инкогнито" (слово то какое красивое) надевает на юзера шапку невидимку, защищает его от слежки и вообще от всего.

Так что же такое приватный режим на самом деле?

Privacy mode or "private browsing" or "incognito mode"[1] is a privacy feature in some web browsers to disable browsing history and the web cache. This allows a person to browse the Web without storing local data that could be retrieved at a later date. Privacy mode will also disable the storage of data in cookies and Flash cookies. This privacy protection is only on the local computing device as it is still possible to identify frequented websites by associating the IP address at the web server.

https://en.wikipedia.org/wiki/Privacy_mode

Суть в том, что приватный режим всего лишь гарантирует стирание куки, кеша, истории и никак не мешает идентификации самого браузера и его уникального окружения, то есть совсем никак.

Чтобы окончательно развеять сомнения в своей уникальности, включаем приватный режим, проходим этот тест и наслаждаемся результатом (Show full results for fingerprinting -> Ctrl+F эту строку):

Your browser fingerprint appears to be unique among the xxx,xxx,xxx tested so far.

Как и везде:

1. /api/auth принимает {"login":"user", "password":"qwerty"} возвращает {"session_id":"UUID:4545633896344"}
   
2. Все остальные API принимают параметр session_id, без него отвечают 401, с неверным session_id отвечают 403.
   
3. Сессии не вечные, через N минут после последнего api-вызова стираются.
   
4. Если клиент внезапно получает 403, то не кричит об этом юзеру сразу, а пытается перелогиниться хотя бы один раз.
   

Как сделать простое текстовое сравнение понятно

А вот и совсем не понятно, потому что текстового сравнения HTML там нет. Страница сначала полностью парсится, потом идет по-элементное сравнение всех текстовых элементов. Если расстояние меньше константы, элементам присваивается единый uid (то есть они признаются парой вариантов одного элемента). Для других тегов, содержащих в себе текст оценивается относительный объем совпадающих дочерних текстовых элементов, на основе этого производится их идентификация, и так идет проход снизу вверх, пока не соберется общее дерево. А сама раскраска diff-отличий для сопоставленных текстовых элементов - тривиальная задача.

Я хорошо знаю эту тему, потому что однажды писал подобное. Тема сложная, готовых решений нет, универсальных подходов тоже нет (мое описание упрощено на порядок), куча разных граничных случаев, мозг закипает от одной только декомпозиции задачи. В общем я так и не закончил решение в тот раз, спонсор потерял веру в проект, а без финансирования на голом энтузиазме такого масштаба проекты не заканчиваются в одиночку. До сих пор мечтаю продолжить, пусть на других технологиях, но с большим опытом в этой теме.

Если канал слабый да еще с оплатой по трафику, то о прямой трансляции видео можно забыть. Лучше на сервере открыть к каталогу с видео доступ по FTP или Samba. А на терминалах делать rsync удаленного каталога в локальный откуда идет трансляция. Это будет максимально экономично по трафику (насколько это вообще возможно) и любые проблемы с сетью могут в худшем случае только замедлить синхронизацию, трансляция же будет продолжаться бесперебойно.
Перекодирование видео, загружаемого пользователями, конечно, необходимо. Но это уже отдельный вопрос.