В первой части мы развернули простую динамическую CDN для трансляции WebRTC потоков на два континента и убедились в том, что задержки в такой CDN действительно низкие, на примере таймера обратного отсчета.

Однако, кроме низкой задержки, важно обеспечить зрителям хорошее качество трансляции, ведь за это они и платят. В реальной жизни, каналы между Edge серверами и подписчиками могут быть разными по пропускной способности и качеству. Например, мы публикуем поток разрешением 720p с битрейтом 2 Мбит/с, а пользователь играет его на Android-смартфоне, используя 3G подключение в зоне неуверенного приема сигнала, и максимальное разрешение, при котором картинка будет плавной, всего 360p с битрейтом 400 Мбит/с.

Устройства и браузеры, которыми пользуются зрители, бывают очень разными. Например, мы публикуем WebRTC поток с использованием кодека VP8 из браузера Chrome на ПК, а зритель играет поток в Safari на iPhone, который поддерживает только кодек H264. Или наоборот, мы публикуем RTMP поток из OBS Studio, кодируя видео в H264, а звук в AAC, а клиент использует браузер на основе Chromium, в котором поддерживается только VP8 или VP9 для видео и opus для звука.

Может понадобиться и повышение качества исходной публикации. Например, мы раздаем поток с IP-камеры в каком-нибудь заповеднике, большую часть времени картинка статична, камера ее отдает с частотой 1 кадр в секунду. В то же время зрителю мы хотим играть 24 кадра в секунду. Как быть, если заменить камеру или изменить ее настройки невозможно?

Во всех этих случаях потребуется транскодирование потока на сервере, то есть декодирование каждого принятого кадра и последующее кодирование с новыми параметрами. Причем параметры, которые должны быть изменены, часто известны только на стороне клиента. Посмотрим, как можно обеспечить транскодинг в CDN, балансируя между качеством трансляции и нагрузками на серверы.

Транскодинг: как, где и почему?

Допустим, нам известны параметры потока, которые желает получить клиент. Например, зритель начал играть поток, и количество потерь кадров в WebRTC статистике говорит нам о том, что разрешение и битрейт необходимо снизить, пока клиент не переключил каналы. В этом случае по умолчанию поток будет транскодироваться на Edge сервере, к которому подключен зритель.

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

И то, и другое может быть только временным решением, при условии, что конфигурации Origin и/или Edge серверов были выбраны с запасом. Транскодинг всегда производится покадрово, поэтому он очень требователен к ресурсам процессора. Так, одно процессорное ядро способно транскодировать совсем небольшое число потоков:

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

Таким образом, правильным решением будет выделить специальные серверы в CDN под задачи транскодирования, и выбрать конфигурацию серверов исходя из этих задач.

Добавляем Transcoder узлы в CDN

Итак, развернем в нашей CDN по одному серверу с ролью Transcoder в европейском и американском дата-центрах

Настройка Transcoder серверов:

• Transcoder 1 EU

cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder

• Transcoder 1 US

cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder

Параметры транскодирования потоков должны быть описаны на Edge серверах в виде специальных профилей в файле cdn_profiles.yml. В качестве примера, рассмотрим три профиля по умолчанию:

• транскодирование к разрешению 640×360, 30 кадров в секунду, ключевой кадр передается на каждые 90 кадров, видеокодек H264 c использованием кодировщика OpenH264, аудиокодек Opus 48 кГц

-640x360:   audio:     codec : opus     rate : 48000   video:     width : 640     height : 360     gop : 90     fps : 30     codec : h264     codecImpl : OPENH264

• транскодирование к разрешению 1280×720, видеокодек H264 c использованием кодировщика OpenH264, без транскодирования звука

 -720p:   video:     height : 720     codec : h264     codecImpl : OPENH264

• транскодирование к разрешению 1280×720, 30 кадров в секунду, ключевой кадр передается на каждые 90 кадров, битрейт 2 Мбит/с, видеокодек H264 c использованием кодировщика OpenH264, без транскодирования звука

 -720p-2Mbps:   video:     height : 720     bitrate : 2000     gop : 90     fps : 30     codec : h264     codecImpl : OPENH264

Публикуем поток test разрешением 720p на сервере o-eu1 и играем этот поток на e-eu1, указав профиль в имени потока, например, test-640x360

Поток транскодируется!

Теперь мы можем описать на Edge серверах ряд профилей, например -240p, -360p, -480p и, если на стороне клиента по данным WebRTC статистики диагностируется большое число потерянных кадров, автоматически перезапрашивать поток с более низким разрешением.

Группируем узлы CDN по континентам

Сейчас наши Transcoder серверы равноправны. А что делать, если мы хотим транскодировать потоки по географии: для американских зрителей в Америке, для европейских — в Европе? Это, кстати, позволит уменьшить нагрузку на трансатлантические каналы, поскольку в этом случае с Origin EU сервера в Америку и наоборот пойдут только исходные потоки, а не все варианты транскодированных.

В этом случае в настройках Transcoder узлов необходимо указать группу

• Transcoder 1 EU

cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU

• Transcoder 1 US

cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US

Также группу необходимо добавить в настройки Edge серверов

• Edge 1-2 EU

cdn_groups=EU

• Edge 1-2 US

cdn_groups=US

Перезапускаем узлы с новыми настройками. Публикуем поток test разрешением 720p на сервере o-eu1, играем этот поток на e-eu1 с транскодингом

Убедимся, что поток транскодируется на t-eu, для этого открываем страницу статистики http://t-eu1.flashphoner.com:8081/?action=stat и видим кодировщик и декодировщик видео в разделе Native resources

При этом на t-us1 в статистике нет кодировщиков видео

Больше транскодеров: балансируем нагрузку

Допустим, число зрителей продолжает расти, и мощностей одного Transcoder сервера на континент уже не хватает. Отлично, добавим еще по одному серверу

• Transcoder 2 EU

cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU

• Transcoder 2 US

cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US

Однако теперь у нас появляется проблема распределения нагрузки по двум транскодерам. Чтобы не пускать все потоки через один сервер, ограничим максимально допустимую среднюю загрузку процессора на Transcoder узлах

cdn_node_load_average_threshold=0.95

Когда средняя загрузка процессора, деленная на количество доступных ядер, достигнет этого значения, сервер перестанет принимать запросы на транскодирование новых потоков.

Можно также ограничить максимальное количество одновременно запущенных кодировщиков видео

cdn_transcoder_video_encoders_threshold=10000

Когда это количество будет достигнуто, сервер также перестанет принимать запросы на транскодирование потоков, даже если загрузка процессора это еще позволяет.

В любом случае, Transcoder сервер продолжит раздавать Edge серверам те потоки, которые на нем уже транскодируются.

Окончание следует

Итак, мы развернули в нашей CDN выделенные серверы для транскодирования медиапотоков и, таким образом, можем обеспечить нашим зрителям качество трансляции в зависимости от возможностей их оборудования и качества каналов. Однако, мы все еще не затрагивали вопрос ограничения доступа к потокам. Его мы рассмотрим в заключительной части.

Ссылки

CDN для стриминга WebRTC с низкой задержкой — сеть доставки контента на базе Web Call Server.

На самом деле, правило фиговое. Но понятное дело, почему оно работает. В среде безопасников считается, что антифрод должен быть такой суперсекретной штуковиной за семью печатями с парой голодных Церберов поблизости. Чтобы никто-никто не мог заглянуть в щель и узнать, как этот антифрод работает и вообще, чего там внутри. Безопасникам это добавляет важности, а самому механизму антифрода — иллюзорную защиту.

Принцип security through obscurity не работает. Если пойти погуглить насчет новостей в разрезе «Клиента банка Х взломали и увели Y рублей», то такие новости будут всегда. Почти каждый день (почти — потому что не всегда об этом пишут).

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

Поэтому система, которая считается защищенной только потому, что люди не знают, как она работает — вообще ни разу не защищенная. А вот чем такая система открытее, тем быстрее въедливое сообщество укажет своим критически настроенным перстом на все косяки в реализации. Что позволит эти косяки устранить.

Я работаю именно в парадигме открытости протоколов и систем, и в этом посте я хочу рассказать про устройство стандартного антифрода, о работе нашего в RBK.money, почему будущее за OpenSource, а также о том, как всё это может работать в идеальном мире.

Который мы с вами и можем приблизить.

Антифрод под капотом

Начнем с самых простых примеров. Антифрод — это совокупность двух машин. Первая работает по каким-то правилам, которые вы знаете и которые вам понятны. Вторая — черный ящик, в котором творится магия, постичь которую не помогут даже канистра энергетика и томик Ницше.

То есть в первой машине у нас лежит набор правил, написанный человеком. Правила выглядят довольно просто и всего-навсего отражают определенный набор действий, который должен триггерить систему на распознание фрода. Например, если с такой-то карты внезапно понеслось по 10 платежей в минуту, это неслабый такой повод насторожиться. Или если транзакция по карте прошла в Питере, а 5 минут назад хозяин по ней снимал деньги в Москве — тут тоже что-то странное.

Я повторюсь, я сейчас сильно образно, потому что такое поведение может быть и в нормальной ситуации. Например, Амазон любит снимать деньги не за весь ваш заказ из 15 позиций, а за каждую позицию по отдельности. Причем в разное время, это нормально. А в случае с географической разницей — хозяин карты может быть в Москве, а в Питере что-то на эту же карту в Apple Pay покупает его мама. Да, на картах пишут, что их не стоит передавать третьим лицам и вот это всё, но жизнь обычно немного сложнее.

Про вторую коробку. Там лежит большой кусок machine learning, и тут конкретно показать на пальцах в простой структуре, как там чего с чем соотносится для выводов, уже не так просто.

И вот из этого базиса можно вывести критерии хорошего антифрода.

Три кита

Во-первых, это интерфейс написания правил. Удобный, красивый и понятный. Об этом будет чуть ниже.

Во-вторых, специальный язык написания этих правил.

В-третьих, быстрая обработка этих написанных правил.

Почему быстро — потому что скорость тут реально важна. Антифрод как сущность ставится в разрыв платежной системы. И тут есть два подхода подобной реализации.

1) Bypass

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

2) Минимизация рисков

В этой ситуации бизнес понимает, что антифрод, в общем-то, не просто так поставили в систему, и прислушивается к его показаниям. Если есть подозрение на фрод, то бизнес тормозится, разбираются в ситуации, и только потом платеж проводится. Или не проводится.

