Bureaucrats, Check users, Interface administrators, Push subscription managers, Suppressors, Administrators
415
edits
CollabVM 1.2 Protocol Reference: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
|
All messages with a return value will be replied to with a message with a matching opcode, and additional arguments specified in this reference.
==
=== nop ===▼
This is a keepalive signal sent through the duration of the session used to verify that the client is still connected.
Clients '''MAY''' drop the connection if the server does not send '''any''' messages over a period of time. However this should not be limited strictly to NOPs as these may not be consistently sent if there is other activity on the connection.
==
Upon making a WebSocket connection, the server will immediately begin sending NOPs, which will continue for the duration of the connection. The client is immediately in the handshaking phase of the connection.▼
The handshake is as follows:
=== Authentication announcement ===
A server that uses CollabVM Account Authentication will send a message with the <code>auth</code> opcode to announce this. This indicates a few changes in behavior:
* Clients may login using the <code>login</code> opcode.
▲Upon making a WebSocket connection, the server will immediately begin sending NOPs, which will continue for the duration of the connection.
* Clients may not change username except by logging in or having a guest username assigned.
* Depending on server configuration, clients may not be able to chat, take turns, or vote without logging in
* Staff-password authentication is disabled
<table class="wikitable">
<tr><td>Opcode</td><td><code>auth</code></td></tr>
<tr><td>Parameter 1</td><td>The base URL of the authentication server used by this instance. Ex: <code>https://auth.collabvm.org</code></td></tr>
</table>
===
The first thing the client may want to do is obtain a list of VMs available on this server. If the client already knows exactly what node ID it wants to connect to (common for bots) this may be skipped.
==== list ====▼
<table class="wikitable">
===== Response =====▼
<tr><td>Opcode</td><td><code>list</code></td></tr>
</table>
Parameters 1 through 3 are repeated for every available VM.
<table class="wikitable">
'''Name''': A display name for the VM. May contain HTML.▼
<tr><td>Opcode</td><td><code>list</code></td></tr>
<tr><td>Parameter 1</td><td>The ID of the node, that should be passed to the <code>connect</code> opcode.</td></tr>
</table>
=== Connect to a VM ===▼
▲'''Thumbnail''': A Base64-encoded thumbnail for the VM. Will be either PNG or JPEG depending on the server implementation. This can be determined through magic numbers.
The client may now connect to a VM as follows:
==== connect ====▼
▲Connect to a VM
<table class="wikitable">
▲===== Parameters =====
<tr><td>Opcode</td><td><code>connect</code></td></tr>
</table>
▲'''ID''': The ID of the VM to connect to. Can be retrieved with the list opcode.
<table class="wikitable">
<tr><td>Opcode</td><td><code>connect</code></td></tr>
<tr><td>Parameter 1</td><td>The status of the connection. See below</td></tr>
</table>
Possible statuses:
'''1''': The connection was successful and the client is now connected to the VM.
'''0''': The connection failed. This is usually due to an invalid VM ID but depending on the server implementation and protocol extensions could mean something else.
After successfully connecting to a VM, the client will begin to recieve messages as normal, and may send messages.
| |||