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. For each file one message is sent. The message is send reliable and 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. Each message contains one block. The blocks are send in order from first to last. The message is send reliable and has this format:

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 unreliable 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 part of the block a message is send. Parts 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.

Sending file data is split into multiple parts per block. This allows sending smaller messages without fragmentation for faster delivery. The default part size is 1357 (ConnectionPartSize). The actual offset to write the data too is then File[Path].Blocks[Block].Offset + PartIndex * ConnectionPartSize.

Send by the client after receiving a Send File Data message with the finish or batch flag set. 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:

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:

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: