Each extension is given an unique id that is decided when it is first registered. We differentiate between two types of packets:
Those that:
| Type | Purpose | Extension id range |
|---|---|---|
HAS_PACKETS |
introduce new packets to the protocol | 0-191 |
PACKETLESS |
don't use and need any packets | 192-255 |
Each extension is given one legacy packet id equal to 64+extension_id.
For PACKETLESS extensions this would mean that their packet ids are out
of spec >255, thus they don't have any.
An example for a packetless extension would be OpenSpades' UnicodeExt.
Each extension packet will contain 1 additional byte in its data, which is a subpacket id, used to have multiple packets available for each extension. This is always the case, even if an extension only needs 1 packet in total.
General extension packet structure:
| Field name | Type | Notes |
|---|---|---|
| Packet id | UByte | 64-255 |
| Sub packet id | UByte | 0-255 |
| Data | UByte[] | extension data |
- Packet ID: 60
- Total size:
2+2*length
| Field name | Field type | Notes |
|---|---|---|
| length | UByte | length entries will follow |
| entries | ExtInfoEntry | see below |
ExtInfoEntry
| Field name | Field type | Notes |
|---|---|---|
| ext. ID | UByte | see #Overview |
| version | UByte | Usually starts at 1 |
The server should send an ExtInfo packet (optimally) after the Version Info response has been received to compatible clients
(OpenSpades versions > 0.1.3, see piqueserver/piqueserver#504),
assuming it supports any. The client can store the list of extensions for later use and should
reply with an ExtInfo packet that lists the extensions it supports (if it does actually support any).
The client can omit any extensions that the server does not support from its reply, but this is not necessary as the server can simply ignore them itself.