Compatibility ru RU

Совместимость

ASF - это приложение C#, работающее на платформе .NET Core. Это значит, что ASF не компилируется напрямую в машинный код, который исполняется на вашем ЦП, а компилируется в код CIL, которому для работы требуется CIL-совместимая среда выполнения.

Этот подход даёт гигантское количество преимуществ, поскольку CIL платформо-независим, и поэтому ASF может запускаться на множестве доступных ОС, в частности Windows, Linux и OS X. Для этого не только не требуется эмуляция, но даже поддерживаются оптимизации под конкретную аппаратуру, такие как наборы инструкций SSE. Благодаря этому, ASF может достигать превосходной производительности и оптимальности, и при этом оставаться прекрасно совместимым и надёжным.

Это также означает что ASF не имеет особых требований к ОС, поскольку всё что он требует это работающую среду выполнения на этой ОС, а не саму ОС. Пока среда выполнения корректно исполняет код ASF, совершенно не важно, происходит ли это под ОС Windows, Linux, OS X, BSD, Sony Playstaion 4, Nintendo Wii или на вашем тостере - если под него существует**.NET Core**, на нём будет работать и ASF.

Однако, независимо от того, на чём вы запускаете ASF, вы должны убедиться что на вашей платформе установлены все предусловия для работы .NET Core. Это низкоуровневые библиотеки, необходимые для функционирования среды выполнения и ядра ASF. Вполне возможно, что некоторые (или даже все) из них у вас уже установлены.

Запуск нескольких экземпляров

ASF поддерживает запуск нескольких экземпляров программы на одной и той же машине. Эти экземпляры могут быть полностью независимы или запущены из одного и того же исполняемого файла (в этом случае вам надо запускать их с разным аргументом командной строки --path).

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

ASF будет по возможности использовать минимум обще-системных, меж-процессных взаимодействий с другими экземплярами ASF. Сюда входит проверка рабочей директории с конфигурационными файлами в сравнении с другими экземплярами, а также общие ограничители уровня процесса ядра заданные параметрами *LimiterDelay глобальной конфигурации, что обеспечит что несколько одновременно запущенных экземпляров ASF не приведут к ситуации срабатывания ограничения на частоту запросов. Что касается технической реализации — все платформы используют наш специальный механизм блокировок ASF, основанный на блокировках файлов во временной директории, в качестве которой используется C:\Users\<ВашеИмяПользователя>\AppData\Local\Temp\ASF под Windows, и /tmp/ASF под Unix.

Использование одинаковых параметров *LimiterDelay для всех запущенных экземпляров не является обязательным, они могут использовать различные значение, поскольку каждый экземпляр ASF будет добавлять собственную, заданную в конфигурационном файле, задержку до освобождения файла после его захвата. Если параметр *LimiterDelay задан равным 0, этот экземпляр ASF будет полностью игнорировать ожидание блокировки заданных ресурсов, разделяемых с другими экземплярами (которые могут потенциально поддерживать общую блокировку между собой). При установке любых других значений, ASF будет правильно синхронизироваться с любыми другими экземплярами ASF и будет ждать своей очереди, а затем снимать блокировку после заданной задержки, позволяя другим экземплярам продолжить работу.

ASF учитывает настройки WebProxy для принятия решения об использовании блокировок, то есть два экземпляра ASF, использующих разную настройку WebProxy не будут иметь общей блокировки между собой. Это сделано чтоб позволить конфигурациям с использованием WebProxy работать без излишних задержек, как ожидается от разных сетевых интерфейсов. Этого должно быть достаточно для большинства вариантов использования, однако, если ваша конфигурация специфична, например вы перенаправляете запросы самостоятельно каким-то другим образом, вы можете задать сетевую группу сами с помощью аргумента командной строки --network-group, позволяющего вам указывать группу ASF которая будет синхронизироваться с данным экземпляром. Имейте в виду, что пользовательские сетевые группы переопределяют внутреннюю группировку, а значит ASF больше не будет учитывать значение WebProxy для определения правильной группы, так как в этом случае вы полностью отвечаете за группировку.

