Дмитрий

Две самые популярные библиотеки:
Boost.Asio
и
POCO::Network.

POCO имеет реализацию вебсокетов.

Ещё есть такая штука, как "отвал" чипа. Когда чип посажен на некачественный припой, который рассыхается и трескается от температурного режима.
Не знаю, как с современным железом, но прошлые поколения с завидной регулярностью отваливались через какое-то время.

У вас существует недопонимание конвеера отрисовки/композитинга/серверов графических элементов. "opengl/vulkan" и "xlib" это совершенно разные уровни абстракции интерфейса. Они часто работают вместе и дополняют друг друга. Можно работать с контроллами через xlib и при этом рисовать это всё через OpenGL.

Вообще, с системами отрисовки графических элементов, различными уровнями абстракций сейчас такой дичайший зоопарк творится, даже сами разработчики порой уже путают эти уровни, впихивают невпихуемое туда, где его быть не должно, потом переписывают всё с нуля, старые костыли оставляют для совместимости, и т. д. Поэтому, крайне не советую начинать это неблагодарное дело, ибо не закончите никогда. Возьмитесь лучше за что-то попроще, напишите биндинги для GTK или Qt, например, если уж так нравятся гуи.

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

Далее, там используется процедурное генерирование. Т. е. текстуры, звуки, эффекты генерируются по формулам, каким-то шаблонам, фракталам, и т. д.

Всё это, по сути, спорт, состязание демо-групп. Реальные вещи на этом делать слишком долго и затратно. Но в плане теории, можно хорошо подтянуться. Поковыряйте исходники движка, на котором написан кригер, они открыты, но довольно устарели уже.

Для реальных вещей, начните учить, например, OpenGL 3.2+, шейдеры, различные технологии, типа abmient occlusion, post processing effects.

А 40 мегабайт планка... это МНОГО. Если учить чистое графическое АПИ, и ничего лишнего не писать, у вас будет всё весить сотни килобайт. Но, опять же, это всё необходимо только для изучения основ и понимания, как оно всё там работает. Для реального продакшена или даже прототипирования лучше возьмите попсовый движок, тот же юнити или анрил. Будет и проще, и быстрее, и удобнее. Ибо, мобильные видеоадаптеры это костыль-driven development. Обычно видео-драйверы там ОЧЕНЬ сырые, ОЧЕНЬ баганые, их реализации графических апи могут абсолютно не соответствовать стандарту. То, что у вас запустилось на Mali, может совершенно не работать на PowerVR или другом чипе. Поэтому не советую привязываться к низкому уровню в мобильной разработке, берите уже проверенный временем движок, в котором решена большая часть этих проблем, и костыли уже расставлены на своих местах. Иначе, будете биться с косяками производителей видеочипов, а не работать с графикой.

Гуглите паттерн publisher-subscriber.

А на какой девайс зацеплены диски?
Если на virtio-blk, то можно попробовать закинуть на virtio-scsi. Может trim у ссдшника не срабатывает и засирает скорость? virtio-scsi поддерживает его, в отличие от virtio-blk.

Отдельный поток выделен ли для io, и какой тип используется: threads или native? Ещё можно поиграться с количеством хардварных io-очередей.

Ну, а на крайняк попробуй vhost-scsi. С ним, по тестам, вроде, какие-то космические иопсы можно раскрутить.

Как уже сказали в комментах, открывайте с флагом binary. Строки -- это строки, а двоичные данные -- двоичные данные ©Кэп. Каждая функция предназначена для своей задачи, и не стоит её использовать для других. Если ваш пример иногда работает, а иногда нет, это заслуга только рака, который иногда свистит на горе, а иногда ленится. Это во-первых.

Во-вторых, в C++ нет стандартных средств для поиска в бинарных файлах. Придётся писать свою функцию, либо просто скопипастить со StackOverflow, там таких вопросов миллионы. Реализация давно уже написана за вас.

Подсказка: гуглите реализацию функции memmem().

1. Берётся сначала анализатор исполняемых файлов. Там нужно посмотреть, защищён ли бинарник каким-то алгоритмом, запакован ли, зашифрован?
   
2. Если защищён, то нужно снять защиту. Для этого нужно знать реверс-инжиниринг и тонкости работы операционной системы. Обычно, защиты снимаются в модифицированных виртуальных машинах. Ну, или руками ковырять можно, но это очень долго.
   
3. После снятия защиты, нужно расчехлять дизассемблер, отладчик, можно, опять же, пропатчить виртуалку под свои требования. По опыту скажу, что реверс и эталонная реализация простой библиотеки АПИ с 4-5 сотнями функций занимает около двух месяцев, в зависимости от опыта. Если опыта нет, можно и на полгода засесть.
   
4. Ещё один важный момент: игра может детектить доступ с неоригинального клиента и банить. Банить может как просто аккаунт, так и по идентификатору железа вашего компьютера, т.е. второй аккаунт с этого железа вы уже не создадите. Это САМЫЙ сложный этап, на котором фейлятся даже мировые лидеры ботостроения. Здесь одному в принципе нереально ничего сделать. Здесь сотни человек работают, и несмотря на это бывают фейлы, как у известного бота для WoW, у которого была упущена пара байт в протоколе, которые с виду ничего не значили (всегда передавался ноль), а потом, как оказалось, это было замедленной защитой, которая внезапно "включилась" в следующем обновлении, и 50 тысяч пользователей получили баны.
   
5. Ну и, наконец, игра может содержать античит. Они обычно реализуются в виде ядерного драйвера. Соответственно, нужно знать принципы работы ядра операционной системы.
   

