Вообще обычно (в других ОС) это делается так - создается разрешающее правило с вашими условиями, и за ним создается запрещающее правило для этой программы на все. Если срабатывает первое правило, то программа идет в интернет, до запрещающего правила дело уже не доходит. Если не срабатывает, то следующим правилом выход блокируется.
Обычно правила фаерволов строго упорядочены, в винде же порядок проверки правил странный и четко не определенный.
Поэтому стандартный подход не прокатит.
По умолчанию в виндовом брандмауэре исходящий трафик разрешен. Измените эту настройку - запретите исходящий трафик по умолчанию. Эта настройка есть для каждого профиля брандмауэра.
Ну и дальше вам надо будет аккуратно настроить исходящие правила. По 80 порту уже не выпускайте всех подряд, а только кого надо и куда надо, для этого нужно будет изменить стандартное правило и по необходимости добавить новых.
Подозреваю, что такая схема может вызвать массу неудобств на первых порах, т.к. возможно отвалятся разнообразные виндовые (и не только) службы.
Это не контроллер диска так себя ведет - винда (да и любая другая ОС).
Ну вот, например, у вас разваливается диск, ОС или софту приспичило что-нибудь записать на него и тут во время записи попадается сбойный сектор. Стандартное поведение в этом случае: сделать несколько попыток записи, если запись все таки не удалась в этот сектор, пометить его как сбойный, записать блок в другое место, как-то так примерно. Т.к. повторные попытки записи идут в тот же сбойный блок, то диск при этом работает не адекватно и медленно. Пока все это продолжается другой софт то же не дремлет и в итоге выстраивается очередь с запросами к диску. Отсюда тормоза и загрузка диска на 100%. И кстати - диск не многозадачное устройство - в один момент времени выполняет одну операцию, к тому же еще и медленный сам по себе.
С ВМ все несколько проще, т.к. это точно не железо.
Для начала обновите vmware-tools.
Чтоб исключить, что это не гипервизор, проверьте журналы ESXi - может это он гостя загосил так хардкорно. Но журналы ESXi лучше смотреть сразу после события, иначе можно ничего не увидеть, т.к. он их ротирует.
А дальше проверяйте софт, как писал выше.
Денис _______________: Мне так же приходилось работать с хламом в свое время, поэтому про видео точно знаю - пень 4 физически не способен обработать в реальном времени поток HD видео (да и не HD, а просто разрешение больше чем 320).
Но т.к. дело было в офисе конторы и видео не требовалось, то остальное было терпимо - компы Pentium 4, 1-2 Гб ОЗУ + WinXP + MS Office 2003 или 2000. Но хорошо, что это кончилось, т.к. народ, конечно, был не очень счастлив от такой работы техники.
И админить этот раритет было тем еще удовольствием, например, на некоторых раб.местах приходилось отказываться от антивируса и обрубать интернет, т.к. антивирус потреблял все ресурсы проца, а для полезной нагрузки уже ничего не оставалось. Антивирус то приходилось использовать более-менее современный, а они все прожорливые до ресурсов.
Денис _______________: Собственно я на видео акцентировал, потому что ютуб указан первым в списке сайтов. Думаю про ютуб на этом компе можно забыть.
Остальное - нужно смотреть, возможно, если запастись терпением, то со временем привыкните :-)
Но вообще для этого компа - консольный линукс самое оно.
Денис _______________: Да хоть М, хоть без М.
Даже если с 1Гб ОЗУ еще хоть как-то можно смириться (как-то ставил Win7 на комп с 1Гб и ничего жил, но проц там был по современней), то проц нынешние потребности уже не тянет. К тому же нет смысла туда ставить SSD - не HDD будет узкое место.
Александр Момот: Базовое отличие в том что в многопоточном приложении используются блокирующие вызовы ввода/вывода (т.е. приложение ждет, когда закончится операция ввода/вывода), в асинхронном - не блокирующие (возврат из операции ввода/вывода происходит сразу же, до реального завершения операции).
Соответственно сложность в разработке асинхронных приложений в том, что нужно так построить внутреннюю архитектуру приложения, что бы оно после вызова операции ввода/вывода могло в дальнейшем проверить состояние операции, предпринять какие-то действия, при ошибочном завершении, если нужно - повторить операцию и т.п., ну и попутно выполнить какие-то полезные действия не связанные с вводом/выводом.
В многопоточном приложении таких проблем нет, т.к. результат операции сразу известен и можно сразу же отреагировать.
Плюсы от использования асинхронного ввода/вывода в том, что нет накладных расходов на организацию и управление потоками. Когда у вас в приложении 1-10 потоков, то на это можно наплевать и не заморачиваться, а когда 1000 потоков, то уже есть смысл задуматься про асинхронный ввод/вывод.
И еще - асинхронный ввод/вывод есть смысл использовать если основная нагрузка в приложении именно на вводе/выводе. Т.е. когда операции ввода/вывода становятся узким местом в приложении и начинают тормозить остальной процесс.
Т.к. система не загружается, то вряд ли этот рецепт поможет.
Для начала попробуйте средства диагностики и восстановления.
Лично мне это ни разу не помогало, но игнорировать не стоит.
Если не поможет - переустановка виндов.
Часто бывает, что сам батник называют start.bat и из-за этого вместо системной команды start выполняется батник в цикле. Выглядеть это может по разному.
Проверяйте пути, возможно надо указать полный путь до вашего jar.
Попробуйте выполнить start ... просто из консоли, без батника.
Запускается однозначно через start, а почему не срабатывает - нужно разбираться.
start /? в помощь.
Странно, конечно. Ошибка говорит о том, что утилита не смогла имя хоста или сервиса перевести в адрес/порт. Это и надо проверять.
Сравните файлы /etc/services на убунте и минте, смотрите что у них на 3389/tcp весит. Судя по всему на минте нет записи, а freerdp, возможно хочет чтоб она была. Если записи нет - добавьте так же как в убунте.
Ну или выгнать того кто сидит там.
Когда виндовый сервер не лицензирован для RDS, то он позволяет подключать 2 удаленных соединения (если не ошибаюсь).
А лицензии то у вас есть? А то чем вы собираетесь лицензировать его?
Собственно, в винде многие администраторские утилиты позволяют подключаться удаленно. Так что часто и заходить на сервер удаленно не нужно.
В ваше ПО добавить описание команд винды? В лицензии к чему это написано?
Документация является частью ПО, если вы ее предоставляете. Там же в лицензии смотрите, что подразумевается под "использованием". Думаю ссылка на описание команды или даже само описание, не является использованием.
Ну тут такой момент: в современных версиях виндоус и RDP (начиная от Win7, про Висту не в курсе) вы вводите логин пароль еще до фактического подключения к удаленной системе, а клиентская винда не знает какие пользователи есть на удаленной системе, поэтому выдает последнего пользователя, которым логинились и возможность ввести другого пользователя.
В принципе, если на сервере разрешить подключение старыми клиентами (выключить галку в настройках про проверку подлинности на уровне сети (в Вин7 по моему не много по другому это выглядит)) и поставить на клиентскую машину старый клиент ( от Windows XP ), то вы получите то что хотите, т.е. клиент сразу будет подключаться к удаленной системе (без локального ввода логина/пароля), а там уже стандартный экран выбора пользователей и т.п.
На счет клиента - возможно не нужно ставить старый клиент, попробуйте поискать параметры реестра, которые делают приоритетнее подключение без проверки подлинности на уровне сети.
Но мой совет - не делайте этого - современные версии RDP гораздо безопаснее и надежнее.
PS: в групповых политиках gpedit.msc - Конфигурация компьютера - Административные шаблоны - Компоненты Windows - Службы удаленных рабочих столов - Клиент подключения ... Есть параметр: Запрашивать учетные данные на клиентском компьютере.
Это как раз то что вам надо. У меня Win10, есть ли это в Вин7 нет возможности проверить. Но это, скорее всего, не отменяет отключения проверки на уровне сети на сервере.
Я это и имел ввиду, только в свой проект нет нужды копировать - заведите отдельный проект для библиотеки, подключите туда все ее исходники и смотрите, тут же можно и собирать со своими настройками компилятора.
Но обычно для библиотечных функций нет нужды в подобном дереве, гораздо важнее наличие нормальной документации. Хотя иногда требуется и в исходники заглянуть.
Обычно правила фаерволов строго упорядочены, в винде же порядок проверки правил странный и четко не определенный.
Поэтому стандартный подход не прокатит.
По умолчанию в виндовом брандмауэре исходящий трафик разрешен. Измените эту настройку - запретите исходящий трафик по умолчанию. Эта настройка есть для каждого профиля брандмауэра.
Ну и дальше вам надо будет аккуратно настроить исходящие правила. По 80 порту уже не выпускайте всех подряд, а только кого надо и куда надо, для этого нужно будет изменить стандартное правило и по необходимости добавить новых.
Подозреваю, что такая схема может вызвать массу неудобств на первых порах, т.к. возможно отвалятся разнообразные виндовые (и не только) службы.