подключаете к проекту на С++ любую библиотеку, которая умеет ставить хуки на функции. Например, minhook или Detours. Инжектите эту длл в необходимый процесс, и в перехваченном теле функций send/recv или sendto/recvfrom меняете трафик, как вам надо.
AleexF: Ну описал же уже, утилита вам всё покажет, все зависимости, рекурсивные зависимости зависимостей, и т. д. Скорее всего, у вас не хватает рантаймовых библиотек от Mingw
CityCat4: Что работает проброс, это без сомнений.
У меня вся работа происходит в виртуалках, игры в виртуалке, распаковка малвари в виртуалке, что-то ещё в виртуалке. Линуксы, винды, маки. А хост стоит себе с kvm и тонким lvm, и не жалуется.
С пробросом есть только две проблемы: HTML5 видео в хроме имеет рассинхрон с нвидиевскими виндовыми драйверами, звук начинает опережать видео через 10-15 минут просмотра. И вторая: иопсы на диске в виндовой виртуалке падают где-то в 4 раза. Благо диск серверный с 600к нативных иопсов, в виртуалке где-то 150к, в принципе, хватает. В линуксах всё летает, никаких просадок производительности не ощущал вообще.
Спайс тоже отлично работает. Когда проброшена видео-железка в какую-то основную систему, то могу стартануть для работы ещё десяток виртуалок со спайсом удалённо, и хоть с другой виртуалки к ним коннектиться, хоть с хоста, хоть с марса. всё работает.
Если сервер именно железный, а не VPS, то пробросить видео не проблема. Единственное, что Intel GVT поддерживается только с E3 v4, поэтому на v3 придётся пробрасывать целиком всю шину pci-e.
Вадим Чопоров: Ну, я просто описал то, что встретил по работе на собственном опыте. Когда на гигабитном линке скорость даже до 100 мегабит доходила редко. Да каком там линке, на ЛОКАЛХОСТЕ она была такой же, когда запускаешь две одинаковые копии, когда локальный сокет вообще в ядре маппит адреса, даже без копирования. Должно всё моментально передаваться, но, что было, то было. Было это 3 года назад, сейчас может что-то изменилось, но в то время писал разработчикам, а они в упор не признавали это багом, хотя, подобные баги в трекере были открыты давным давно. Те ссылались на какую-то мифическую перебалансировку дерева, по которому отдавался приоритет пирам, файлам, чанкам.
В тоге нашли единственный клиент -- rtorrent, который выжимал более-менее честный канал. Да и то, по "историческим" причинам, перейти безболезненно на него не смогли.
Так что, как вы сказали, кому верить, вопрос сугубо личный и философский =))
К тому же, в современных реалиях скорость подключения не значит практически ничего. Надо менять сами протоколы -- динозавров TCP с UDP заменить на SCTP, хотя бы. HTTP вроде пытаются что-то там оптимизировать. А пока что сайты будут одинаково открываться сайт хоть на 20 мегабитах, хоть на 1000. Не видел ещё ни одного домашнего пользователя, которому бы 50 мегабит было мало для домашних задач.
Вадим Чопоров: Во-первых, BitTorrent использует в качестве транспорта протокол UDP. Этот протокол не имеет никаких встроенных механизмов управления потоком, как миллион различных реализаций Congestion Control у TCP, например. Т. е. стоит лишь чуть "переборщить" с рейтом пакетов, как они начнут улетать в чёрную дыру. Соответственно, на разработчика полностью ложится ответственность на реализацию этого самого Congestion Control. Достаточно опробовать разные реализации протокола торрентов, и можно заметить очень большой разброс скорости и методов её контроля.
По работе пришлось в своё время изучить все существующие реализации протокола. Так вот, из полутора десятков, адекватный Congestion Control имели на тот момент (3 года назад), всего 2(!) клиента. Т. о. есть гигабитная п2п сеть, раздаются файлы по нескольку терабайт, и только 2 из, примерно, 10-15-ти опробованных реализаций, смогли выжать этот несчастный гигабит, что говорит о довольно сомнительном понимании этих самых алгоритмов разработчиками.
Во-вторых, даже скорость они отображают слишком апроксимировано, за какой-то длительный промежуток времени. Например, закачка может уже закончиться, а скорость ещё в течение длительного времени показывается ненулевая.
Либо, есть такая процедура в протоколе, как "душить пира", т. е. временно прекращать передачу с ним. И есть реализации, которые сначала наберут кучу пиров, потом начинают их душить по каким-то своим мудрёным правилам, при этом полезная нагрузка на протокол резко падает, и какую скорость при этом будет показывать клиент, думаю, не знают даже его разработчики.
А, уж про отбор пиров и коннект к ним, и говорить нечего, там всё очень нестабильно, если пиров не 500, хотя бы. Из них стабильных наберётся от силы несколько десятков.
Например, сам использую клиент Tixati, при тарифе провайдера в 50 мегабит, он может без проблем показать 80 и выше, при том, что локальных пиров в принципе у данного провайдера быть не может. В это же время Speedtest покажет 48-50 мегабит.
Speedtest имеет специальные серверы, с огромной пропускной способностью. Вам и не нужно выбирать какой-то удалённый сервер, вы должны выбрать БЛИЖАЙШИЙ, чтобы показалась именно ВАША пропускная способность после шлюза-шейпера, а не каких-то пограничных шлюзов и кривых маршрутов, на которые ваш провайдер НИКАК не может влиять. К тому же, спидтест использует протокол TCP, который за 40 лет уже отлично протестирован и, хоть и имеет устаревшие вещи, но он более, чем стабилен на стабильном канале.
danij_com: Не понимаю, о чём вы.
Есть сайт en.cppreference.com, там находится практически официальная документация языка.
В круглых скобках передаются аргументы функции, в фигурных -- тело функции. Если фигурные вложены в функцию, как у вас, то это создаёт отдельный блок времени жизни на стеке, который очищается при выходе из блока.
Верно записана функция или нет, определяет компилятор. Если ошибок компиляции нет, значит верно. Но дальше идёт процесс линковки, который все скомпилированные объектные файлы запихивает в один исполняемый файл. На этапе линковки проверяются заголовки и сигнатуры функций, если они не совпадают, отсутствуют или повторяются несколько раз в разных объектных файлах, линкер выдаст ошибку.
Гуглите ваши ошибки линкера на MSDN и читайте в чём проблема.
"Хех, мне стабильность нужна железобетонная. Как у скайпа и аськи."
о_О
у скайпа стабильность? вы с Марса что ли? когда отправленное сегодня утром сообщение, доходит до адресата завтра вечером, это нихрена не стабильность, по-моему...
А если по делу, зачем вам несколько тредов в вашем случае? Если ваша система, как вы пишете, действительно сложная, используйте асинхронные сокеты, единственный тред и очередь сообщений; намного меньше геморроя получите. Блокирующие сокеты на сложной системе -- путь в никуда, и тормоза, растущие в геометрической прогрессии от количества подключений.
Т. е., по вашему, когда вы "просто выбираете диск", boot manager не используется?
Он точно так же загружается, просто он жёстко прописан в первый физический сектор вашего накопителя. Поэтому, в legacy-режиме выбирать просто нечего, т. к. на один диск может быть только один boot manager. Соответственно, выбор тут не имеет смысла.
А в режиме загрузки EFI, boot manager находится на определённым образом сконфигурированном диске, в виде простых исполняемых файлов в формате PE32/COFF. Этих файлов могут быть сотни. Соответственно, чтобы знать, какой из них грузить, его путь и параметры прописываются в nvram биоса. Вот этот Windows Boot Manager и есть тот самый файл, прописанный в энергонезависимую память. Вы можете его переименовать и написать, что душе угодно.
Опять же, это не решение проблемы. Оно может точно так же взять и поломаться на другом файле от другого символа, локали, кодировки, и т.п. Нужно переписать с нуля, не используя строки вообще. Читать нужно байты в вектор char'ов, а не строк. Строки здесь никаким боком не подходят.
Избавиться от лишних символов можно только использовав для задачи те инструменты, которые для неё предназначаются.
А там ничего сложного. Просто запускаете командой `tmux`, появляется точно такая же консоль, просто в сессии, которая контролируется внешним процессом. Соответственно, если происходит внезапный обрыв соединения, можно подключиться снова и командой `tmux attach` попасть в ту же самую сессию, с теми же запущенными командами и консолями. Отключиться -- комбинацией Ctrl-B D.
При этом, можно открывать ещё одну консоль прямо в этой же ssh-сессии, без создания новой. Комбинация Ctrl-B C. Можно скроллить по истории, если эмулятор её не поддерживает -- Ctrl-B [. Лучше сразу привыкнуть к этому, там всего 2-3 комбинации надо знать, зато потом будет очень удобно работать.
Этим комментарием ты показываешь, что ничего до сих пор не понимаешь, к сожалению.
Почему ты разделяешь низкоуровневое программирование и движки? Хороших движков не бывает без низкого уровня. В любом случае придётся в него вникнуться, если не хочешь писать всю жизнь тетрисы на Юнити размером в 100 мегабайт.
Переход с движка на движок не требует никаких полгода. За полгода можно научиться управлять коммерческим тяжёлым авиалайнером. С хорошим пониманием основ максимум 2-3 недели нужно будет, чтобы перейти с одного движка на другой.
Повторюсь: учи ОСНОВЫ. Понимая их, не будет составлять никакого труда переключение между движками.
Движок -- это ИНСТРУМЕНТ. Как молоток -- умея забивать гвозди ты не сможешь построить дом с нуля. Но, если изучишь основы архитектуры, сопромат, и прочее, то гвозди сможешь забивать хоть сапогом.
Ну, даже STL многие не любят, я в том числе. А если устраивает, то буст стоит использовать только потому, что много чего из него потенциально может перекочевать в STL. А современный Asio вообще не требует никаких зависимостей, насколько я помню, откуда у вас набралось их аж 20 штук?
Нужно выносить его в Precompiled Header. Вообще, всё, что часто используется в проекте и редко изменятся, можно туда вынести. Он скомпилируется один раз и больше не будет пересобираться, если его не изменять.