Грубо говоря, если вы задаёте подобные вопросы, у вас опыта нет вообще. Поэтому, если интересно, учите реверсинг, ассемблер, операционные системы. Годика должно хватить для понимания. А потом, уже зависит от того, насколько хорошо усвоили, насколько работает логика, решение нестандартных ситуаций. В игры уровня WoW одному можно даже не соваться. А что-то поменьше за 2-3 года можно раскурить, в свободное от работы время.

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

Во-вторых, нет таких книг "под компилятор". Есть различные стандарты. Из современных сейчас практически полностью реализован во многих популярных компиляторах -- С++14. С++11 реализован на 99.99% обычно.
Сначала нужно решить, какой стандарт начать изучать -- 03 или 11/14. Т. к. 14-й -- это, по сути, минорный апдейт 11-го.

Чистый С++14 без всяких там костылей и экстеншенов лучше изучать на компиляторе clang с максимальными флагами ворнингов, педантиков и т. д. Это научит отличать стандартизованный С++ от миллионов расширений и костылей, которые в него успели внести за время его развития. Да и сообщения об ошибках у клэнга на порядок адекватнее, чем наркоманские простыни неверного инстанцирования шаблонов вижуал студии.

Если работаете под виндой, советую поставить Cygwin и на него clang и, если позволяет религия, vim. Можно clion, для новичка он неплохо поможет. Лучше сразу задать параметр -std=c++14, чтоб компилировать под 14-й стандарт. Чтобы отключить всевозможные расширения и не пропускать ни одного предупреждения, нужно добавить параметры -Weverything -Werror -pedantic-errors -Wno-c++98-compat.

Ещё, советую не использовать хидеры, начинающиеся на c*, т. к. они оставлены для совместимости с чистым языком Си. Ибо, используя их, будете путать и не различать чистый Си и C++. Лучше использовать чистый STL и пространство имён std, там всё необходимое есть для начала.

Референсы и хидеры для всяких фич лучше смотреть на C++ reference, ибо там всё по стандарту расписано более-менее.

ПС Ещё, существует два холиварных направления в C++: чистый STL, который предлагает Страуструп и Ко. Там, в основном, используются "3 кита языка: контейнеры, алгоритмы и итераторы". Это типа "тру C++", который изначально придумывался. В основном сюда хорошо накладываются паттерны GoF.
Второе направление -- "Си с классами", это когда, по сути, из ООП используется только полиморфизм, да и то, не там, где нужно. Здесь обычно мешают всё подряд: и Си, и С++, и STL, и макросы, и ещё чёрт знает что. Его использует большинство тех, кто перешёл из Си в С++. Много книг так же написано в данном стиле.
Лично я рекомендовал бы на случай ООП разработки всё-таки приучать себя использовать "тру C++", ибо там есть всё, что нужно, для нормального ООП. Ну, а если хочется просто учить прикладной язык и не париться насчёт хорошего кода, то можно учить как угодно.

Работать надо в tmux или screen, и не будет таких проблем.

Установить компилятор и плагин для C/C++.

Да не слушай ты этот бред, который пишут: "То бросай, это бросай, вакансий нету, всё пропало!".
Всё есть, если есть интерес.
Учить не важно какой движок, они все используют одни и те же концепции, паттерны примерно одинаковые.

Внезапно(!), но везде есть и текстуры, и спрайты, и шейдеры. И игровой цикл даже есть!
Изучив один движок, и написав пару игрушек, потом сам поймёшь, когда стоит перейти на что-то более функциональное и удобное. Придёт осознание, каких фич не хватает, и в каких движках они есть, и т. п.

А все эти анрилы и юнити только ключевыми словами, по сути, отличаются. Ну, и общий дизайн у них чуть более удобен в плане декомпозиции кода, грамотной архитектуры. Но, пока сам не дойдёшь до необходимости использовать эту декомпозицию, ничего особо не выиграешь, только запутаешься. При переходе достаточно будет ознакомиться с паттернами Gang of Four и всё станет ясно более-менее.

ПС Знаю разработчиков Юнити, которые начинали геймдев с этого движка и в шоке от того, что кто-то программирует не мышкой. Азы оптимизации им просто недоступны, ибо они даже понятия не имеют о нижележащем уровне API. Они искренне удивляются, как это знать чистый OpenGL и писать всё самому, а разве так можно? Точно так же, кстати, удивляются многие кодеры на плюсах: "А зачем мне знать ассемблер? Я с ним не сталкиваюсь никогда..."

ППС Вот ещё можно почитать чуть позже, самая крутая книга по геймдеву, которую я видел. Правда, она для тех, уже, кто нашёл в своих движках какие-то изъяны и ищет решения. Но и основы игрового цикла есть там, обработки ввода, множество примеров декомпозиции.

А уж, если хочется просто изучить полезный скилл зарабатывания денег и как зомби рубить бабки, то тут, как описали выше, 2 варианта по сути: Unity (C#), Unreal (C++). По ним вакансий немерено.

Он предназначен для вывода со встроенного в чипсет\процессор видео. С дискретной видеокарты через него вывести нельзя.

Precompiled headers, же! И всё влёт собирается.
Ну, или для совсем тяжёлых случаев, можно юзать Ниндзю.

А писать однозначно на бусте.

Тут много подробной инфы.

Наличие у IPv6 миллиардов адресов никак не означает, что у одного юзера будет только один адрес или даже префикс.
Механизм раздачи адресов у IPv6 в разы сложнее и объёмнее, чем в IPv4. На текущий момент, одному пользователю рекомендуется выделять /64 префикс, а это ни много, ни мало — около 300 миллионов адресов, что, мягко говоря, сводит на "нет" вашу идею.

Как-то так

Как и в любом другом дистрибутиве:

# iptables -A TCP -p tcp --dport 8080 -j ACCEPT

Либо, сервер запускается не на ANY, а на локалхосте.