Bureaucrats, Check users, Interface administrators, Push subscription managers, Suppressors, Administrators
427
edits
No edit summary |
(add flag opcode) |
||
(3 intermediate revisions by the same user not shown) | |||
The server will respond with a [[#Client Renamed|Client Renamed]] event, however with one key difference: The status will always be <code>0</code> (success), even if the requested username was not available for whatever reason. In this case, a guest username is assigned.
=== Client Capabilities ===
The client may at this point negociate capabilities with the server. This is a recent addition and so far only one exists, <code>bin</code>, enabling the [[#Binary Protocol|Binary Protocol]].
==== Request ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>cap</code></td></tr>
<tr><td>Parameters</td><td>Each parameter is a client capability the client supports and wants the server to use.</td></tr>
</table>
==== Response ====
<table class="wikitable">
<tr><td>Opcode</td><td><code>cap</code></td></tr>
<tr><td>Parameters</td><td>The server lists each opcode it supports, out of the list the client sent, that will be used for this connection.</td></tr>
</table>
=== Connect to a VM ===
<tr><td>Parameter 1</td><td>The username of the added user.</td></tr>
<tr><td>Parameter 2</td><td>The [[#Rank|Rank]] of the added user as an integer.</td></tr>
</table>
=== Flag ===
Sent to provide the ISO country code for one or more users, if the server supports geolocation. The intended use is to display a country code beside each name in the list.
Parameters 1 and 2 are repeated for each user added.
<table class="wikitable">
<tr><td>Opcode</td><td><code>flag</code></td></tr>
<tr><td>Parameter 1</td><td>The username whose country code is being sent</td></tr>
<tr><td>Parameter 2</td><td>The two-character, upper-cased ISO country code of the user in question.</td></tr>
</table>
=== Framebuffer Update ===
Sent to update the VM screen. The server will send one initial message containing the entire screen on connection, and after that will send a dirty rect for each update.
If the binary protocol is enabled, you will instead receive [[#Framebuffer Update (Binary)|Framebuffer Update (Binary)]] messages.
<table class="wikitable">
<tr><td>Parameter 2</td><td>System message to send</td></tr>
</table>
= Binary Protocol =
The binary protocol is a new addition to the CollabVM protocol, that allows certain messages to be sent as binary instead of a base64 encoded guacamole string. So far, only one such message exists.
The protocol may be enabled by [[#Client_Capabilities|Negotiating]] the <code>bin</code> protocol with the server during the [[#Handshake|Handshake]].
== Message format ==
All binary messages are encoded with [https://msgpack.org/ MsgPack] (subject to change) and follow this basic format:
{{code|lang=ts|<nowiki>
{
type: number;
// Message specific data
}
</nowiki>}}
Where <code>type</code> is one of the following:
{{code|lang=ts|<nowiki>
{
// Framebuffer Update (rectangle)
rect = 0,
}
</nowiki>}}
== Server-to-Client Messages ==
=== Framebuffer Update (Binary) ===
Sent to update the VM screen. The server will send one initial message containing the entire screen on connection, and after that will send a dirty rect for each update.
If the binary protocol is enabled, this will be sent INSTEAD of <code>png</code> opcode messages.
{{code|lang=ts|<nowiki>
{
type: 0,
rect: {
// X-coordinate of the rectangle
x: number;
// Y-coordinate of the rectangle
y: number;
// Buffer containing the JPEG data for the rectangle.
data: Uint8Array;
}
}
</nowiki>}}
= Rank =
|