Skip to content

Latest commit

 

History

History
176 lines (137 loc) · 7.57 KB

PROTOCOL.md

File metadata and controls

176 lines (137 loc) · 7.57 KB

WispNet Protocol

Version 1.0.0 Draft 1 written by @FoxMoss

Note on terminology used

A "Wisp node" is a traditional server running a Wisp.

A "server" is a browser creating a server via wispnet.

A "client" is a browser connecting as a client via wispnet.

A "device" is a browser connected to wispnet.

Packet Types

General Packet Types

Field Name Field Type Notes
Type uint8_t Types will mean different things coming from the server and browser
Payload ... Arbitrary data

Wisp Node Sent Packets

0x01 - REGISTERED

Format

Field Name Field Type Notes
Device ID uint32_t The id as stored on the Wisp node

Behavior

Sent from the Wisp node right after connection, used by the browser to confirm a connection. An ID should be randomly generated and not conflict with another device. It can also be displayed as base64 on the browser for easy sharing and hostnames.

0x02 - REGISTRY

Format

Field Name Field Type Notes
Sockets Socket[] Not seperated by anything

Behavior

Sent by the Wisp node in response to a probe packet. Sends all discoverable ports on all devices.

Socket Struct

Field Name Field Type Notes
Device ID uint32_t Same as sent to browser
Port uint16_t Fictional port to stay compliant with TCP
Notes char[] Null terminated UTF-8 string defined by the browser

0x03 - FWD_CONNECT

Format

Field Name Field Type Notes
Device ID uint32_t The ID of the browser that initiated connection
Connection ID uint32_t Generated by the server, specific to the socket & client ID
Stream Type uint8_t Same as the Wisp packet
Port uint16_t Same as the Wisp packet.

Behavior

Forwarded from a traditional Wisp CONNECT packet. Wisp node should generate an incrementing or random connection ID and store the data on the stream for future use.

0x04 - FWD_DATA

Format

Field Name Field Type Notes
Device ID uint32_t The ID of the browser that initiated connection
Connection ID uint32_t Same as in a FWD_CONNECT packet.
Port uint16_t Same as the Wisp packet.
Data ... Copied from Wisp packet.

Behavior

Forwarded from a traditional Wisp DATA packet. Data should be reused from the connect packet that started the stream.

0x05 - FWD_EXIT

Format

Field Name Field Type Notes
Device ID uint32_t The ID of the browser that initiated connection
Connection ID uint32_t Same as in a FWD_CONNECT packet.
Port uint16_t Same as the Wisp packet.

Behavior

Sent when a Wisp stream exits, or the device wisp web socket closes.

Browser Sent Packets

0x01 - PROBE

Format

No body, sent as a single byte 0x01.

Behavior

Sent to discover other devices on the Wisp node. Once seen a Wisp node should respond with a REGISTRY packet.

0x02 - OPEN

Format

Field Name Field Type Notes
Port uint16_t Fictional port to stay compliant with TCP
Discoverable bool (still a byte) Wont be shown in a REGISTRY packet if false
Notes char[] Null terminated UTF-8 string defined by the wispnet server

Behavior

Sent to open a socket on the Wisp node.

0x03 - SERVER_DATA

Format

Field Name Field Type Notes
Device ID uint32_t The ID of the browser that needs to receive the packet
Connection ID uint32_t Same as the ID thats was sent to it.
Port uint16_t The port that is responding.
Data ... The raw stream data

Behavior

Packet should be forwarded to a device as a standard DATA packet once read by the Wisp node.

0x04 - SERVER_EXIT

Format

Field Name Field Type Notes
Device ID uint32_t The ID of the browser that needs to receive the packet
Connection ID uint32_t Same as the ID thats was sent to it.
Port uint16_t The port that is responding.

Behavior

Packet should be forwarded to a device as a standard EXIT packet once read by the Wisp node. This should be sent once all data has been sent.

Wisp Changes

WispNet maintains backwards compatibility with any standard Wisp server, except parsing hostnames on CONNECT packets. If a connection is made for the wispnet hostname open a TCP stream to your own internal WispNet server as defined above. If the hostname ends with .wisp then interpret the beginning section as a base64 encoded WispNet device ID.

Protocol Extension

If you would like to implement with Wisp V2 you can send appened to your info packet a protocol extension with id 0xF1 and empty body.