Often one asks what are requests and tasks and how they are executed.
First, you must understand that 2 types of partners exist: client and server.
a) A client
A client can only be the source of a request (whatever the way, push or pull, send or recv). It cannot be the target of a request. This could be compared to a FTP client which can only initiate a connection, but cannot be the target of a new connection (a part from internal FTP protocol for Data between Passive or Active mode for instance).
b) A server
A server can ask for new request (initiating a connection) or can be the target of a new request. However, contrary to a FTP server, it can initiate itself a request.
c) An heavy client
An heavy client is like a client but with a "light" database, meaning that all its logs and management will be in the light database (H2 Database in Java). Note that this mode could be extended to a Server mode, using this database, as for "light" server.
For a request, we have two kinds of partners:
a) the requester
b) the requested
When a request is initiated, the initiator (named requester) will try to connect to the requested (target). It tries 3 times with waiting time between, until it reaches the target. If the connection is not ok, then after 3 tries, the request is in error. We will see later on what happens then.
If the initiator is a client, the request can only be restarted from the client, since it cannot be the target of a new request (the client is not listening to any new request). That's the main reason why a stopped request can be restarted from initiator only. However, in some conditions, R66 protocol will try to restart a request even from the target, if the initiator is not a client and if it can in fact send a request of restart to this remote original requester partner.
Another reason for the requester to be the root of a restart in case of error, is that most of the time, this is where the request could have much more meanings, either in term of tasks to execute or in term of file preparation or responsability.
Any request can be in SEND or RECV mode (push or pull).
This are the main drivers to know which tasks will be executed by who.
Once the request is initiated and both partners ok to do so, the sender (could be different than the requester) will execute Send tasks, while the other one will execute the Recv tasks. For a specific rule, if the rule is defined as a SEND mode, the requester will be the sender, while in the opposite if the rule is defined as a RECV mode, the requester will be the receiver.
Examples:
The rule will be defined in both partners as follow:
The opposite rule in RECV mode will be as follow:
The independance of the configuration for server A and server B ensure that locally the rules are defined according the local needs. Note however that if the 2 servers share the same database for their respective configuration, they will share also the rule definitions and therefore the task definitions.
Using the local configuration information (local to each partner), as the directory configuration, the local resolution of variables (as host name, file name, ID, ...), it is therefore possible to share the very same rule definitions with several partners, while they will act differently locally. For instance, both partners could reference the very same name of external script, but those scripts will be different and adapted to the local context and therefore acting differently.
Once the role of each partner is determine (sender or receiver), the tasks will be executed as follow:
a) Pre tasks on requested side b) Pre tasks on requester side c) File transfer d) Post tasks on receiver side e) Post tasks on sender side
In case of error, whatever the side, the error message is sent back to the partner and both sides execute the Error tasks.
Two modes are available:
For the asynchronous mode, the command line SubmitTransfer has to be used.
For the synchronous mode (or to come back to a synchronous operation once launched using asynchronous mode):