Александр Ананьев

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

Полагаю, свитч провайдера перешел в режим хаба по какой-то причине (рассылает полученные пакеты на все порты без фильтрации), т.к. вы видите в touch unicast-трафик других IP-адресов. Кто-то скачивает файл через L2TP на полной скорости, и эти данные приходят всем клиентам на все порты свитча.

Вам нужно объяснить поддержке, что их свитч (скорее всего, в вашем доме) неисправен либо программно, либо аппаратно, и «перешел в режим хаба. Когда кто-то качает файл, у всех остальных маленькая скорость. На мой порт приходит L2TP-трафик других IP-адресов.».

Ссылка - это как указатель, только она не может быть нулевой.
Поэтому никак нельзя вернуть *nullptr_t вместо ссылки на переменную, в отдельных случаях.

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

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

Вам лучше подойдут указатели.

Одновременно и просто и сложно, зависит от "глубины погружения в тему"
Для различных авто немного по разному, но принцип один и тот же, по ОБД данные доступны через запросы к соответствующему модулю (MRM,ABS,ESP ....) (думаю для разных машин по разному и с различной точностью, количеством инфо) скорость поворота руля и угол поворота (если память не изменяет с точностью до десятых долей) скорость вращения каждого колеса тоже с точностью до десятой доли км/ч. Но тут встает момент, что некоторые модули ABS при таких запросах становится в диагностический режим а свыше 30-50 км/ч выходят из него и перестают отвечать на подобные запросы. Но это не отменяет возможности подслушивать эти сообщения по CAN, например в приборку прилетает постоянно скорость. Но и тут от модели авто зависит, где-то это просто скорость, а где-то 4 значения по каждому колесу.
И 2й вариант подслушивать эти сообщения на шине, когда блоки общаются между собой. И опять ньюанс, на разных машинах по разному, но например высокоскоростная шина моторного (мотор коробка абс) не флудит этим трафиком в ОБД, а на некоторых машинах наоборот все слышно по ОБД
По частоте запросов точно не скажу, тоже вариативно, но минимум 1-2 запроса в секунду должно проходить, если запрашивать у блока, а если подслушивать, тот тут все от блока зависит. Вы же понимаете, что для своих целей внутри ABS получает данные напрямую с датчика, и в состоянии определить пропущенный сегмент на задающем диске а частота опроса в милисекндундах.

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

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

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.