The Remote Launcher Network Protocol uses the Drag[en]gine Network Protocol as protocol and defines a set of messages and linked states supported by IGDE and Remote Launchers. The specification can change with upcoming Drag[en]gine updates but stays backwards compatible. Servers and clients are required to ignore unknown messages and linked states.

To implement this protocol best use Drag[en]gine Network Library and add the necessary message and state handling.

These are all messages the server and the client can send to each other.

Upon connecting the client has to send this message to request access to IGDE indicating the kinds of features it supports. The connect request message has this format:

The server will then respond with a Connect Accepted message or disconnect the client if rejected.

Send by the server after a client connects which send Connect Request message identifying itself as a Remote Launcher client. This is the first message received from the server. The client should not send any messages until it has received this message as this will get him disconnected. The message is send reliable and has this format:

Send by the server to request the file layout of the client. The client has to scan the entire date storage where the project files are located and record the file parameters. Since this process can be lengthy the client typically stores the file layout in memory and updates it as files are modified. The message is send reliable and has this format:

Once the file layout is ready a Response File Layout message is send.

Send by the client in response to a Request File Layout message containing the scanned file layout. The message is send reliable and has this format:

Where FileInfo is:

Send by the server to request block wise hashes of a file from the client. Block wise hashes are useful for large files to avoid updating the entire file. Since this process can be lengthy the client typically stores the block wise hashes for a file in memory if requested. The message is send reliable and has this format:

Once the block wise hashes are calculated a Response File Block Hashes message is send.

Send by the client in response to a Request File Block Hashes message containing the file block hashes. The message is send reliable and has this format:

Where BlockInfo is:

Send by the server to request the client to delete a file. The message is send reliable and has this format:

Once the operation finished (either successfully or not) a Response Delete File message is send.

Send by the client in response to a Request Delete File message. Indicates if the operation succeeded or not. The message is send reliable and has this format:

Send by the server to request the client to start writing a file. The message is send reliable and has this format:

The client has to mark the file as in progress for writing. If the file size is shorter than the existing file the file has to be truncated. File writing has to be done in overwrite mode hence the file content is retained. This allows updating only ranges of data inside large files. Data to write is send using reliable Send File Data messages.

Once ready the client has to send back a Response Write File.

Send by the client in response to a Request Write File message. The message is send reliable and has this format:

Message send by the server to client with data to write to a file. For each block a message is send. Blocks are send in order from first to last. The message is send reliable and has this format:

Receiving and processing the message (successful or not) requires the client to send a File Data Received message.

Send by the client after receiving a Send File Data message. The message is send reliable and has this format:

Send by the server to request the client to finish writing a file. The message is send reliable and has this format:

The client has to mark the file as finished writing and ready to be used.

Once ready the client has to send back a Response Finish Write File.

Send by the client in response to a Request Finish Write File message. The message is send reliable and has this format:

Send by the server to request the client to start application. The message is send reliable and has this format:

Send by the server to request the client to stop application. The message is send reliable and has this format:

Send by the client to send logs to the server. Logs are send as lines. The message is send reliable and has this format:

Send by the server to request information about the system the client is running on. The server indicates which property to query. The client has to return the requested property value if it is supported and the value can be determined. Otherwise the client has to return an empty response. The message is send reliable and has this format:

The client sends back a Response System Property message.

Send by the client in response to a Request System Property message. The response contains the property value if the client supports the property and can determine the value. Otherwise the client sends an response with empty data. The message is send reliable and has this format:

Send by the server and the client to verify the other side is still alive. This catches situations where the other side crashed or the network connection between the two sides ruptured. This messages requires no response since it is send reliable. Failure to receive it closes the connection. The message has this format:

These are all linked states the server can request.

Send by the server to link the running state. The link message has this format:

The client has to add these values to the state in this specified order: