Базовые модули заменить нереально. Так станцию строили. Заря это как раз базовый модуль.
При слишком частых поломках или проблемах всю станцию надо в океан.
Новую станцию уже можно попробовать спроектировать уже с учетом ремонта и замены базовых модулей.
В остальном — а нельзя ли эту задачу выполнять по индукции? Ну, т.е. нашли решения для доски n x n, а затем придумываем как перейти к решению для (n + 1) x (n + 1). Явно, что это правило перехода должно быть универсальным. Или… нет?
Доказательство такой возможности, даже без алгоритма, потянет на серьезную математическую премию.
PDF Хорош своей стабильностью и универсальностью. Любой файл на любом устройстве будет показан одинаково.
И плох ей же. К примеру, электронные книги не могут отрисовывать странички красиво под свой размер.
Количество костылей в PDF просто зашкаливает. Начиная от кучи древних форматов хранения картинок. Там есть такая экзотика… Включая забагованный JBIG2.
И заканчивая множествами вариантами для производства одной операции. Все можно сделать несколькими способами. Зачем непонятно. Результат абсолютно одинаков. Нет даже рекомендаций как рекомендуется делать.
Очень хочу новую ревизию с deprecated всей экзотики и рекомендациями по использованию методов для типовых вещей. Вот в этом замучаешься разбираться: T*, Tc, Td, TD, Tj, TJ, TL, Tm, Tr, Tw, Tz И это только базовый вывод текста. Функционал дублируется раза 3.
Как именно шифровать это не важно в данном случае. Но необходимо понимать общий принцип шифрования. Пакет отдельно, пользовательские данные в нем отдельно. Ключ от пакета сессионный, ключ от пользовательских данных только у получателя.
Миллион пользователей это мало. Мессенджеры нынче живут на миллиарде пользователей. И любая разработка должна быть готова к работе с таким объемом. Миллиард это 10Тб шаренной и доступной со всех узлов входа ОЗУ только на сессии. Это уже много. Очень много. Да и просто держать столько открытых tls сессий это задача ну очень нетривиальная.
Проблема что это плохо масштабируется горизонтально.
Проблема что это плохо будет работать за фаерваллами.
Это будет плохо работать за двойными натами.
Это плохо совместимо с проксями.
Это проблема консистентности статуса клиента и сервера.
Это в конце концов кастомный низкоуровневый протокол. То есть все типовые балансировщики с ним будут работать плохо или не будут вообще.
Реверс прокси работать не будет точно.
И ради чего все это? Чтобы пользователь имел повышенный шанс отправить сообщение при ухудшении сигнала? Оно того не стоит.
Вы вот так вот сразу отказали от End2End шифрования. В 2019 году. Вы это серьезно?
Шифруем все в 2 слоя. Первый пакет до сервера, второй само сообщение.
Сессионный ключ клиента это не паблик ключ сервера. Это именно сессионный ключ. Чтобы в случае компрометации серверного ключа трафик нельзя было расшифровать. Да и использовать один ключ неопределенно долгое время это не очень. Азы же.
1. Вы считаете размер пакета, а надо считать размер инфы которою нужно хранить на серверах для поддержания сессии.
2. Всю историю можно хранить на дисках и не париться о скорости. Подгрузка истории это процесс не требующий особой скорости. Клиент готов подождать пока у него загрузится история на новой устройстве. А вот информация о сессиях нужна в памяти. К ней нужен очень быстрый доступ.
3. Проблема не в сообщениях, а в клиентах. С сообщениями все понятно. таймстемп последнего и хеш от него же.
При https да. Именно так и делаем и все просто. Вы же хотите кастомный udp протокол. На сервер будет приходить шифрованный массив. Надо найти от него ключ, расшифровать, найти клиента, валидировать что все ок и уже потом передать на обработку.
4. Сессионные ключи строго обязательны в 2019 году. Я выше написал.
Это даже на идею не тянет. Не говоря уже о прототипе. Отправка по UDP пакета и ожидание ответа сервера перед отправкой следующего максимум на лабораторку тянет.
Решается, только масштабируется не очень. Нам нужен как минимум id клиента, id сессии, ключ шифрования и хеш с таймстемпом последнего сообщения. Пара килобайт точно. Если подумать точно еще что-то вылезет что надо хранить. На миллиарде клиентов это терабайты данных.
Шардирование делать сложно. Пакеты шифрованные. В начале надо терминировать tls. Проблема явно решаемая, но не с налету.
Вот чувствую зря я про совсем потом на писал. Там и без этого пункта проблем с stateful выше крыши.
В реальном мире у нас есть авторизации, ключи, сессии.
Вы сделали stateful мессенджер для телефона. А теперь придумайте пяток сценариев где это не будет работать вообще.
И на закуску парочку сценариев где это приведет к серьезным проблемам. Не отправленное сообщение, которое отображается отправленным, это серьезная проблема.
Совсем потом можно подумать на тему хранения сессий в WhatsApp. Миллиард активных пользователей. Как вы бы обработали на серверах stateful?
Не понимаете. Если делать все правильно то УЦ ничего плохого сделать и скомпрометировать в принципе не сможет. Он проверяет ваши документы, подписывает ваш сертификат и все.
Из CSR воровать в принципе нечего. Это публичная информация.
Неэкспортируемый ключ с токена нельзя экспортировать. Вообще никак. Нет никакой секретной галочки. Вот мол я хороший парень мне можно.
А они делают все так что у них может остаться ваш приватный ключ. И они будут подписывать от вашего имени все что захотят. Да и вообще любой желающий может скачать этот ключ с токена и делать все захочет.
Не знаю как эти, но адекватные УЦ без проблем подписывают CSR.
Да и с токенами с по настоящему неизвлекаемыми ключами работают почти без проблем. Почти без проблем это примерно минут 30 перезвона внутри УЦ с привлечением каких-то спецов которые понимают что надо делать.
А вот почему они всеми силами проталкивают решения с ключами в виде файлика на флешке я не понимаю. Неужели это денег больше приносит?
Вы что хотите сказать docx на Линукс не поддерживается!
Эти поделки линуксовые хотя бы с табличками и колонками работать научились?
Про режим правок и VB я даже спрашивать не буду. И так знаю что не научились.
Изумительно работает!
И именно поэтому вы даете http ссылку. Прям идеальный кейс. Об изумительно работающем гостовом https предлагают почитать по http. Это все что вам надо знать по отлично работающий гостовый https.
По сравнению со многими другими странами Госуслуги это просто образец удобства и функциональности. Да и налоговая потихоньку подтягивается. nalog.ru уже имеет смысл и уже лучше чем подобные сервисы в большинстве стран.
При слишком частых поломках или проблемах всю станцию надо в океан.
Новую станцию уже можно попробовать спроектировать уже с учетом ремонта и замены базовых модулей.
А для научного спутника на такой странной орбите вопрос не актуален. Отработал гарантийный срок и хорошо. Переработал вообще замечательно.
Доказательство такой возможности, даже без алгоритма, потянет на серьезную математическую премию.
Или есть еще какая причина использовать велосипед, вместо отраслевого стандарта?
И плох ей же. К примеру, электронные книги не могут отрисовывать странички красиво под свой размер.
Количество костылей в PDF просто зашкаливает. Начиная от кучи древних форматов хранения картинок. Там есть такая экзотика… Включая забагованный JBIG2.
И заканчивая множествами вариантами для производства одной операции. Все можно сделать несколькими способами. Зачем непонятно. Результат абсолютно одинаков. Нет даже рекомендаций как рекомендуется делать.
Очень хочу новую ревизию с deprecated всей экзотики и рекомендациями по использованию методов для типовых вещей. Вот в этом замучаешься разбираться: T*, Tc, Td, TD, Tj, TJ, TL, Tm, Tr, Tw, Tz И это только базовый вывод текста. Функционал дублируется раза 3.
Миллион пользователей это мало. Мессенджеры нынче живут на миллиарде пользователей. И любая разработка должна быть готова к работе с таким объемом. Миллиард это 10Тб шаренной и доступной со всех узлов входа ОЗУ только на сессии. Это уже много. Очень много. Да и просто держать столько открытых tls сессий это задача ну очень нетривиальная.
Проблема что это плохо масштабируется горизонтально.
Проблема что это плохо будет работать за фаерваллами.
Это будет плохо работать за двойными натами.
Это плохо совместимо с проксями.
Это проблема консистентности статуса клиента и сервера.
Это в конце концов кастомный низкоуровневый протокол. То есть все типовые балансировщики с ним будут работать плохо или не будут вообще.
Реверс прокси работать не будет точно.
И ради чего все это? Чтобы пользователь имел повышенный шанс отправить сообщение при ухудшении сигнала? Оно того не стоит.
Шифруем все в 2 слоя. Первый пакет до сервера, второй само сообщение.
Сессионный ключ клиента это не паблик ключ сервера. Это именно сессионный ключ. Чтобы в случае компрометации серверного ключа трафик нельзя было расшифровать. Да и использовать один ключ неопределенно долгое время это не очень. Азы же.
1. Вы считаете размер пакета, а надо считать размер инфы которою нужно хранить на серверах для поддержания сессии.
2. Всю историю можно хранить на дисках и не париться о скорости. Подгрузка истории это процесс не требующий особой скорости. Клиент готов подождать пока у него загрузится история на новой устройстве. А вот информация о сессиях нужна в памяти. К ней нужен очень быстрый доступ.
3. Проблема не в сообщениях, а в клиентах. С сообщениями все понятно. таймстемп последнего и хеш от него же.
При https да. Именно так и делаем и все просто. Вы же хотите кастомный udp протокол. На сервер будет приходить шифрованный массив. Надо найти от него ключ, расшифровать, найти клиента, валидировать что все ок и уже потом передать на обработку.
4. Сессионные ключи строго обязательны в 2019 году. Я выше написал.
Решается, только масштабируется не очень. Нам нужен как минимум id клиента, id сессии, ключ шифрования и хеш с таймстемпом последнего сообщения. Пара килобайт точно. Если подумать точно еще что-то вылезет что надо хранить. На миллиарде клиентов это терабайты данных.
Шардирование делать сложно. Пакеты шифрованные. В начале надо терминировать tls. Проблема явно решаемая, но не с налету.
Вот чувствую зря я про совсем потом на писал. Там и без этого пункта проблем с stateful выше крыши.
Вы сделали stateful мессенджер для телефона. А теперь придумайте пяток сценариев где это не будет работать вообще.
И на закуску парочку сценариев где это приведет к серьезным проблемам. Не отправленное сообщение, которое отображается отправленным, это серьезная проблема.
Совсем потом можно подумать на тему хранения сессий в WhatsApp. Миллиард активных пользователей. Как вы бы обработали на серверах stateful?
И сразу все станет понятно.
Из CSR воровать в принципе нечего. Это публичная информация.
Неэкспортируемый ключ с токена нельзя экспортировать. Вообще никак. Нет никакой секретной галочки. Вот мол я хороший парень мне можно.
А они делают все так что у них может остаться ваш приватный ключ. И они будут подписывать от вашего имени все что захотят. Да и вообще любой желающий может скачать этот ключ с токена и делать все захочет.
Да и с токенами с по настоящему неизвлекаемыми ключами работают почти без проблем. Почти без проблем это примерно минут 30 перезвона внутри УЦ с привлечением каких-то спецов которые понимают что надо делать.
А вот почему они всеми силами проталкивают решения с ключами в виде файлика на флешке я не понимаю. Неужели это денег больше приносит?
Б — Безопасность!
Чтобы просто зайти на сайт надо всем на все устройства ставить какую-то непонятную приблуду.
Кстати, а на Андроидах и iOS оно работает?
Эти поделки линуксовые хотя бы с табличками и колонками работать научились?
Про режим правок и VB я даже спрашивать не буду. И так знаю что не научились.
И именно поэтому вы даете http ссылку. Прям идеальный кейс. Об изумительно работающем гостовом https предлагают почитать по http. Это все что вам надо знать по отлично работающий гостовый https.