Поэтому антифрод должен быть быстрым, максимально быстрым, и при этом адекватно конфигурироваться.

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

• ip
• fingerprint
• БИН банка
• ID мерчанта
• токен карты

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

Да, кстати, важно понимать, что антифрод — это не вещь в себе. Он не может быть плохим или хорошим, это инструмент, требующий настройки. И если антифрод работает хреново, это не потому, что антифрод хреновый — это его хреново настроили, вписали не те правила или не учли еще кучу важных штук.

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

И это правильно. Если ты оперируешь чужими деньгами, люди тебе их доверяют, а ты не в состоянии их защитить — на кой ты вообще на рынке? Открой шиномонтаж, например.

Поэтому у тебя или хорошо настроенный антифрод, или никакого вообще, ибо тебя выкинули с рынка и он тебе больше не нужен.

Своя рубаха

Когда мы писали свой антифрод, мы смотрели на все это, проверяли работоспособность, и поставили в итоге ClickHouse.

Работает это так. У нас есть платёжная система, которой активно пользуются. Соответственно, генерится большое количество событий. Все эти события мы единым потоком сливаем в ClickHouse, где они успешно агрегируются и обрабатываются. И обрабатываются быстро.

Некоторое время назад у нас был вендорский антифрод. Вполне себе решение, работало по подписке, особых неудобств не доставляло. Но когда мы вывели для себя критерии правильного антифрода, мы стали писать свой. Писали мы его суммарно месяца два, внешняя апишечка описана swagger-ом. Когда закончили, стали тестить, сначала пускали почти весь трафик на старый, а небольшую часть — на новый. Ну а вдруг там навернется чего.

Не навернулось. Мы его активно отлаживали, использовали на старте как такую добавочную рекомендалочку. А на днях мы полностью перетащили все на него, он ощутимо быстрее старого, шустро отрабатывает все правила, в общем — полет нормальный. Но старый пока лежит как запаска.

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

Уютного интерфейса мы пока не сделали, так как пока мы на этапе отлаживания протокола и правил (их у нас штук 200+, новые пишем ежедневно). Система управляется бодрым curl напрямую из консоли. И тут уже главная задача антифродера (да, есть такой специально обученный человек, который именно этим занимается) — сидеть, внимательно смотреть на трафик, получать чарджбеки из-за фрода, корректировать правила. Как видите, роботам пока не удалось полностью спихнуть с работы кожаных мешков.

В общем, новый сейчас хорош. Но пока не прямо отличный-отличный. Хотим впилить туда dry run — это когда ты написал правило, а потом прогнал через него какой-то конкретный платеж с пометкой «А что было бы с платежом, если бы к нему применилось это правило». Это вот ощутимо прокачает его возможности.

А ещё интерфейсы моделирования хочется строить. Ну знаете, как в фильмах, когда бравые ФБР-овцы отслеживают беглеца по кредитке — ага, смотри, вот тут он заправился на кредитку, вон там кофе купил, а в том городе наличку снял. И все это с привязкой к карте, прочим данным, с красивой визуализацией. Дело времени.

Идеальная система

Когда мы допишем наш антифрод, он станет отличным. А вот идеал, как обычно, достижим не так легко.

Идеал, как по мне, построен на абсолютном OpenSource. То есть опенсорсный антифрод на опенсорсном языке и удобный обмен правилами.

Давайте на примере про подобную идеальную систему защиты от DDoS.

Представим, что всех текущих операторов мамкины дудосеры достали так сильно, что они объединились и стали использовать единую базу засранцев. Если на ресурсе какого-то маленького оператора начинается DDoS, он оперативненько смотрит, какому оленю не спится, добавляет айпишники негодяя в блеклист. Обновление блеклиста расходится по единой системе, и все, что связано с этой атакой, блокируется на уровне клиентских подключений.

Вопрос доверия и надежности такой системы решается блокчейном.

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

Система распределенная, у нас же блокчейн, взломать ее нельзя. ОК, если представить, что взломали сам антифрод у одного банка — это все еще проблема банка. Потому что общий у нас только список правил. А сами движки антифрода в каждом банке свои.

Как на самом деле сейчас. Банки — очень консервативные структуры. Очень. Сейчас у них есть небольшая рассылка, приходит письмо на определенных спецов, мол, зацените, а вот тут карта дропа, вот параметры. Но это рассылка. Про оперативность и вовлеченность можно вообще забыть сразу. Но лучше, чем вообще ничего, да.

Так что такую идеальную историю банки вряд ли осилят. Финтех вот вполне себе может потянуть, именно платежные системы и стартапы.

Machine learning вкупе с OpenSource — это будущее антифрода. кто хорошо научится с этим работать, тот сможет взять неплохой куш — индустрия огромна, там миллиарды. Но идеально решения пока нет.

А раз его нет — то есть хорошие возможности выйти на рынок.

(статья Wired 2018 года)

Фермерское бюро Калифорнии (The California Farm Bureau) отказало фермерам в праве чинить свое оборудование, не обращаясь к дилеру.

Война фермеров-инженеров и производителем тракторов John Deere началась в 2015 и продолжается до сих пор. Вот примерная хронология на Хабре:

• Самостоятельный ремонт трактора John Deere — нарушение закона DMCA (2015)
• Фермеры США все еще пытаются добиться права ремонтировать собственные тракторы John Deere (2016)
• Американские фермеры взламывают и устанавливают украинскую прошивку на тракторы (2017)
• Почему американские фермеры обходят DRM тракторов украинской прошивкой — анализ ситуации (2017)

Какое будущее нас ждёт?

Предлагаем вам перевод самой последней статьи на эту тему в достаточно авторитетном журнале Wired.

Борьба за право чинить свои собственные вещи потерпела огромную неудачу.

Кто хоть раз ремонтировал электронику, знает, что нужно чинить как железо, так и софт. У фермеров есть «профсоюз», и этот профсоюз подписал соглашение, согласно которому, теперь фермерам запрещено иметь доступ и изменять исходный код в их тракторах и прочей технике.
Калифорнийское фермерское бюро (The California Farm Bureau), насчитывающее 2,5 миллиона рабочих мест, отказало фермерам в праве покупать запчасти, не проходя через дилера. Теперь фермеры не могу менять настройки в двигателе, внедрять новые функции и подгонять свою технику под меняющиеся экологические стандарты. Хуже того, их профсоюз гордится этим нововведением.

Фермерам очень важно самим ремонтировать свое оборудование. Ждать несколько дней пока John Deere отправит техника, чтобы тот починил комбайн, – непозволительная роскошь для фермера во время сбора урожая. Кроме того, фермеры — довольно рукастые ребята. Они чинят свои машины уже целую вечность. Зачем тратить тысячи долларов на то, что легко можно починить самим? Однако, сельскохозяйственное оборудование становится все более сложным и электронным, и у фермеров зачастую просто нет нужных инструментов, чтобы привести все в порядок, несмотря на то, что именно фермеры более всего заинтересованы в работе своих машин. Все усугубляется еще и тем фактом, что John Deere (и другие компании по производству оборудования, представленные the Far West Equipment Dealers Association) прикрываются законом об авторских правах, что мешает фермерам еще больше.

Монополии на ремонт оборудования очень выгодны, это огромный бизнес. Далеко ходить не надо, к примеру, компания Apple всегда запрещала ремонт своей техники и приобретение деталей у кого-либо другого, кроме нее самой. Именно по этой причине Big Ag так не хочет идти на уступки движению фермеров за право на ремонт.

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

Но если у фермеров не будет доступа к запчастям и диагностическому программному обеспечению, то все это теряет смысл. «Я за любые нововведения, которые помогут мне чинить свои машины», — говорит Jeff Buckingham, владелец ранчо San Luis Obispo. «В конце концов, я купил это все и хочу, чтобы все работало, а я мог это починить, не дожидаясь помощи дилера».
В соглашении нет ничего нового. John Deere и компания уже «уступили» фермерам и ранее в этом году запустили сервисные руководства в продажу. Должно быть, они осознали неизбежность своего положения, когда новый закон о праве на ремонт электроники был введен в Калифорнии в марте. Законопроекты о праве на ремонт оказались чрезвычайно популярными среди избирателей – Массачусетс принял свой законопроект о праве на ремонт автомобилей в 2012 году с поддержкой 86 процентов избирателей.

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

Как сообщил Jason Koebler из Motherboard, этот флаер как две капли воды похож на соглашение, которое только что заключило фермерское бюро (the Farm Bureau). Листовка и соглашение содержат одинаковые ограничения:

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

В итоге все упирается в эти ограничения. Если бы автомеханики не могли бы перепрограммировать автомобильные компьютеры, большая часть современных ремонтных работ была бы просто невозможна. Если механику нужно починить кондиционер в Civic, наверняка ему нужно будет перепрограммировать электронный блок управления. Электроника контролирует все основные функции основного сельскохозяйственного оборудования, из-за одного датчика вся машина может перестать работать. Изменение софта – большая часть современного ремонта.

Кроме того, если фермер не может изменять систему, контролирующую выбросы, то ему придется каждый раз покупать новую технику, чтобы соответствовать эко стандартам. И это очень коварно со стороны таких компаний, как John Deere.

Именно поэтому фермеры борются за право вносить изменения в софт. Американская федерация фермеров, национальная ассоциация производителей кукурузы и национальный союз фермеров (the American Farm Bureau Federation, the National Corn Growers Association, the National Farmers Union) работают с фондом электронных рубежей (Electronic Frontier Foundation) и ходатайствуют перед управлением авторских прав США, чтобы освободить сельскохозяйственную технику от положений закона об авторских правах в цифровую эпоху (Digital Millennium Copyright Act).

It is necessary to access the electronic control units to diagnose and repair a malfunctioning agricultural vehicle, as well as to lawfully modify the functions of a vehicle based on the owner’s specific needs in cultivating his or her land.

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

Многие фермеры изменяют свое оборудование в соответствии с потребностями своей земли. Члены сообщества электроники сельскохозяйственной техники Farm Hack разработали пользовательские семенные ролики, напечатанные с помощью 3D принтера, запрограммировали Arduino для укрепления тепличных систем и разработали все виды датчиков и сигналов предупреждения. Группа студентов из университета Cal Poly работает над реверс-инжинирингом протокола программного обеспечения John Deere. А также сторонняя компания под названием Farmobile делает устройство, которое подключается ко всем видам крупной сельскохозяйственной техники, чтобы фермеры могли получить доступ к данным, минуя John Deere.

tractorhacking.github.io

Вся Америка следует за калифорнийскими фермерами, что неудивительно, ведь штат Калифорния производит больше продовольствия, чем любой другой в стране, на его долю приходится две трети всех выращенных в США фруктов и орехов. Соглашаясь с фейковым различием между «ремонтом» и «изменением софта», Калифорнийское фермерское бюро (The California Farm Bureau) только усложнило работу фонда электронных рубежей (EFF). Вместо того, чтобы предоставить фермерам право на ремонт, это соглашение только запутывает. Более того, оно может закрепить культурный прецедент для производителей электроники, которые хотят запретить сторонним техникам изменять софт устройства.

Как нация защитников ремонта, мы должны отказаться от таких беззубых сделок. Право на ремонт надо определить так, чтобы выгодно было физическим лицам и мелким производителям, а не корпорациям.

Данной сделке не выиграть права на ремонт, что бы там не говорили John Deere или the California Farm Bureau. Реальный прогресс не наступит до тех пор, пока штат не выпустит реальный законопроект Right to Repair legislation. Но динамика набирает обороты. 20 штатов, включая Айову, Канзас и Небраску, рассматривали законопроекты в этом году. Несмотря на то, что ни один еще не прошел, John Deere явно стало не по себе.

---

Читать еще полезные статьи:

• McKinsey: переосмысляем софт и архитектуру электроники в automotive
• Очередная война операционок уже идет под капотом автомобилей
• Программный код в автомобиле
• В современном автомобиле строк кода больше чем…

На «Пикабу» появилась новая функция: посты-ответы — фича для тех, кому «постом навеяло» написать собственную статью. Это отличная функция, важность которой выходит далеко за пределы «Пикабу» и касается состояния всего современного интернета.

Пост-ответ — это цифровая реинкарнация жанра публицистической дискуссии. Традиционно этот жанр считался «газетным», но, на самом деле, он гораздо старше как масс-медиа (переписка Ивана Грозного и Андрея Курбского), так и печати как таковой.

В печатной прессе этот жанр расцвёл: ярчайшие примеры подобных публичных дискуссий внесли в историю публицистики вклад не меньший, чем лучшие соло-публикации — если не больший. Люди до сих пор помнят о спорах Герцена с Чаадаевым — даже если не читали ни одной из их публикаций. Наверное, потому, что любая яркая статья была обречена перерасти в дискуссию. Тогда как статьи, не способные вызвать обсуждение, оказались забыты.

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

При этом в онлайне возник другой, совершенно новый, ранее не существовавший жанр: жанр комментария. Ответить на публикацию разными способами можно было и раньше. Но никогда — таким образом, чтобы вся её аудитория имела возможность увидеть этот ответ в том же месте.

Разница между «давай я на твою развёрнутую мысль, изложенную в форме публикации развернуто отвечу в той же форме» и «давай я на твою развёрнутую мысль, изложенную в форме публикации развёрнуто отвечу в виде подписи к ней» — принципиальная.

Но, к сожалению, не с точки зрения биологии. Глубина и обстоятельность ответа зависит от силы выброса дофамина — гормона мотивации. А дальше психика уже подберёт наименее затратный из доступных способ воплощения возникшего желания. В доинтернетную эпоху те, у кого была такая возможность, в ответ на затронувшую их публикацию размещали свою публикацию. У кого не было — писали письма авторам или редакции.

С интернетом у людей появилась ранее отсутствовавшая возможность ответить «на месте», прямо в подписи к публикации. С точки зрения психики — разницы почти нет, чувство удовлетворения от ответа практически одинаковое. Таким образом, более простой вариант получает преимущество.

В совокупности, вымирание прессы и появление комментариев привело к тому, что пар — желание ответить — чаще стал уходить в свисток, в комментарии — даже когда человеку действительно есть, что сказать. В эпоху комментариев любое обсуждение рискует оказаться законсервированным внутри одной записи, тогда как некоторые ответы сами тянут на пост или требуют поста.

Многие скажут, что это хорошо — вся информация, релевантная посту, находится в одном месте, обеспечивая continuity (связность). Но обратной стороной этого удобства является ограничение дискуссии количеством людей, прочитавших исходную публикацию. Если пост прочитала тысяча человек, то количество людей, увидевших ответы к нему, тоже будет ограничено этой тысячей.

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

Обмен мнениями пост-на-пост, объединённый перелинковкой в цепочку публикаций на одну тему даже из двух, не говоря уже о большем числе постов, чем два, и участников, чем двое в цепочке — это другой уровень коммуникации, который добавляет огромное количество добавочной ценности по сравнению с простыми комментариями.

Почему это до сих пор такая редкость в интернете? Да всё из-за той же связности: ответная публикация можешь вовлечь в разговор новых участников, но оказаться пропущенной старыми. И если кто-нибудь потом набредёт в обсуждение уже «протухшей» публикации, то может пропустить развитие истории, если оно не будет отображено в комментариях.

Посты-ответы на «Пикабу» убивают двух зайцев разом, решая и проблему связности, и проблему ограниченности.

1. Теперь обсуждение, разросшееся на несколько постов, не потеряется в пространстве, потому что посты-ответы видны в комментариях к оригиналу.
2. При этом, обсуждение любой темы, достаточно интересной, чтобы кто-то захотел по ней высказаться отдельной публикацией, привлечёт больше внимания, не ограниченного охватом оригинальной записи.

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

Его оцифровывание в виде постов-ответов на «Пикабу» — отличная новость и пример для любой площадки, организованной по принципу коллективного блога.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «JavaScript in 3D: an Introduction to Three.js» автора Брета Кемерона (Bret Cameron).

Введение

Three.js это мощный инструмент. Он помогает использовать 3D дизайн в браузере с приемлемой производительностью. По началу Three.js может быть сложным, особенно если вы никогда не погружались в мир 3D программирования ранее.

У меня есть базовый опыт работы с игровым движком Unity и C#, но все равно многие концепции оказались новыми для меня. Я пришел к выводу, что сейчас совсем мало ресурсов для начинающих разработчиков, поэтому я и решил написать эту статью. В ней мы рассмотрим основные элементы Three.js сцены от полигональных сеток и материалов до геометрии, загрузчиков и много другого.

В конце этой статьи, у вас будет твердое понимание базовых аспектов, необходимых для добавления дополнительного измерения в ваш будущий веб проект.

Three.js примеры от Ben Houston, Thomas Diewald and StrykerDoesAnimation.

Векторы и контейнеры – основные строительные блоки

Зачастую выделяют два основных класса в Three.js – Vector3 и Box3. Если вы новичок в 3D, то это может звучать немного абстрактно, но вы встретите их еще очень много раз.

Vector3

Самый основной 3D класс, содержащий три числа: x,y и z. Числа представляют собой координаты точки в 3D пространстве или направление и длину. Например:

const vect = new THREE.Vector3(1, 1, 1);

Большая часть конструкторов в Three.js принимают объекты типа Vector3 в качестве входных аргументов, например Box3

Box3

Этот класс представляет кубойд (3д контейнер). Его главная задача – создать контейнер вокруг других объектов – и все, наименьший кубойд в который поместится 3D объект. Каждый Box3 выравнивается про осям x, y и z.Пример, как создать контейнер, используя Vector3:

const vect = new THREE.Vector3(1, 1, 1); const box = new THREE.Box3(vect);

Пример как создать контейнер вокруг уже имеющегося 3D объекта:

const box = new THREE.Box3(); box.setFromObject(object);

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

Полигональная сетка

В Three.js основной визуальный элемент на сцене это Mesh. Это 3D объект, составленный из треугольных прямоугольников (полигональная сетка). Он строится при помощи двух обектов:
Geometry – определяет его форму, Material – определяет внешний вид.

Их определения могут показаться немного запутанно (например, класс Geometry может содержать информацию про цвет), но главное отличие именно такое.

Geometry

Основываясь на задаче, которую вы хотите достигнуть, возможно вам захочется определить геометрию внутри Three.js или импортировать другую из файла.

Используя функции как THREE.TorusKnotGeometry, мы можем создать сложные объекты одной строчкой кода. Мы скоро доберемся до этого, но сначала рассмотрим более простые формы.
Самая простая 3D фигура, кубойд или контейнер, может быть задан параметрами width, height и depth.

const geometry = new THREE.BoxGeometry( 20, 20, 20 );

Для сферы минимально нужно значение параметров radius, widthSegments и heightSegments. Две последние переменные указывают сколько треугольников модель должна использовать, чтобы представить сферу: больше количество – более гладко будет выглядеть.

const geometry = new THREE.SphereGeometry( 20, 64, 64 );

Если мы хотим сделать острые или треугольные формы, то можно использовать конус. Его аргументы это сочетание аргументов двух предыдущих фигур. Ниже, мы прописываем radius, widthSegments и radialSegments.

 const geometry = new THREE.ConeBufferGeometry( 5, 20, 32 );

Это лишь часть самых распространенных фигур. Three.js имеет внутри очень много фигур из коробки, которые можно посмотреть в документации. В этой статье, мы расмотрим более интересные формы, построенные на основе метода TorusKnotGeometry.

Почему эти фигуры выглядят именно так как они выглядят? Этот вопрос выходит за рамки этой статьи, но я призываю вас экспериментировать со значениями параметров, потому что вы можете получить очень интересные фигуры одной строчкой кода!

const geometry = new THREE.TorusKnotGeometry(10, 1.3, 500, 6, 6, 20);

https://codepen.io/BretCameron/pen/gOYqORg

Материалы

Геометрия задает форму наших 3D объектов, но не их внешний вид. Чтобы это исправить, нам нужны материалы.

Three.js предлагает из коробки 10 материалов, каждый из них имеет свои плюсы и настраиваемые параметры. Мы рассмотрим лишь часть самых полезных.

MeshNormalMaterial

Полезен при быстром старте и запуске

Мы начнем с MeshNormalMaterial, многоцветный материал, который мы использовали в примерах выше. Он соответствует нормальным векторам в панели RGB, другими словами, используются цвета для определения позиции вектора в 3D пространстве.

const material = new THREE.MeshNormalMaterial();

Заметим, что если вы хотите поменять цвет материала, то можно использовать CSS фильтр и изменять насыщенность:

 filter: hue-rotate(90deg) .

По моему опыту, этот материал более полезен для быстрого страта и запуска. Для большего контроля ваших объектов лучше использовать что нибудь другое.

MeshBasicMaterial

Полезен при отображении только скелета

Если вы хотите придать фигуре единый цвет, то можно использовать MeshBasicMaterial, только если не применяется освещение. Я нашел полезным применения того материала в отрисовке скелета модели. Для отрисовки только скелета нужно передать { wireframe: true } как параметр.

const material = new THREE.MeshBasicMaterial({    wireframe: true,    color: 0xdaa520 });

Главный недостаток этого материала в том, что абсолютно пропадает информация о глубине материала. Каждый материал имеет опцию для отображения только скелета, но только один материал решает проблему отсутствие глубины — MeshDepthMaterial

MeshLambertMaterial

Полезен при высокая производительность, но низкой точности

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

const scene = new THREE.Scene(); const frontSpot = new THREE.SpotLight(0xeeeece); frontSpot.position.set(1000, 1000, 1000); scene.add(frontSpot); const frontSpot2 = new THREE.SpotLight(0xddddce); frontSpot2.position.set(-500, -500, -500); scene.add(frontSpot2);

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

const material = new THREE.MeshLambertMaterial({   color: 0xdaa520,   emissive: 0x111111, });

Как вы можете увидеть в примере ниже, цвет более менее правильный, но то, как он взаимодействует со светом не добавляет реалистичности. Для исправления этого, нам нужно использовать MeshPhongMaterial или MeshStandardMaterial.

MeshPhongMaterial

Полезен при средней производительности и средней точности

Этот материал предлагает компромисс между производительностью и точностью отрисовки, поэтому этот материал – хороший вариант для приложения, которое должно быть производительным наряду с более точной отрисовкой чем при MeshLambertMaterial.

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

const material = new THREE.MeshPhongMaterial({   color: 0xdaa520,   emissive: 0x000000,   specular: 0xbcbcbc, });

Визуально, изображение сверху отражает свет более убедительно, но все еще не идеально. Белый свет слишком яркий и материал выглядит более ребристо, чем металлически (а мы стремимся именно к этому). Мы можем получить результат лучше, используя MeshStandardMaterial.

MeshStandartMaterial

Полезен при высокой точности, но низкой производительности

Это самый точный материал из всех, хотя его использование повлечет за собой издержки использования большей мощности. MeshStandartMaterial используется с дополнительными параметрами metalness и roughness, каждый из которых принимает значение между 0 и 1.

Параметр metalness влияет на то, как объект отражает, становясь ближе природе металла. Все потому что проводниковые материалы как металлы имеют другие отражающие свойства в отличии от диэлектриков таких как керамика.

Roughness добавляет дополнительный слой для кастомизации. Можно представить его как как противоположность глянцевости: 0 – очень глянцевый, 1 – очень матовый.

const material = new THREE.MeshStandardMaterial({   color: 0xfcc742,   emissive: 0x111111,   specular: 0xffffff,   metalness: 1,   roughness: 0.55, });

Это самый реалистичный материал из всех представленных в Three.js, но и самый ресурсозатратный

Материалы, которые мы обсуждали внизу это те, которые я встречал чаще всего и посмотреть все варианты можно в доке.

Загрузчики

Как мы уже обсудили выше, можно вручную определять геометрию и полигональные сетки. На практике люди чаще загружают свои геометрии из файлов. К счастью, Three.js имеет немного поддерживаемых загрузчиков, поддерживающих многие 3D форматы.

Основной ObjectLoader загружает JSON файл, используя JSON Object/Scene format. Большинство загрузчиков нужно импортировать вручную. Вы можете найти полный список поддерживаемых загрузчиков тут и импортировать их. Ниже небольшой список того что можно импортровать.

// GLTF import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'; // OBJ import { OBJLoader } from 'three/examples/jsm/loaders/OBJLoader.js'; // STL import { STLLoader } from 'three/examples/jsm/loaders/STLLoader.js'; // FBX import { FBXLoader } from 'three/examples/jsm/loaders/FBXLoader.js'; // 3MF import { 3MFLoader } from 'three/examples/jsm/loaders/3MFLoader.js';

Рекомендуемый формат для онлайн просмотра – GLTF, по причине того, что формат “направлен на доставку ассетов в рантайме, компактный для передачи и быстрый для загрузки”.

Кончено, может быть очень много причин предпочитать определенный тип файлов (например, если качество в приоритете или нужно точность для 3D печати). Лучшая же производительность онлайн будет, при импорте GLTF.

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'; import model from '../models/sample.gltf'; let loader = new GLTFLoader(); loader.load(model, function (geometry) {   // if the model is loaded successfully, add it to your scene here }, undefined, function (err) {   console.error(err); });

Соединяем все вместе

Одна из причин почему Three.js может показаться запугивающим в том, что создать что то с нуля можно лишь парой строчек кода. В каждом примере выше, нам нужно было создать сцену и камеру. Чтобы упростить, я держал этот код за рамками рассмотрения, но сейчас мы посмотрим как это будет выглядеть все вместе.

