Académique Documents
Professionnel Documents
Culture Documents
In A3 1.50 the 2 new script commands were added to natively handle execution of code and functions on remote
machines - remoteExec and remoteExecCall.
Links
remoteExec
remoteExecCall
CfgRemoteExec
BIS_fnc_MP
Motivation
Until A3 1.50 there was no engine based remote execution. The only officially supported way how to execute
code or command on non-local machine was by using scripted remote execution framework - BIS_fnc_MP. This
scripted framework, however working, suffered from several issues, mainly poor network traffic optimization and
insufficient security control. The network traffic was optimized in 1.46 but the security issues could not be
properly fix in the scripted framework.
To address those security issues, in A3 1.50 the remote execution was implemented into the engine. There are
now 2 new script commands - remoteExec and remoteExecCall, that allow for fully controlled and secure remote
execution from client machines(s).
Syntax
Both script commands have same syntax but differ in way how the code is executed on target machine(s). For
details and explanation of the difference, see the next section.
function: STRING - function name. Commands and functions defined in CfgRemoteExec are whitelisted.
target: - Optional. [default: 0]
0 - the function will be executed on each machine including the one where remoteExec was called from.
2 - it will be executed only by server.
negative value - it will be executed everywhere except for machines with with the given owner ID.
SIDE - the function will be executed only on machines where the player is on the specified side
GROUP - the function will be executed only on machines where the player is in the specified group
ARRAY - array of any of types listed above
isPersistent: STRING or BOOL - Optional [default: false].
If true, function generates an unique ID for the message and the message itself is added to the JIP
queue with the unique ID.
If a non-empty string, it is a custom ID of the message and the message itself is added to the JIP queue
overriding any remoteExec message with the same ID.
Otherwise, no ID is generated and no message is placed into the JIP queue (default state).
Return Values
NIL in case of error.
STRING otherwise. If JIP is not requested this is an empty string. Otherwise this is an unique JIP ID.
remoteExec
If you want to execute more complex code that needs to be processed as separate spawn
use remoteExec command.
More specifically:
2. If your code contains more CPU demanding operations that will take some time for the
game to process, you SHOULD use remoteExec, otherwise you might experience
performance drops.
remoteExecCall
The code sent by remoteExecCall MUST NOT contain any delays and SHOULD NOT be too
complex and CPU demanding.
Security
The biggest issue of previous scripted remote execution was the lack of control over what can and
cannot be executed from local clients. To address this weve created system where content authors
can define through CfgRemoteExec config how the remote execution should operate on clients.
Note: Server doesnt have any limitations at place, everything is enabled and opened for him. All
limitations and rules apply only for client(s).
Because remoteExec and remoteExecCall can be used to remotely execute script commands (like
for e.g. setDamage) as well as scripted functions (e.g. BIS_fnc_setRank) we have separated the
security settings into two groups Functions and Commands. This allows people to quickly set
different rules for functions and commands separately.
The security rules consist of 3 security settings - operation mode, allowed targets and jip. The
operation mode is very important as it defines if functions/commands can be executed remotely from
client or not and ev. allows you to whitelist specific functions/commands. The allowed targets and jip
are very optional and you really do not need to use them, unless you want to be super safe.
To get more info about those settings and the CfgRemoteExec config, check the subsections below.
Operation modes
Operation mode is numeric value describing how functions or commands should be treated on
server on client.
Allowed targets
In addition to the operation mode, in client subclass, allowed targets can be defined for individual
whitelisted commands and functions. This adds another layer of security and control to the system,
as it allows you to define not only who can send the execution request, but also where it can be
executed.
JIP
To control who can add JIP message into JIP queue, we have added an optional parameter jip. This
parameter can be defined in whitelisted function/command class, at the same place as allowed
targets are defined or in the Functions and/or Commands classes. This parameter affects only
clients (no effect if defined within Server subclass).
If it is defined on both levels, the more local definition takes precedence (which is the value defined
in the whitelisted function/command).
Config location
class CfgRemoteExec
class Commands
mode = 1;
class hint {jip = 0;}; //jip is not allowed for this command
};
class Functions
mode = 0;
};
};
The BIS_fnc_MP function is scheduled for A3 1.54 to be changed to a proxy for the new system to
provide backwards compability to missions still using BIS_fnc_MP. This means that as of A3
1.54 CfgRemoteExec rules for remote execution will apply to BIS_fnc_MP. Because of that the
content authors that were using the BIS_fnc_MP will be able to set the security permissions for
remote execution.
If you want to know more about how the remote execution works and handles some more
complicated issues and edge cases continue reading, otherwise feel free to skip.
JIP queue
JIP id
The JIP id is a unique key under which the JIP MP message is being stored in the JIP queue on the
server. When you set isPersistent flag to true, the JIP id is auto-generated on the machine the
remote execution was initiated. If you set the isPersistent flag to specific string, that string is
considered to be the JIP id.
The auto-generated JIP is always unique. If the JIP is manually supplied, the content author needs
to make sure it is unique, otherwise he/she will overwrite another MP msg that is currently stored in
the queue under the JIP id.
Every JIP message is stored in the queue. If you need to overwrite the JIP message with another
message, use the same JIP id for the new message. This way the new message will be stored in the
queue under the provided id and will overwrite the previously stored message that used the same id.
To remove a specific JIP message from the queue call the remoteExec with function/command
name set to an empty string, the JIP id of the message you want to remove and no other params.
remoteExec ["", "JIPid"];
Validity verification
Validity of remote execution request is verified in 2 steps: when the request is initiated (issued from a
client machine) when the server is going to broadcast the request. If the request is initialized directly
from the server, step 1 is skipped (this applies for hosted server admins as well).
4. if JIP is used (isPersistent flag is not false), JIP must be allowed in CfgRemoteExec (jip=1)