res2001

Как только ты дашь доступ из интернета к этому приложению по советам выше, приложение сразу же начнут ломать.
Если приложение изначально не создавалось для работы в интернете, то скорее всего рано или поздно в нем найдут баг и сломают. А дальше может быть что угодно: внедрение шифровальщика/вымогатора, использование твоего компа в бот сети и т.п. не приятные вещи.

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

Надо "разлогиниться" и залогинится пользователем 2.

lololoshka_1991, Если совсем просто, то пиши исходники в кодировке cp866. Кодировка консоли по умолчанию как раз такая в русской винде. Но в этом случае и запускай программу руками из консоли, т.к. тот же MSVS может менять кодировку консоли при запуске программы из него.
Так же кодировка консоли может меняться и командой в самой консоли. Например: chcp 1251
В винде по умолчанию может быть 3 варианта кодировок с поддержкой кириллицы: cp866, cp1251, UTF8.

Что бы сделать программу независимой от кодировки консоли, то придется заморочиться. Готового решения не встречал. По уму надо делать так: пишем исходники в UTF8, в программе узнаем кодировку консоли (WinAPI позволяет это делать), перед выводом весь текст перекодируем в кодировку консоли, после ввода весь ввод перекодируем в UTF8. Внутри программы работаем только с UTF8. Для хранения строк в программе использовать wchar_t, wstring и т.п. Функции перекодирования в WinAPI так же присутствуют.

Кстати в плюсах есть метод std::basic_ios.imbue(), который позволяет задавать кодировку потока. Можно попробовать поиграть с этим. Но вообще менять кодировку консоли из программы - плохо, т.к. пользователь консольной программы может ждать ответ от запускаемой программы в конкретной кодировке. Это широко используется при написании батников и т.п. скриптов. Например большая часть виндовых команд корректно выводит текст не зависимо от того какая кодировка в консоли. Тот же dir, например.

Есть специализированная команда head, с помощью которой можно вывести N первых строк файла:

head -q -n 10 file.txt >file_new.txt
rm file.txt
mv file_new.txt file.txt

Обычно, когда вы арендуете целиком подсеть, то у вас есть эта подсеть + еще какой-то белый адрес не из этой подсети, который выдается оператором для внешнего интерфейса и через который будет происходить маршрутизация вашей подсети оператором. Соответственно на шлюз на внешний интерфейс вешается этот отдельный адрес, а в локальной сети назначаете адреса из подсети (статически или через DHCP). Т.е. все то же самое, как и при использовании серых адресов, только в случае с серыми адресами подсети их вам никто не выдает (выбираете любой диапазон по собственному усмотрению) и вы обязаны использовать NAT для выхода в интернет.

Если же у вас только подсеть, то используйте ответ Andrey Barbolin

sizeof(chars) в результате дает размер указателя (8 - для x64 систем, 4 - для х32 систем), а не размер строки. Чтоб получить размер строки надо его передать в функцию (str.size()) или вызвать strlen уже внутри.
sizeof(*chars) всегда в результате равен 1, т.к. размер char по стандарту 1 байт.

Вам не нужно 2 цикла. Я так понимаю, вы хотели различать четное и не четное количество символов в строке.
Но если количество элементов четное, то мы должны обработать все элементы массива при этом количество итераций цикла будет strlen(chars)/2. А если количество элементов не четное, то центральный элемент мы пропускаем и количество итераций будет то же strlen(chars)/2, за счет того, что тут используется целочисленное деление и остаток от деления отбрасывается.

В функцию можно передавать ссылку на объект string, а не сырой массив (c_str()). string позволяет обращаться на прямую к каждому символу отдельно с помощью операции индексации (str[i], так же как и сырые массивы). При этом возвращать что-либо из функции не нужно, т.к. вы будете манипулировать непосредственно данными самого объекта и все изменения будут видны в main.

Просто считайте количество открывающих скобок и количество закрывающих. Причем, если на закрывающей скобке количество открывающих <= количества закрывающих, то ее не учитываем (или учитываем в ошибках закрывающих скобок), т.к. нет парной открывающей.
Ошибки по открывающим скобкам будут, если в конце количество открывающих > количества закрывающих, количество ошибок открывающих скобок в этом случае = количество открывающих - количества закрывающих.
Количество правильных скобок == количеству закрывающих (т.к. не правильные закрывающие мы не считаем).

RDP подключения можно сохранять как *.rdp файл. Заводите каталог с набором RDP файлов. Все.

На счет имени таргета посмотрите тут: https://stackoverflow.com/questions/31038963/how-d...
С каталогом, ну я бы в проекте сделал подкаталог MyDir и в нем свой cmakelists.txt с описанием таргета для библиотеки. Библиотека будет собираться в своем подкаталоге. В корневой cmakelists.txt включать подкаталог с помощью add_subdirectory(MyDir)

Что клиент подключается к серверам с разными ключами? Ну тогда надо отзывать и второй клиентский ключ.

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

Функция с переменным числом аргументов, но минимально должен присутствовать 1 - format, все остальные опционально.

443 и 80 используются веб серверами (HTTP(S)), и это TCP. Тут UDP не используется.
53 - это DNS запросы, могут быть как UDP (по умолчанию) так и TCP.

На самом деле никто не мешает использовать любой порт любому протоколу (т.е. любое приложение может открыть любой порт если он не занят и хватает прав). Но то что я привел - это стандартная практика. Другое дело, что протоколы верхнего уровня обычно жестко связаны либо с TCP либо с UDP, но бывают исключения (тот же DNS).

Можно на одну комнату один поток, тогда сокеты игроков делаете не блокирующими и используете асинхронные сетевые операции с двумя сокетами в одном потоке.
Но если уж делать сокеты не блокирующими, тогда ничего не мешает в одном потоке обрабатывать сразу несколько комнат. Обычно создают пул потоков по количеству ядер процессора и размазывают всю нагрузку по всем потокам. Но надо добиться того, чтобы обработка данных игроков в одной комнате происходила в одном же потоке, так избавитесь от разделяемых данных и не надо будет синхронизировать потоки (мьютексы и т.п.).