d-stream

да
да

дергать таймером например

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

Во всех остальных случаях ситуации "два выхода, один вход" и т.п. - достаточно регулярная ситуация.

Чуть облегчает картину, если есть разделение событий входа и выхода...

Ну а так - раздолье безопасникам, кадровикам и прочим вахтерам:
по каждому сотруднику дневные события классифицируются на корректные - число входов совпадает с числом выходов и отсутствуют комбинации вход-вход и выход-выход и некорректные
по корректным автоматически считается "трудовая дисциплина", по некорректным - кто-то из вахтеров втыкает в некорректный лог, смотрит записи, пытает сотрудника и например удаляет лишний вход из-за двойного махания картой -> лог по сотруднику становится корректным...

В общем:
- первый уровень выбор 100% корректных выборок сотрудник-день
- автокоррекция очевидных некорректностей типа два входа подряд в течение минуты
- ручная коррекция остального

ну а дальше снюхивать это с табелями, потом зазоры-допуски на опоздания до 3 минут например, вариации допустимости сдвигов перерывов на обед и как именно трактовать (нарушение или нет) ранний на 3 минуты уход на обед, но возврат на 15 минут раньше и засчитывать ли в рабочее время то что сотрудник пришел на час раньше, а ушел на час позже и не ходил на обед))))))

А потом все это сломается об круглосуточную работу предприятия где день и смена несколько не совпадают)

p.s. без оконных функций такое считать тяжко

Собственно если не "сразу", то стоит ровно по шагам исходное-группировка - получившееся-группировка и так далее.

Плюс стоит ловить компромисс между читабельностью и производительностью. Чтобы не получалось как с регулярными выражениями, которые через день-два после написания уже нечитабельны... (привет от полной регулярки проверки email по rfc на пяток страниц)

Можно порыть в сторону вкладки "L7" в firewall
но не думаю что будет весело микротиковскими мозгами лопатить регэкспы для всех пакетов

Ну вообще зачастую для такого используют google protobuf

Собственно говоря автовыбор в 99% случаев - вполне достаточное условие.
Ну а использование дискретной карты чем плохо? Только бОльшим потреблением? Но подключенный стационарный монитор как бы намекает на использование стационарно и не от аккумуляторов.
Да еще вероятно разрешение и частота кадров у монитора огого - его вообще тянет встроенная?

Гм... чтобы не сравнивать теплое с мягким - стоит поискать маршрутизатор, которые умеет порты в LACP например. И удивиться его цене.

Ну наверное стоит погуглить про ELM327 (как самый популярный конвертер интерфейсов)
Вкратце со стороны компьютера он выглядит com портом, а с другой умеет договориться с шиной авто о скоростях и протоколах (их там много). Ну а потом собственно можно например зацепившись любым терминалом (winterm к примеру) можно и покомандовать посылая в него (набирая ручками прям) AT команды
АТ Z
AT SP 0
01 05
и в ответ получить кучку циферок про температуру охлаждающей жидкости

потом нагуглить общие "стандартизированные" расшифровки OBD PID кодов

потом нарыть россыпи хитростей vendor specific PID

ну и собственно дальше - хоть делать даже больше чем умеют дилеры дилерскими сканерами

p/s/ где-то на середине может попадется hobdrive - там народ много нарыл интересного

p/p/s а если любится визуализм и есть лень - можно с canny поиграться)

поставить в дом комп

Планирую воткнуть всё в 19" форм-фактор

Стоит начать с того, что все рэковое оборудование в силу заточки под работу в плотной набивке в шкафу реализует эффективность охлаждения производительностью вентиляторов.
То бишь 1u сервер в режимах перезагрузок и хороших нагрузок звучит примерно как хороший бытовой пылесос на максимальной мощности. И так же как пылесос сосет пыль. Если нет бытового нулевого этажа с хорошей звукоизоляцией - все это будет не очень весело. Бывают конечно "тихие" серверы, но лишь за счет холодных и унылых процессоров.

Да и rack - это так или иначе миниатюризация с вытекающими ценниками...

Уж лучше подумать о двух "коробках" - нечто на пассивном охлаждении под круглосуточные задачи средней производительности и просто компьютер/ноутбук для поработать.

И что будет? Ну покажет канал клиент-провайдер 100500 гигабит/сек, а у провайдера на мир один 100mb/s канал на всех клиентов

Разве что уличать провайдера в жульничестве прикладывая два спидтеста до него и чуть дальше...

p.s. типа "родное" в микротике - Bandwith test к BTest Server (меню Tools)

Я бы расположил по "приличности" примерно так:
1. RDS Gateway и/или vpn по вкусу (anyconnect, ipsec+l2tp и т.п.)
2. vpn по вкусу (anyconnect, ipsec+l2tp и т.п.)

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

Вот последним можно воспользоваться:
делаем правила дропа и занесения в блэклист обращения к типичным, но не задействованым портам (telnet, ftp, ssh, sql, mysql, sip и тп)

в итоге бот сунулся в порт из списка - не успев получить ответ дропнулся и попал в список и больше ему нет ответа даже с "правильных" портов.

На микротике - это собственно две строки:
input правило если src addr в блэклисте
input правило с действием add src to list - помещать в блэклист

у меня на этой сладкой палочке со сроком очистки 10 дней висит порядка 2-4 тысяч адресов

p.s. главное родной rdp в правила не подсовывать, а то одна ошибка, забыв указать порт и отдых)

что за диалект?
в MS SQL либо "GO" если пачка, либо ничего не надо

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

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