nApoBo3

1. Вы не совсем понимаете, что такое потеря 50% пакетов. В вашем гипотетическом сценарии, это потеря каждого второго пакета, но в реальной жизни это не так.
Удвоением кол-ва пакетов вы проблему усугубите.
2. И да, эту проблему можно для части протоколов решить программно, но не уверен, что такие решения есть в готовом виде. Вам потребуется реализовать собственный аналог tcp для ситуации с большой потерей пакетов, работающий поверх udp или более низких протоколов, плюс промежуточный прокси.
Возможно подобные решения есть, я про подобные вещи когда-то читал для нефтяники на спутниковых каналах, там были свои протоколы, для ускорения передачи данных, поскольку tcp плохо подходит для каналов с большими задержками.

Насколько я помню ethernet не гарантирую доставку.

Если вы vlan настраиваете на bridge, вам надо в настройки моста настроить target и untarget порты.

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

Похоже на телеметрию или попытку входа в Майкрософт аккаунт.
ИМХО самый простой вариант изменить механизм блокировки интернета, вероятно у вас блокировка идёт через drop пакетов. Можно её сделать, через reject, возможно это решит проблему.
Второй вариант, зарубить узлы на dns, win server может разным клиентам отдавать разные ответы.

Насколько я помню windows professional поддерживает максимум 20 конкурентных подключений.

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

https://docs.microsoft.com/ru-ru/azure/active-dire...

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

Xeon v3 как процессор сильно слабее современных cpu при том же кол-ве ядер и частоте.
https://3dnews.ru/1065050/obzor-xeon-e52640-v3-e52...
Но не следует забывать и об особенностях многопоточность, не исключено, что ваше приложение с ростом кол-ва потоков становится медленнее на каждый поток.
Плюс, возможно у вас xeon работал на достаточно низкой частоте, поскольку были загружены все ядра.

Это древний холивар.

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

Например gns3.

Вам следует использовать http 401, приложение должно само знать куда ходить за токенами. Поместив эти информацию в веб сервис, вы создаёте лишнюю зависимость фактически отказываясь от плюсов jwt.

ИМХО смена логина не должна инвалидировать токен.

Меняйте частоту на ту где нет rd. Насколько я помню rd на 116-132 каналах.

Выборка из таблицы с сортировкой по id, вставка в таблицу в автоинериментом.

Я в таких "непонятных" случаях начинаю с проверки счётчиков ошибок на портах коммутатора. Если там все ок. Проверяю dns. Если и тут проблем нет. Запускаю несколько параллельных пингов, изнутри, до маршрутизатора, если есть возможность до ещё одного устройства в сети, до шлюза за маршрутизатором, до крупного публичного ресурса, и аналогично снаружи, до маршрутизатора, до коммутатора.
Чаще всего этого достаточно, чтобы понять где именно находится проблема.
Можно даже готовые скрипты для этого написать, которые логи в удобном виде в файл положат.

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

нет