All mrci frames transferred throughout this application have an 8bit numeric value to indicate the type of data being passed with the binary data. The type id enum values are as follows:
This is text that can be displayed directly to the user, pass command line arguments to be processed or used to carry text data within other data types.
This is a file transfer type id that can be used to transfer any file type (music, photos, documents, etc...). It operates in its own protocol of sorts. The 1st GEN_FILE frame received by the host or client is TEXT parameters similar to what you see in terminal command lines with at least one of the arguments listed below. The next set of GEN_FILE frames received by the host or client is then the binary data that needs to be written to an open file or streamed until the limit defined in -len is meet.
The host or the client can be set as the sender or receiver of the GEN_FILE binary data. Which ever is designated as the receiver by the TEXT parameters need to send an empty GEN_FILE frame to start the process. An example if this can be found in section 3.3.
* **-len (int)** | this is the integer value of the file size or amount of bytes to read/write.
* **-offset (int)** | this integer position tells where in the source or destination file to start reading/writing.
* **-client_file** (string) | this is the file path to the source/destination file in the client's file system.
* **-remote_file** (string) | this is the file path to the source/destination file in the host file system.
* **-single_step** | the presents of this argument tells both the client and host to operate in single step mode. single step mode causes the receiver of the binary data whether host or client to send an empty GEN_FILE frame after successfully receiving the data. this then tells the sender to send the next GEN_FILE frame containing binary data for the file and the cycle continues until len is meet. if this argument is not found, the sender can simply send all GEN_FILE data without waiting for an empty GEN_FILE from the receiver.
* **-to_host** | this argument should only come from host and it will define the client as the sender and the host as the receiver.
* **-from_host** | opposite affect to *-to_host*. it defines the host as the sender and the client as the receiver.
* **-truncate** | this indicates to whoever is the receiver to truncate the file being written to.
* **-force** | in some cases, the receiver might need to overwrite the target file. the presents of this argument tells it to overwrite without asking the user. the host should never send this argument and the client should ignore it if it is received from the host.
```ERR```
This type id is similar to TEXT except it indicates that this is an error message that can be displayed directly to the user if needed.
```PRIV_TEXT```
This id can be treated exactly like TEXT except this should tell the client to hide or do not echo the next TEXT data that the host is expecting, like a password or other sensitive text data.
```BIG_TEXT```
Also formatted exactly like TEXT but this indicates to the client that this is a large body of text that is recommended to be word wrapped when displaying to the user. It can contain line breaks so clients are also recommended to honor those line breaks.
This doesn't carry any actual data, instead this indicates that the command-branch id that sent it has finished it's task. Modules that send this doesn't need to terminate it's process.
```KILL_CMD```
This doesn't carry any actual data, instead can be sent by the client or session object to tell the command-branch id sent in the frame to terminate the module process. Modules that receive this need to send a IDLE frame if a command is still running and then terminate itself. The module will have 3 seconds to do this before it is force killed by the session.
```HALT_CMD```
This doesn't carry any actual data, instead can be sent by the client or session object to tell the command-branch id sent in the frame to pause/halt the current task that the command is currently running. All modules are not obligated to support this feature but highly recommended.
```RESUME_CMD```
This is the other half of HALT_CMD that tells the module to resume the command task it was running.
This data structure carries 3 numeric values that represent the host version as described in section [1.3](protocol.md).
```
format:
1. bytes[0-1] - version major (16bit little endian uint)
2. bytes[2-3] - version minor (16bit little endian uint)
3. bytes[4-5] - version patch (16bit little endian uint)
```
```PRIV_IPC```
This is a data structure used to by modules to run async commands on the local session object only.
```
format:
1. bytes[0-1] - async command id (16bit little endian uint)
2. bytes[2-n] - payload (data to be processed by async command)
```
```PUB_IPC```
This is formatted exactly like PRIV_IPC except it is used by modules to run async commands on all connected peers in the host while avoiding a run on the local session object.
```PUB_IPC_WITH_FEEDBACK```
This combines the functionality of PUB_IPC and PRIV_IPC. It runs async commands on all connected peers and on the local session object.
This formatted extactly as PEER_INFO except it can be used the ASYNC_LIMITED_CAST [async](async.md) command to tell all peer sessions that receive it to send PEER_INFO frame about you to their own clients and to return PEER_INFO frames about themselves to you.
This type id carries a 64bit unsighed LE int indicating the channel id.
format: ```8bytes - 64bit LE unsigned int (channel id)```
```SESSION_ID```
This is a fixed length 28byte(224bit) sha3 hash of a client's session id connected to the host. This is unique to just the client's tcp connection with the host. This can change upon re-connection.
format: ```28bytes - session id (224bit sha3 hash)```
This is formatted extactly like PEER_INFO except it is allowed to be sent directly to a peer session without retriction via the ASYNC_P2P [async](async.md) command. It will be up to the target peer to respond with a P2P_OPEN for the session to then unrestrict ASYNC_P2P so it will then be able to send/received other TypeIDs with this peer until P2P_CLOSE is sent/received. P2P_CLOSE can also be sent to decline the request.
* The host has a command called *upload_file* with a command id of *768* and handles the ```GEN_FILE``` data type.
* The client has a file called */home/foo/bar.mp3* and wants to upload it to the host file */home/host/music/bar.mp3* and the client knows the file size is 512bytes.
To upload the file, the client calls command id *768* with the following text arguments (must still be sent as a GEN_FILE):
The host will then return the following the text arguments to the client (also sent as a GEN_FILE):
```-to_host```
This argument from the host designates it as the receiver so it will be up to the host to send an empty ```GEN_FILE``` to indicate to the client that it was ready to start receiving binary data from the client to write to */home/host/music/bar.mp3*. If that file already exists, the host will need to ask the user to overwrite or not.
If the host indicates that it's ready for the upload, the client can then simply read 512 bytes from */home/foo/bar.mp3* and send the read bytes to the host command id *768* as a ```GEN_FILE```.
The host will then write the bytes received from the client to */home/host/music/bar.mp3* and then auto terminate the command since 512 bytes has been meet.