Пакеты ASF

ASF поставляется в 2 основных вариациях - универсальный пакет и пакеты под конкретные ОС. С точки зрения функциональности они идентичны, и способны автоматически обновляться. Единственная разница в том, содержится ли там только универсальный (generic) пакет, или с ним поставляется среда выполнения под конкретную ОС.

Универсальный пакет

Универсальный (generic) пакет это платформо-независимая сборка, не включающая себя никакого машинно-ориентированного кода. Этот вариант требует чтобы в вашей ОС уже была установлена среда выполнения .NET Core требуемой версии. Все мы знаем как сложно бывает поддерживать все зависимости в актуальном состоянии, поэтому этот пакет предназначен в основном для людей, которые уже используют .NET Core и не хотят дублировать среду выполнения только для ASF, если можно использовать ту, которая уже установлена. Универсальный пакет также позволяет запустить ASF на любой платформе, для которой вы можете получить работающую реализацию среды выполнения .NET Core, независимо от того, существует ли сборка ASF под данную ОС, или нет.

Не рекомендуется использовать универсальный пакет если вы начинающий или даже продвинутый пользователь, желающий просто запустить ASF и не вдаваться в технические подробности, связанные с .NET Core. Другими словами - если вы знаете что это, можете пользоваться, иначе вам лучше взять пакет под конкретную ОС, как описано ниже.

Пакет для .NET Framework

В дополнение к универсальному пакету, описанному выше, существует также пакет generic-netf основанный на .NET Framework (а не на .NET Core). Этот пакет - устаревшая версия и оставлен для поддержки совместимости со времён ASF версии 2.x.x.x, и может быть запущен, например, с помощью Mono, чего пакет generic, основанный на .NET Core, на данный момент не позволяет.

В основном вам следует по возможности избегать использования этого пакета, поскольку большинство операционных систем прекрасно (и гораздо лучше) работают с пакетом generic, упомянутым выше. Фактически, этот пакет имеет смысл использовать только на платформах, под которые отсутствует работоспособная реализация среды выполнения .NET Core, но при этом имеется работающая реализация Mono. Примерами таких платформ могут служить linux-x86 (32-разрядный linux i386/i686), а также linux-armel (платы на базе ARMv6, например Raspberry Pi 0 & 1), для которых на сегодняшний день нет официальной работоспособной среды выполнения .NET Core.

Поскольку со временем к всё больше платформ будет поддерживаться .NET Core и всё меньше будет совместимость между .NET Framework и .NET Core, пакет generic-netf будет полностью заменён пакетом generic когда-нибудь в будущем. Пожалуйста, воздержитесь от использования этого пакета если вы можете вместо этого использовать любой пакет, основанный на .NET Core, поскольку в generic-netf отсутствует многое из функционала доступного в версиях на .NET Core, и со временем этого функционала будет становиться всё меньше. Мы оказываем поддержку этого пакета только на машинах, на которых невозможно использовать вариант generic, описанный выше (например, linux-x86), и только с актуальной средой выполнения (например, последней версией Mono).

Особенности OC

Пакеты под конкретную ОС, помимо управляемого кода, присутствующего в универсальном пакете, также включают в себя машинный код для заданной платформы. Другими словами, в пакете под конкретную ОС уже присутствует среда выполнения .NET Core, что позволяет вам полностью избежать проблем с установкой и перейти непосредственно к запуску ASF. Пакет под конкретную ОС, как понятно из названия, подходит только для одной ОС, и для каждой ОС нужна своя версия - например для Windows требуется исполняемый файл ArchiSteamFarm.exe формата PE32+, а для Linux исполняемый файл ArchiSteamFarm формата Unix ELF. Как вы, возможно, знаете, эти два типа несовместимы между собой.

ASF на данный момент доступно для следующих вариантов ОС:

win-x64 работает на 64-разрядных ОС Windows. Это включает в себя Windows 7 (SP1+), 8.1, 10, Server 2012 R2, 2016, а также будущие версии.
linux-arm работает на 32-разрядных ОС GNU/Linux для процессоров на базе ARM (ARMv7+). Это включает в себя такие платформы как Raspberry Pi 2 (и более новые) и все доступные для них ОС GNU/Linux (такие как Raspbian), как текущие так и будущие версии. Эта версия не будет работать на более старых архитектурах ARM, таких как ARMv6 на которой основаны Raspberry Pi 0 & 1, а также не будет работать под ОС в которых не реализовано необходимое окружение GNU/Linux (таких как Android).
linux-arm64 работает на 64-разрядных ОС GNU/Linux для процессоров на базе ARM (ARMv8+). Это включает в себя такие платформы как Raspberry Pi 3 (и более новые) и все доступные для них ОС GNU/Linux для архитектуры AArch64 (такие как Debian), как текущие так и будущие версии. Этот вариант не будет работать с 32-разрядными ОС, в которых отсутствуют необходимые 64-разрядные библиотеки (такими как Raspbian), а также не будет работать под ОС в которых не реализовано необходимое окружение GNU/Linux (таких как Android).
linux-x64 работает на 64-разрядных ОС GNU/Linux. Это включает в себя Alpine, CentOS/Fedora/RHEL, Debian/Ubuntu/Linux Mint, OpenSUSE/SLES и многие другие, включая их производные, текущих и будущих версий.
win-x64 работает на 64-разрядных ОС OS X. Это включает в себя 10.13, а также будущие версии.

Разумеется, даже если под ваше сочетание ОС и архитектуры отсутствует готовый пакет, вы вы всегда можете самостоятельно установить подходящую среду выполнения .NET Core и запустить универсальный пакет ASF (generic), это и есть основная причина почему он существует. Универсальный пакет ASF платформо-независим и будет работать на любой платформе, на которой есть работоспособная среда выполнения .NET Core. Важно отметить - ASF требуется среда выполнения .NET Core, а не конкретная ОС или архитектура. Например, если вы пользуетесь 32-разрядной версией Windows, то несмотря на то что нет отдельной версии ASF win-x86, вы всё равно можете установить .NET Core SDK версии win-x86 и без проблем запустить универсальный ASF. Мы просто не можем создать пакеты под все сочетания ОС-архитектура которые могут использоваться, поэтому приходится чем-то ограничиться. x86 не попадает в это ограничение, поскольку это устаревшая архитектура как минимум с 2004 года.

Для просмотра полного списка поддерживаемых .NET Core 5.0 платформ и ОС, посетите раздел "release notes" в репозитории .NET Core.

Требования среды исполнения

Если вы используете пакет под конкретную ОС, то вам не нужно беспокоиться о требуемой среде выполнения, поскольку ASF всегда комплектуется требуемой и актуальной средой исполнения, главное чтобы у вас были установлены актуальные предусловия для .NET Core. Другими словами, вам не нужно устанавливать среду выполнения или SDK для .NET Core, поскольку пакеты под конкретную ОС требуют только присутствия необходимых библиотек в данной ОС (предусловий) и ничего более.

Однако, если вы пытаетесь запустить универсальный (generic) пакет ASF - вам следует убедиться, что среда .NET Core поддерживает необходимую ASF платформу.

ASF в данный момент основано на .NET 5.0 (net5.0), но в будущем может потребоваться более новая платформа. netc5.0 поддерживается начиная с версии 5.0.100 SDK (среда выполнения 5.0.0), но ASF настроен на использование самой последней среды выполнения на момент компиляции в качестве целевой, поэтому вам необходимо убедиться, что на вашей машине установлена последняя версия SDK (или как минимум среды выполнения), доступная для вашей платформы. Универсальная версия ASF может не запуститься, если ваша среда выполнения более старая, чем минимальная (целевая) используемая в процессе компиляции.

If in doubt, check what our continuous integration uses for compiling and deploying ASF releases on GitHub. You can find dotnet --info output in every build as part of .NET verification step.