Introduction - The Routers
You want to receive an important message from your colleague's machine that you can only request in bundles.
The request response will include a slice of the message that you will need to put together when all the pieces arrive.
Is your program able to pass your requests in time through the maze and compile a final message with data management and router configuration capabilities?

Program logic
The server room consists of 14 routers ([0..13]), each with 20 slots (left [0..9] and right [0..9]). The requests / data can be located in the storage between these slots ([0..9]).
Routers are in ring topology, where the left slots are smaller by one index, the right slots by one index larger by the right and left slots of the router, respectively, and the first to the last (see figure).
During the qualifier, your computer is connected to Router 3, where you start the requests, and your colleague's computer to 10, where you will receive the data.

The elements
router

Feeders
They have the following characteristics:
Busy, that is, there is a request / data: There can only be one request / data per storage at a time.
Open: Whether to transmit and receive from your slots or from your neighboring storage. These can be set initially or during laps. (character, 0 = closed, 1 = open) Router rules refer to the locking / opening of your containers.
joints
A binding connects the slots of two adjacent routers with the same index.
Binding is permeable to a request / data if the container adjacent to both slots is open and the destination container is not occupied by another.

Request / data
It has the following features:

the current router and the storage location within it. (non-negative integers)
Unique index (non-negative integer)
Index of the requested piece of the final message (non-negative integer)
Initial router where the message started (non-negative integer)
Destination Router Index (Non-Negative Integer)
Direction (left / right) of which branch of the ring topology goes. (character, l = left, r = right) If the initial router and destination router have the same index, then this is data, otherwise it is a request.
They move automatically depending on:

If the request / data of your current location router has one smaller storage open and unoccupied then it moves to that location.
If the binding to the request / data is permeable, you prefer it for the second time
Otherwise, wait for the router rules to change
Requests can only appear on a free storage on a computer-connected router. Each controller can have a maximum of 5 request + data packets on the routers.

Modifying router rules
The router has the ability to change the router's rule every turn if there is a packet that it starts on that router. Here's how:

The router number and
specifying one direction (positive / negative) (character, '^' negative, 'v' positive): When given a positive direction, all the router storage "takes over" the smaller one. Storage 0 takes over the openness of the largest storage on the router. Negative direction is the opposite.
CAUTION: As rules change, requests / data move in the same direction!

If several movement commands are received on a router within a circle, the "result" of these commands will be executed, ie: two positive directions will move the rules by 2, one positive and one negative will have no movement.

System protection function: one router rule per turn is automatically changed according to unknown but deterministic rules.

Receipt of the request / data
If a request / data reaches any repository on the destination router, it stays in that loop. At the beginning of the next round:

If this was a data, it disappears and the sender receives the message.
If this was a request, it changes its direction and destination router back to the sender's router as data in the message.
The process of simulation
The simulation is a turn-by-turn simulation, with the following steps in each turn:

Manage your targeted messages
The appearance of new packages
Changes in router rules
Move requests / data one space at a time
If multiple requests / data are moved to a single location, the next priority is to move:
It's the future inside a router.
It comes from a smaller router. The last router with an exception is the exception because it has priority over router 0.
Received requests / data are processed and "frozen" until the next round.
If there is a request / data that can still move, then step 3 continues.
Protocol
The program must communicate through its standard input and standard output according to the following protocol:

Initial message
START <team-token: string> <seed: int>

The initial message may include the token in the web interface, or optionally the seed of the initial configuration you are considering, which is an integer.

Successful connection or at the beginning of each turn
REQUEST <game-id: uint> <tick-id: uint> <start-router-id: uint>
PREVIOUS <message: string>
ROUTER 0 <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0 / 1>
ROUTER 1 <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0 / 1>
ROUTER 2 <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0 / 1>
ROUTER 3 <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0 / 1>
...
ROUTER 13 <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0/1> <0 / 1>
DATA <current-router-id> <current-store-id> <data-index> <message-id> <from-router-id> <to-router-id> <l / r>
...
MESSAGE <data-index> <message-piece: string>
...
.
Where the number after ROUTER is the index of the router, followed by the binary digits listed below, in the order of [0..9] open for the containers (0 = closed, 1 = open)

The DATA message has a request / data description

The MESSAGE message comes when a data request from you arrives at a router connected to your machine. The message does not contain a whitespace character.

The end of the message queue is a. indicates.

Reply Options
You can send exactly 1 message to each of the following options. Each command must be preceded by 3 numbers after REQUEST!

<game-id> <tick-id> <start-router-id> PASS:

The program does nothing.

<game-id> <tick-id> <start-router-id> CREATE <store-id> <package-id>:

A request is created in the store-id repository specified on your router id. The message will have the package-id index. Its direction will be left first, then alternately right-left ...

<game-id> <tick-id> <start-router-id> MOVE <router-id> <dir: ^ / v>:

The router will move your router id in the specified direction.

<game-id> <tick-id> <start-router-id> SOLUTION <final-message>:

Once the final message has been received, the resulting pieces are stitched together (without whitespace characters) and then sent to the simulation. Then, if the solution is right, you are in the next round!

The final message
The only thing we know about the final message, that is, the solution, if an empty message part comes in response to a request for one packet, it indicates the end of the message. The first package is the index 0 package, which always contains information.
For each different game-id, this final message (and even its length) will be different!

Error, timeout
If there are any incorrect requests to the server (including failed connection), or a timeout occurs (your program thinks for more than 2 seconds within a lap), the server will disconnect after the next message.

WRONG <reason: string>
.
There is also a global timeout which is 3 minutes. If the game is not completed during this time, the server will automatically disconnect and the results (and logs) received so far will be lost!

Testing
If you manage to solve the problem at least once (with the code in the git, uploaded), you are on your way. After that, you can continue to test your code.

You have the following methods:

From the surface
It is possible to modify or save the code in the web interface. Each backup will start a new run which will test the current code. The result of this can be viewed on the web interface in the viewer, and any custom logs or communication process written for the standard error can be downloaded. Changes are automatically saved to git.

From the git repository
Each team file on the web is stored in its own git version manager, which we also provide direct access to. If someone pushes the master_ [c / cpp / java / python] branch pushed, then a trigger will automatically start the compile and run process from the top of the branch. The result is pushed to the master_log branch. The programming language can only be selected from the interface!

network
It is also possible to test remotely on your own machine. To do this, you have to work by downloading the code and redirecting standard input / standard output communication to the TCP address provided in the web interface (eg netcat).
The logs of the games played in this way will not be added to the GIT (they will be lost) or counted for further progress.