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. Layout contains the entire file hierarchy as flat list. The message is send reliable and has this format:

FileData has this format:

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:

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

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

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

FileData has this format:

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

FileData has this format:

The client has to mark the files 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 unreliable Send File Data messages.

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

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

FileData has this format:

Message send by the server to client with data to write to a file. The message is send unreliable and has this format:

Receiving and processing the message (successful or not) requires the client to send a File Data Received message. Multiple Send File Data messages can be acknowledged in the same File Data Received message.

Send by the client after receiving one or more Send File Data messages. Using this message the server knows which Send File Data messages have arrive and which have been successfully been written. The message is send reliable and has this format:

FileData has this format:

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

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

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

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

FileData 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:

LineData 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: