Вы просто не представляете масштаб, сложность и уровень ответственности при таких блокировках (масштаб - вся страна).
Это весьма непростая задача для команды опытных инженеров. Терабиты трафика для реал-тайм обработки с необходимостью точечной классификации. Плюсом ко всему трафик мигрирующий между выходными узлами и/или сервером обработки.
Не нужно думать что когда что-то отваливается это в виду некомпетентности людей. Просто это реально очень сложно.
_ в начале имени члена класса весьма удобен - при написании и чтении когда сразу с первого символа названия переменной понимаешь что это не аргумент и не локальная переменная.
Согласен с вопросом проблемности архитектуры нынешних технологий - клиент<->сервер.
Но насколько я понимаю, ваш мессенджер не решает эту проблему. Такж есть сервера вашего мессенджера, которые можно определять и блокировать.
---
На мой взгляд, P2P должен получить новый виток на фоне того, что происходит в мире с технологиями. Причем без каких-то костылей в виде mesh систем и блютузов.
Готовых и подходящих симуляторов ядра сети и пользовательских устройств на рынке мы не нашли, поэтому разрабатываем их самостоятельно.
Где-то читал (уже не помню) что не смотря на то что стандарты мобильной связи имеют спецификации составленные 3GPP, в разных странах работа мобильной сети может немного отличаться. Это правда? И если да, то может это и причина того что готовых симуляторов нет, так как они затачиваются под страну?
И второй вопрос, а что ожидается от симулятора пользовательского устройства? Работа GSM модуля с возможностью проигрывать сценарии?
маршрутизатор направляет запрос DHCP-серверу для получения динамического IP-адреса. Сервер выдаёт адрес и запускает shell-скрипт, ...
То есть у вас свой модифицированный DHCP который дергает shell скрипт после выдачи IP адреса? Который в свою очередь шлет запрос (команду) на активацию политики no-auth (условное название) для конкретного IP адреса, верно?
Я ведь описал механизм (SPID - Statisitcal Protocol Identification). Он основывается не на протоколе, а статистических характеристиках, которые можно рассчитывать как для шифрованного трафика, так и для не шифрованного.
Что до чата, передачи файла, отсылки кружка, и прочего - делаются условно 100 тестов и составляются референсные значения (вилки) для каждой категории.
DPI классифицирует сервис (WhatsApp, Telegram, Viber, ...), затем происходит классификация workflow (аудио/видео вызов, передача файла, чат). Workflow классифицируется только для отдельные сервисов, для которых это требуется и мессенджеры одни из них. Например для какого-нибудь DropBox можно также классифицировать передачу файлов или для YouTube можно классифицировать Video stream.
Классификация workflow не всегда "протокольная" как описано в статье. Какой-нить SIP/RTP/RTCP можно отловить для FaceTime. Для телеграм это не сработает - там свой протокол и для DPI это выглядит как нераспознанный трафик. Но так как основной сервис определен (Telegram), то DPI может сделать предположение о том, что этот поток делает (workflow) на основе статистической информации по потоку: уровень энтропии, битрейт, средний размер пакетов, IAT (inter arrival time) и прочее. Например для аудио вызова характерен высокий битрейт и не очень большой размер пакетов. Для видео вызова также высокий битрейт и большой размер пакетов. Для передачи файлов - бла-бла, и так далее.
Вывод уведомлений в реальном времени (отпадает необходимость постоянно доставать смартфон). Просто удобно.
Вывод каких-то важных оповещений. Например при вождении можно не дёргать глазами на навигатор, а очки будут отображать полосу, скорость, время до точки и так далее.
Вывод дополнительного дисплея при работе за компьютером (монитором) или на крайний случай вывод виджетов.
Встроенный AI помогающий тебе в режиме реального времени. Например пишешь статью или код и не нужно плодить 100500 плагинов - очки видят все то, что видите вы.
Google Glass как отличный пример опередивший время. Очки дополненной реальности для 2013 казались чем-то непонятным, но в наши дни практически каждый осознает как они могут быть применены.
P.S. Apple Vision не в счёт. Это вообще не пойми что. Для маргиналов)
В 2015 (или 2016) закрыли G+ где сохранял ссылки на статьи. Выгруженные данные где-то лежат в архиве, но вот куда их загрузить чтобы они были в «потребном» виде не понятно. Начал использовать Pocket. И вот 2025 и его тоже закрывают и снова выгружать ссылки и снова они будут валяться в архиве на диске.
Два крупных сервиса для агрегации ссылок за 10 лет грохнули)
Предоставьте простые и понятные инструменты для активации лицензии конечным пользователем. Например, внедрите элемент самообслуживания через личный кабинет с возможностью мгновенной покупки, изменения тарифного плана или переноса лицензий между устройствами.
Года 3 назад, видел как в одной из компаний начали улучшать данный процесс. Его назвали User Journey (кажется это какой-то специальный термин). Цель была упростить покупку и продление лицензии для пользователей. Чтобы все было приятно и красиво. Это здравая мысль и это действительно работает, но вот оплату автоматизировать для B2B продукта не так просто в случае, если общая стоимость продукта (или совокупная цена) достаточно большая. Условно карту не привяжешь для оплаты лицензии на сумму >= 10 000 000 рублей в год и все возвращается к ручному/автоматическому генерированию счета на оплату, ожидания перевода, подтверждение его человеком и выдаче лицензионных ключей.
Я правильно понимаю что на данный момент это не больше чем IDE с прикрученным AI плагинами?
Как агенты они не рабоют. То есть, невозможно на данный момент подключить к этим IDE issue tracker, где можно повесить теги “ai” для задач, которые мы можем делегировать искусственному интеллекту и на выходе ожидать готовый MR, с документированными коммитами, новыми тестами, изменениями в доке если требуется и пройденным циклом CI/CD?
Вы просто не представляете масштаб, сложность и уровень ответственности при таких блокировках (масштаб - вся страна).
Это весьма непростая задача для команды опытных инженеров. Терабиты трафика для реал-тайм обработки с необходимостью точечной классификации. Плюсом ко всему трафик мигрирующий между выходными узлами и/или сервером обработки.
Не нужно думать что когда что-то отваливается это в виду некомпетентности людей. Просто это реально очень сложно.
Наконец-то! Давно пора сделать такой фильтр.
Так и есть - это субъективный-объективизм)
Здесь нет правильно или неправильного ответа (пока это не ломает сборку компилятором) и определяется мэинтейнером проекта.
_в начале имени члена класса весьма удобен - при написании и чтении когда сразу с первого символа названия переменной понимаешь что это не аргумент и не локальная переменная.Как вариант решения кейса для многопоточности - атомарный индекс для вершины стека.
Когда приходит запрос на выделение сегмента - первым делом резервируется сегмент через инкремент индекса.
Или альтернативный и самый простой вариант - thread_local пул. Но тогда потребление памяти будет не рациональным.
Согласен с вопросом проблемности архитектуры нынешних технологий - клиент<->сервер.
Но насколько я понимаю, ваш мессенджер не решает эту проблему. Такж есть сервера вашего мессенджера, которые можно определять и блокировать.
---
На мой взгляд, P2P должен получить новый виток на фоне того, что происходит в мире с технологиями. Причем без каких-то костылей в виде mesh систем и блютузов.
Где-то читал (уже не помню) что не смотря на то что стандарты мобильной связи имеют спецификации составленные 3GPP, в разных странах работа мобильной сети может немного отличаться. Это правда? И если да, то может это и причина того что готовых симуляторов нет, так как они затачиваются под страну?
И второй вопрос, а что ожидается от симулятора пользовательского устройства? Работа GSM модуля с возможностью проигрывать сценарии?
Тоже хотел об этом написать, что причина скорее в уже написанных (для мессенджера) библиотеках, зависимостях и технологиях.
Всем вокруг одна сплошная конспирология мерещится.
То есть у вас свой модифицированный DHCP который дергает shell скрипт после выдачи IP адреса? Который в свою очередь шлет запрос (команду) на активацию политики
no-auth(условное название) для конкретного IP адреса, верно?Тоже заметил что файлы стали долго уходить. Возможно передача файлов некорректно классифицируется как видеовызов.
P.S. Всё нормально, бывает=)
Я ведь описал механизм (SPID - Statisitcal Protocol Identification). Он основывается не на протоколе, а статистических характеристиках, которые можно рассчитывать как для шифрованного трафика, так и для не шифрованного.
Что до чата, передачи файла, отсылки кружка, и прочего - делаются условно 100 тестов и составляются референсные значения (вилки) для каждой категории.
DPI классифицирует сервис (WhatsApp, Telegram, Viber, ...), затем происходит классификация workflow (аудио/видео вызов, передача файла, чат). Workflow классифицируется только для отдельные сервисов, для которых это требуется и мессенджеры одни из них. Например для какого-нибудь DropBox можно также классифицировать передачу файлов или для YouTube можно классифицировать Video stream.
Классификация workflow не всегда "протокольная" как описано в статье. Какой-нить SIP/RTP/RTCP можно отловить для FaceTime. Для телеграм это не сработает - там свой протокол и для DPI это выглядит как нераспознанный трафик. Но так как основной сервис определен (Telegram), то DPI может сделать предположение о том, что этот поток делает (workflow) на основе статистической информации по потоку: уровень энтропии, битрейт, средний размер пакетов, IAT (inter arrival time) и прочее. Например для аудио вызова характерен высокий битрейт и не очень большой размер пакетов. Для видео вызова также высокий битрейт и большой размер пакетов. Для передачи файлов - бла-бла, и так далее.
Первое что приходит в голову:
Вывод уведомлений в реальном времени (отпадает необходимость постоянно доставать смартфон). Просто удобно.
Вывод каких-то важных оповещений. Например при вождении можно не дёргать глазами на навигатор, а очки будут отображать полосу, скорость, время до точки и так далее.
Вывод дополнительного дисплея при работе за компьютером (монитором) или на крайний случай вывод виджетов.
Встроенный AI помогающий тебе в режиме реального времени. Например пишешь статью или код и не нужно плодить 100500 плагинов - очки видят все то, что видите вы.
Google Glass как отличный пример опередивший время. Очки дополненной реальности для 2013 казались чем-то непонятным, но в наши дни практически каждый осознает как они могут быть применены.
P.S. Apple Vision не в счёт. Это вообще не пойми что. Для маргиналов)
В 2015 (или 2016) закрыли G+ где сохранял ссылки на статьи. Выгруженные данные где-то лежат в архиве, но вот куда их загрузить чтобы они были в «потребном» виде не понятно. Начал использовать Pocket. И вот 2025 и его тоже закрывают и снова выгружать ссылки и снова они будут валяться в архиве на диске.
Два крупных сервиса для агрегации ссылок за 10 лет грохнули)
Года 3 назад, видел как в одной из компаний начали улучшать данный процесс. Его назвали User Journey (кажется это какой-то специальный термин). Цель была упростить покупку и продление лицензии для пользователей. Чтобы все было приятно и красиво. Это здравая мысль и это действительно работает, но вот оплату автоматизировать для B2B продукта не так просто в случае, если общая стоимость продукта (или совокупная цена) достаточно большая. Условно карту не привяжешь для оплаты лицензии на сумму >= 10 000 000 рублей в год и все возвращается к ручному/автоматическому генерированию счета на оплату, ожидания перевода, подтверждение его человеком и выдаче лицензионных ключей.
Я правильно понимаю что на данный момент это не больше чем IDE с прикрученным AI плагинами?
Как агенты они не рабоют. То есть, невозможно на данный момент подключить к этим IDE issue tracker, где можно повесить теги “ai” для задач, которые мы можем делегировать искусственному интеллекту и на выходе ожидать готовый MR, с документированными коммитами, новыми тестами, изменениями в доке если требуется и пройденным циклом CI/CD?
Когда уже конец?)
Пользовался Yolla когда был зарубежом, чтобы делать звонки в другие страны или на стационарные телефоны стран где путешествовал. Отлично работал.
Это действительно работает? Всегда думал что нельзя создать AppleID без номера телефона той страны, в регионе которой регистрируется учётка.