Алексей Черемисин

Смотрите в сторону gstreamer. Не знаю, как для шарпов, но для явы биндиги есть, сам на нем пишу audio-приложения.
И да, для шарпов тоже есть - https://gitlab.freedesktop.org/gstreamer/gstreamer...

Вот прямо отсюда начать - https://habr.com/ru/company/ruvds/blog/529832/

Для сборки есть утилита make. Рекомендую изучить, причем настоятельно!

Например на STM32. Практически любая отладочная плата подойдет, например STM32F4DISCOVERY. Кстати, там демо-прошивка как раз этулирует компьютерную мышку и мыргает диодиками.
www.st.com/en/evaluation-tools/stm32f4discovery.html

Начните с простого, с протокола RS-232, его как минимум можно смотреть осцилографом, причём - самым простым.
Далее - сделайте распределенную сеть на RS-485, введите маркеры и адресацию.
Поговорите про аналоговые модемы, потом расскажите по DSL (ADSL/HDLS).
Переходите к кодированию ТВ-сигналов, вот здесь уже можно и на телевизоре крестик рисовать через STM32 например,
Далее - технология цифровой передачи DVB-S (-C), тоже достаточно просто. Тут же помехозащищенное кодирование RS (Reed-Solomon), перемежение. Факультативом - пишем восстановление блоков данных, рассказываем про массивы RAID.
Рассказываем про параллельные линии, начиная от параллельного порта, через Centronics, SCSI-8/16, всяким шинам данных типа VME, переходим к современным протоколам работы памятью.
Дальше - коммутация, начиная от телеграфа к телефонии и заканчивая каким нибудь Infiniband и мультисервисными сетями типа ethernet 10/40Gb со всеми вытекающими.

Ну и возвращаемся к последовательным высокоскоростным линиям SATA/Ethernet/PCI-e.

По интерфейсам, начинаем с терминалов RS-232 и заканчиваем WEB, наверное, как ни парадоксально.

PS. Хорошо бы учесть специфику слушателей... Если это будущие "бухгалтеры", тогда, что я написал - для них overflow будет...

PPS. Вынесу наверх...
Увы, на мой взгляд, нельзя вот так просто объяснить как этот ftp/gopher/http/GUI работает, без хотя бы введения в "а что у нас есть такое протокол, и почему он возник..." (А возник как раз из-за симплекса и телеграфа, еще до телефона, а то и раньше, начиная с сигнальных костров и тамтамов).
Также, наверное, бестолково объяснять дизайн современных интерфейсов без истории сигнализации лампочками, технологий ввода информации (да перфокарта, клавиатура, мышь, дисплей)

Но многие говорят, что время низкоуровневого программирования прошло, сейчас только веб, C#, Java и т.д.

Весь вопрос не в том, что время прошло, а в том, где больше всего железок выпускают и строят фабрики/заводы с автоматизацией.
Что касается низкоуровнего программирования, то время совсем не прошло и специалисты требуются постоянно. Вопрос в другом, что эти специалисты практически не нужны (увы) на наших просторах. Я знаю десяток фирм, в которых есть отделы разработок (сам когда-то возглавлял такой), там специалисты нужны постоянно. Еще знаю с десяток предприятий, которые делают свои железки, там тоже нужны программисты. И всё! Если вы живете в городе-миллионнике, то работу по программированию железок вы найдете в легкую, и очень хорошо оплачиваемую, и интересную (что не всегда)!
Но если вы родились в городе с меньшим населением, задумайтесь о переезде, возможно и совсем туда.
Ну и еще немного сменились акценты, если раньше все пытались разработать свою железку, и написать под нее ПО, то теперь для подавляющего числа задач можно взять любой ПЛK и просто посадить инженегра, который на языках МЭК составит вам блок-программу.
Но тем не менее, область низкоуровневого программирования цветет и пышет.
Возможно, с выпуском отечественных CPU/SOC и нацеленностью на это нашего законодательства, ситуация как-то и будет меняться в лучшую сторону.
Ну а пока, в основном хорошо живут те, кто занимается аутсорсом ПО на чужие железки (в основном забугорные).

А вот я Таненбаума не читал. Сети можно изучить и без него, например
"Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов", Олифер & Олифер.

Интересует момент начиная от. Вот объявляем мы переменную и что происходит дальше и как дальше структуры и классы располагаются в памяти.

Все сильно зависит от используемого языка программирования, типа архитектуры, и извратов программистов, исследователей и математиков.
Рекомендую прочитать вот это, все очень понятно и в картинках - www.cs.virginia.edu/~evans/cs216/guides/x86.html

Ассемблер не нужен! Учите С!
Ассемблер нужен только в очень редких случаях, например поменять регистры при переключении контекста при разработке мультизадачной RTOS, написании критической секции IRQ до вызова обработчика или при портировании на новую платформу для заполнения таблицы таймингов, или поправить регистры при вызове C-кода. Да и во всех этих случаях все уже написано, нужно будет исправить только пару-тройку мест, да и то, если новый чип с новой архитектурой. Да, еще знание ассемблера нужно, если разработываете свой компилятор языка высокого уровня на совершенно новую архитектуру.
Во всех остальных случаях ассемблер не нужен, никогда. Так как он прекрасно генерится практически любым современным компилятором с любого языка высокого уровня.
Наверное единственное исключение, совсем уж маленькие микропроцессоры, да и здесь я бы сильно поспорил.
Времена, когда драйверы, операционки и программы писались на ассемблере, прошли безвозвратно.

Что касается рынка программирования для микропроцессоров - он огромен. Только в здании, где мы арендуем площади, с десяток фирмочек заняты разработкой собственных железок под всяко разно. Начиная от электронных замков, и заканчивая обработкой радарных данных.

Хорошо, а если я под виртуалкой буду запускать net/freebsd, windows, dos, os/2 прости господи? Увы и ах, контролировать виртуалку можно только косвенными путями, если у нас нет полного представления что гость назапускал:
- по файловой системе и/или дисковому обмену, да и то, если гость не использует криптографию на диске;
- сетевому трафику, и опять же, если гость его не шифрует, или там tor не запускает.
- конечно же можно с помощью vd-x и vd-t смотреть содержимое регистров и памяти, отлавливать всякое I/O.
Но это же все начинает напоминать игру в ревресинжиниринг кода с получением ключей доступа к какому нибудь платному приложению. Вроде бы приложение и запущено у нас в системе, только ключей требует для совего запуска. Вроде бы как и наш компухтер, а не мы хозяева-то приложения. И дебагеры вроде как можем запускать и менять регистры всякие, только хрен там...
Что-то не нравится мне такая тема диплома...
PS. Я вот тут намедни запускал Windows NT4.0 SP3 в виртуалке. Запустилось, грустное это занятие, скажу я вам... Драйверов нет, проброс старых PCI-плат - ужас. Новые не работают, драйверов нет, да и ПО их не поддерживает. Сама NT еще та девочка с косичками из фильмов Хичкока...

А зачем непосредственно в приложении это делать? Возьмите, к примеру, redis.io, в нем и храните. Там не только sortedset, но и hash и и сounters и еще кучу всего реализовано. Работает быстро, лежит в памяти, кластеризуется и шардируется.

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