То, как вы организуете свой код решаете только вы. В более простых примерах, таких как в этой статье, есть смысл писать весь код в одном месте. Но на практике, полезно разделять отдельные элементы для возможности расширения кодовой базы и ее управления.

Для простоты, мы рассмотрим элементы, которые отрисуются как один объект, поэтому весь код мы разместим в одном файле.

// Import dependencies import * as THREE from 'three'; import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';  // Создаем сцену const scene = new THREE.Scene(); scene.background = new THREE.Color(0x282c34);  // Определяем камеру, устанавливаем ее на заполнения окна браузера const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 10000); camera.position.z = 5;  // Определеяем "рисовальщика" и устанавливаем на окно браузера const renderer = new THREE.WebGLRenderer(); renderer.setSize(window.innerWidth, window.innerHeight);  // Берем элемент DOM и прикрепляем renderer.domElement к нему document.getElementById('threejs').appendChild(renderer.domElement);  // Добавляем управление, устанавливаем как цель тот же DOM элемент let controls = new OrbitControls(camera, document.getElementById('threejs')); controls.target.set(0, 0, 0); controls.rotateSpeed = 0.5; controls.update();  // Определяем (или импортируем) геометрию объекта const geometry = new THREE.TorusKnotGeometry(10, 1.3, 500, 6, 6, 20);  // Определяем материал объекта const material = new THREE.MeshStandardMaterial({   color: 0xfcc742,   emissive: 0x111111,   specular: 0xffffff,   metalness: 1,   roughness: 0.55, });  // Создаем полигональную сеть, масштабируем ее и добавляем на сцену const mesh = new THREE.Mesh(geometry, material);  mesh.scale.x = 0.1; mesh.scale.y = 0.1; mesh.scale.z = 0.1;  scene.add(mesh);  // Добавляем освещение, устанавливаем его и добавляем на сцену const frontSpot = new THREE.SpotLight(0xeeeece); const frontSpot2 = new THREE.SpotLight(0xddddce);  frontSpot.position.set(1000, 1000, 1000); frontSpot2.position.set(-500, -500, -500);  scene.add(frontSpot); scene.add(frontSpot2);  // Создаем функцию анимации, которая позволит вам отрисовать Вашу сцену и определить любое движение const animate = function () {   requestAnimationFrame(animate);    mesh.rotation.x += 0.005;   mesh.rotation.y += 0.005;   mesh.rotation.z += 0.005;    renderer.render(scene, camera); };  // Зовем функцию анимации animate();

Нужно ли использовать фреймворк?

Наконец то, пришло время обсудить стоит ли использовать Three.js со своим любимым фреймворком? На текущий момент, есть хороший пакет react-three-fiber для React. Для пользователей React, есть очевидные преимущества пользования пакетом как этот – вы сохраняете структуру работы с компонентами, которая позволяет переиспользовать код.

Для новичков я советую начать с обычного Vanila JS, потому что большинство онлайн материалов, написанных про Three.js относятся к Three.js на Vanila JS. Основываясь на моем опыте изучения, это может быть запутано и трудно изучать через пакет – например, вам придется транслировать Three.js объекты и методы на компоненты и пропсы. (как только вы освоите Three.js можете использовать любой пакет).

Как добавить Three.js в фреймворк

Three.js дает HTML объект (чаще всего называется он renderer.domElement) который может быть добавлен к любому HTML объекту в вашем приложении. Например, если у вас есть div с id=”threejs” вы можете просто включит следующий код в ваш Three.js код:

document.getElementById('threejs').appendChild(renderer.domElement);

Некоторые фреймворки имет предпочтительные пути обращения к узлам DOM дерева. Например, ref в React, $ref в Vue или ngRef в Angular и это выглядит как массивный плюс на фоне прямого обращения к элементам DOM. Как пример, давайте рассмотрим быструю реализацию для React.

Стратегия для React

Если вы используете React, то существует один путь внедрения Three.js файлов в один из ваших компонентов. В файле ThreeEntryPoint.js мы напишем следующий код:

export default function ThreeEntryPoint(sceneRef) {   let renderer = new THREE.WebGLRenderer();    // ...   sceneRef.appendChild(renderer.domElement); } 

Мы экспортируем это как функцию, которая принимает один аргумент: ссылку на элемент в нашем компоненте. Теперь мы можем создать наш компонент

import React, { Component } from 'react'; import ThreeEntryPoint from './threejs/ThreeEntryPoint'; export default class ThreeContainer extends Component { componentDidMount() {     ThreeEntryPoint(this.scene);   } render() {     return (       <>         <div ref={element => this.scene = element} />       </>     );   } }

Импортированная функция ThreeEntryPoint должна вызываться в методе componentDidMount и передавать новый div как аргумент, используя ссылки
В качестве примера такого подхода в действии, можно склонировать репозиторий и попробовать самостоятельно: https://github.com/BretCameron/three-js-sample.

Заключение

Есть еще очень много, что я могу расскзать про Three.js, но я надеюсь что эта статья дала вам достатчно информации для того, чтобы начать использовать эту мощную технологию. Когда я только начал изучать Three.js я не мог найти ни одного ресурса как эта статья, поэтому я надеюсь я помог сделать эту технологию более доступной для начинающих.