1. Там же важнее переиспользование структур SocketAsyncEventArgs — что дает меньший расход памяти и уменьшает нагрузку на GC.
2. На уровне .NET Standard 2.0 код нормально шарился между платформами. В крайнем случае можно было настроить multitargeting на netcoreapp2.1, netstandard2.0 и net47. А на .NET Core 3 и 3.1 уже даже WPF заработал.
P.S. Вообще интересно даже что вы там такое использовали, что только .NET 5 нормально стал поддерживать?
У меня возникло два вопроса?
1. Почему код сокетов не был переписан на асинхронные сокеты (это не те что async/await, а те что SocketAsyncEventArgs)?
2. Почему не был осуществлен переход на Core 2.x. Я в одном из проектов с Mono под ARM благополучно перешел на core под ARM, а уж 3.1 там поддерживал любые изыски.
При развертывании в Kubernates, вам нужен init-контейнер, который приготавливает базу.
При развертывании локально вам нужно чтоб миграции выполнились при старте сервиса. Не всегда используется EF, я, например, использую пару NHibernate и Dapper в зависимости от потребностей
Что касается кодов ошибок, таких кодов не так много.
200 — стандартный ответ
204 — null (реализовано .NET)
На все остальные кидается Exception, который выставляет код ошибки.
Я лично за подход 200 — возвращается всегда когда API правильно отработало запрос, 500 — когда произошла ошибка. Ведь сервисы еще и мониторить надо
Автомэппер тоже отдельное зло. Я помню как сделал protected set в просто set и Mapster сломался. Учитывая что правка была оценена в 1 час, пришлось сделать public метод, который эту логику реализовывает. Поэтому автомепперы это тоже зло.
Более того часто люди не понимают как это работает — в итоге получаем что у нас есть три enum в разных проектах, которые в друг друга мапятся вместо одно enum.
А задачи по добавлению одного поля в ответ отнимают половину рабочего дня. А если там еще интеграционные тесты на каком-нибудь питоне, то задача по добавлению одного поля может и за 2 дня в мастер не вмерджиться.
Кодогенерацию еще и запускать надо. В новом .NET 5 она уже нормальная станет
В любой компании есть человек, который любит придумывать такие абстракции над абстракциями и еще обижается когда их мало кто использует.
Архитектура проекта должна быть такова, чтобы позволять делать вещи удобно и с минимальными усилиями, при этом оставляя проект тестируемым.
Если взять C# то тут:
1. БД должна быть полностью описана миграциями (FluentMigrator)
2. Уровень доступа к БД должен быть покрыт компонентными тестами которые выполняются в Docker (поднимается минимальная рабочая инфраструктура для сервиса)
3. Должны быть интеграционные тесты выполняющие определенные сценарии, также исполняемые в Docker, при этом тесты должны быть внутри этого же решения.
4. Для каждого контроллера делать фасад. Никакой логики в контроллере. В простейшем случае фасад же и будет репозиторием.
5. Никогда не закладывать в начале создания сервиса overhead на репозитории, внутренние сервисы и прочее когда в них нет надобности. В 99% случаев микросервисов достаточно контроллера, фасада и уровня ORM.
6. Давать именам осмысленные названия чтобы проект не состоял из кучи бессмысленных producer,consumer,context и прочего вырвиглаза который не нужно инжектить. Его можно просто создать в том сервисе, который логически за всё это отвечает, а не в инициализации контейнера.
7. Шаблон репозиторий на высокой нагрузке приводит к тому, что код на нём сложно оптимизировать. Например, в процессе оптимизации просто приходится напрямую в базу ходить, чтобы сделать JOIN на 4 таблицы вместо того чтобы данные извлекать по очереди. Просто потому что через репозиторий это сделать невозможно не вынося на верх Query(...) который просто окажется абстракцией над решением ORM
Ну вот тут, хз. Я лично боюсь что исполнители накосячат или как-то не так применят неоднозначный механизм.
Перед этим голосованием я был в составе экспертной группы по голосованию в ДИТ и там было сделано всё хорошо (под это выделили и людские ресурсы и машинные и вообще удивительно, потому что на тестовом голосовании были проблемы). И после голосования также создалось впечатление что всё должно быть хорошо — и тут всплывает эта поделка, которая делалась другим ведомством в последний вечер :-D
Поэтому и не хочется видеть решения, которые допускают недетерминированное поведение. Это Россия, тут если исполнителю уже на этапе проектирования дали возможность налажать — он налажает
В 22:17 по МСК уже приложение было скомпилировано, в 22:38 был дописан файл ReadMe.txt. Доступных серверных мощностей под ДЭГ чуть более чем дохера. Там одних виртуалок было около 150 штук.
Проблема была в том, что эту поделку, оказывается делал даже не ДИТ Москвы, а совсем другое ведомство
В таком случае тем же перебором можно было бы всё восстановить :-)
Нет, тут на мой взгляд оптимальное решение — клиент-серверное.
Учитывая что «внутри» инфраструктуру обеспечивает РосТелеком, а «снаружи» можно прикрутить резервный метод с ограниченным RPS.
Это как раз к вопросу почему при таких задачах нужны люди с опытом по криптографии/ИБ
Правильно решить эту задачу может человек, который знаком не только с тем как работает хэш-функция, но и с методами атак на них.
Вы же постепенно шаг за шагом задумываетесь о тех вещах, которые разработчик с соответствующим опытом уже знает :-)
Так, там есть и защита на сетевом уровне DDoS, а RPS с одного IP нужно ограничить. Учитывая что паспортов всего миллион — хеши можно держать в памяти в словаре. Сможете сами оценить сколько запросов в секунду выдержит такая архитектура? Более того она еще и горизонтально масштабируемая :-)
Вы похоже не понимаете, что как происходит разработка ПО. Программисту всегда ставится бизнес-задача. Я напомню вам, что у нас на всех участках не то что есть Интернет, там даже обеспечено видео-наблюдение на инфраструктуре РосТелекома. Поэтому существующая инфраструктура УЖЕ работает с интернетом. Поэтому проблем не будет.
Но даже если предположить что вы правы и Интернет пропал везде, включая сотовые телефоны(!), то давайте подсчитаем по времени хеширования. Если просто добавить миллион итераций sha256, то проблему бы не заметили:
10 миллиардов комбинаций можно прогонять 4 часа (1 кратное выполнение хеша), а можно 400 лет. К тому времени данные бы потеряли актуальность. Цена реализации — дополнительный цикл for.
Hashcat — это вообще удар ниже пояса, особенно если у вас под рукой настольный компьютер с NVidia. К сожалению я был на даче и под рукой у меня был только ноутбук с встроенной графикой на которой OpenCL для hashcat работает не стабильно.
Т.е. завести поддомен на сайте госсулуги и разместить там общедоступный произвольный файл для скачивания можно, а развернуть там код, который загрузит в память csv-файл и будет отвечать true,false,null в зависимости от нахождения хэша и значения булевой переменной ну никак нельзя?
Вы знаете сколько времени потребуется C# разработчику чтобы написать такой серверный-бэкенд?
Там будет:
1. контроллер
2. фасад в котором будет один Dictionary<string,bool>, не нашел -> null, нашел -> вернул значение
3. Код загрузки csv
Это любой ASP.NET разработчик вам на собеседовании на листочке бумаги должен написать за гораздо меньшее время чем за 3 часа.
Что касается бюрократии — в государственных структурах когда «жопа горит» любые бюрократические проволочки решаются очень быстро. Просто в известность ставится вышестоящее начальство, которое решает проблемы бюрократии одним звонком.
Пока разработчик пишет код, манагер должен звонить. Если они оба компетентны — никто даже не узнает про то какой был пц. Так работают госструктуры.
Разработчика тут никто и не винит. Речь как раз была в том, что виновато руководство, которое не привлекло ни архитектора ни безопасника. Если хотя бы один был привлечен — задача была бы решена без такого позора.
Посмотрите внимательно у вас всё равно количество входных данных осталось то же — 10^10. Просто усложнилась хеш-функция, которая стала составной. В этом как раз суть проблемы — соль неприменима в этом режиме использования.
2. На уровне .NET Standard 2.0 код нормально шарился между платформами. В крайнем случае можно было настроить multitargeting на netcoreapp2.1, netstandard2.0 и net47. А на .NET Core 3 и 3.1 уже даже WPF заработал.
P.S. Вообще интересно даже что вы там такое использовали, что только .NET 5 нормально стал поддерживать?
1. Почему код сокетов не был переписан на асинхронные сокеты (это не те что async/await, а те что SocketAsyncEventArgs)?
2. Почему не был осуществлен переход на Core 2.x. Я в одном из проектов с Mono под ARM благополучно перешел на core под ARM, а уж 3.1 там поддерживал любые изыски.
При развертывании локально вам нужно чтоб миграции выполнились при старте сервиса. Не всегда используется EF, я, например, использую пару NHibernate и Dapper в зависимости от потребностей
Что касается кодов ошибок, таких кодов не так много.
200 — стандартный ответ
204 — null (реализовано .NET)
На все остальные кидается Exception, который выставляет код ошибки.
Я лично за подход 200 — возвращается всегда когда API правильно отработало запрос, 500 — когда произошла ошибка. Ведь сервисы еще и мониторить надо
Более того часто люди не понимают как это работает — в итоге получаем что у нас есть три enum в разных проектах, которые в друг друга мапятся вместо одно enum.
А задачи по добавлению одного поля в ответ отнимают половину рабочего дня. А если там еще интеграционные тесты на каком-нибудь питоне, то задача по добавлению одного поля может и за 2 дня в мастер не вмерджиться.
Кодогенерацию еще и запускать надо. В новом .NET 5 она уже нормальная станет
Архитектура проекта должна быть такова, чтобы позволять делать вещи удобно и с минимальными усилиями, при этом оставляя проект тестируемым.
Если взять C# то тут:
1. БД должна быть полностью описана миграциями (FluentMigrator)
2. Уровень доступа к БД должен быть покрыт компонентными тестами которые выполняются в Docker (поднимается минимальная рабочая инфраструктура для сервиса)
3. Должны быть интеграционные тесты выполняющие определенные сценарии, также исполняемые в Docker, при этом тесты должны быть внутри этого же решения.
4. Для каждого контроллера делать фасад. Никакой логики в контроллере. В простейшем случае фасад же и будет репозиторием.
5. Никогда не закладывать в начале создания сервиса overhead на репозитории, внутренние сервисы и прочее когда в них нет надобности. В 99% случаев микросервисов достаточно контроллера, фасада и уровня ORM.
6. Давать именам осмысленные названия чтобы проект не состоял из кучи бессмысленных producer,consumer,context и прочего вырвиглаза который не нужно инжектить. Его можно просто создать в том сервисе, который логически за всё это отвечает, а не в инициализации контейнера.
7. Шаблон репозиторий на высокой нагрузке приводит к тому, что код на нём сложно оптимизировать. Например, в процессе оптимизации просто приходится напрямую в базу ходить, чтобы сделать JOIN на 4 таблицы вместо того чтобы данные извлекать по очереди. Просто потому что через репозиторий это сделать невозможно не вынося на верх Query(...) который просто окажется абстракцией над решением ORM
Перед этим голосованием я был в составе экспертной группы по голосованию в ДИТ и там было сделано всё хорошо (под это выделили и людские ресурсы и машинные и вообще удивительно, потому что на тестовом голосовании были проблемы). И после голосования также создалось впечатление что всё должно быть хорошо — и тут всплывает эта поделка, которая делалась другим ведомством в последний вечер :-D
Поэтому и не хочется видеть решения, которые допускают недетерминированное поведение. Это Россия, тут если исполнителю уже на этапе проектирования дали возможность налажать — он налажает
Проблема была в том, что эту поделку, оказывается делал даже не ДИТ Москвы, а совсем другое ведомство
Нет, тут на мой взгляд оптимальное решение — клиент-серверное.
Учитывая что «внутри» инфраструктуру обеспечивает РосТелеком, а «снаружи» можно прикрутить резервный метод с ограниченным RPS.
Правильно решить эту задачу может человек, который знаком не только с тем как работает хэш-функция, но и с методами атак на них.
Вы же постепенно шаг за шагом задумываетесь о тех вещах, которые разработчик с соответствующим опытом уже знает :-)
Но даже если предположить что вы правы и Интернет пропал везде, включая сотовые телефоны(!), то давайте подсчитаем по времени хеширования. Если просто добавить миллион итераций sha256, то проблему бы не заметили:
10 миллиардов комбинаций можно прогонять 4 часа (1 кратное выполнение хеша), а можно 400 лет. К тому времени данные бы потеряли актуальность. Цена реализации — дополнительный цикл for.
Вы знаете сколько времени потребуется C# разработчику чтобы написать такой серверный-бэкенд?
Там будет:
1. контроллер
2. фасад в котором будет один Dictionary<string,bool>, не нашел -> null, нашел -> вернул значение
3. Код загрузки csv
Это любой ASP.NET разработчик вам на собеседовании на листочке бумаги должен написать за гораздо меньшее время чем за 3 часа.
Что касается бюрократии — в государственных структурах когда «жопа горит» любые бюрократические проволочки решаются очень быстро. Просто в известность ставится вышестоящее начальство, которое решает проблемы бюрократии одним звонком.
Пока разработчик пишет код, манагер должен звонить. Если они оба компетентны — никто даже не узнает про то какой был пц. Так работают госструктуры.