Binary protocol for communication between instances of HaveClip

Architecture

HaveClip defines conversations and messages (commands).

Messages are generic means of exchanging information while conversation brings them into context. Messages may be used in any order and by any conversation.

A conversation has defined structure of communication by a chain of messages in either receiving or sending role (message receives or transmits data).

A conversation may change the order of messages at runtime, based on peer's responses or other parameters. A conversation may also morph into another conversation. However, it must always do so on both peers, otherwise communication will fail.

Authentication

Conversation may choose what level of authentication should be applied.

Authentication is enforced after SSL/TLS handshake and after it is clear what conversation will take place, so that the conversation level of authentication may be considered.

The levels are:

• NoAuth - no authentication at all, used for Introduction
• Introduced - the peer must be introduced, used for Verification
• Verified - the peer must be verified, meaning it is in pool, has valid certificate and it matches

Auto discovery

HaveClip can be auto discovered on LANs. The searching peer sends a broadcast. All HaveClips listen for this broadcast and they reply to the sender.

Possible conversations

Introduction

Used when adding a node to the pool. Target node should open a dialog where user can type the security code shown on requestor.

The requestor should also remember target node certificate and check it during verification.

1. Request: Introduce
2. Reply: Introduce

Verification

Follows introduction, target node sends the security code back to requestor. If the code is correct, devices are paired.

There are three tries after which security code becomes invalid and pairing failed.

1. Request: SecurityCode
2. Reply: Confirm

Clipboard update

Requestor is sending ClipboardItem to replier.

1. Request: ClipboardUpdateReady
2. Reply: ClipboardUpdateConfirm
3. Request: ClipboardUpdateSend
4. Reply: Confirm

Protocol structure

Message header

Auto discovery request/reply

The message contains no header.

Message types

Ping

Contains no data, sends just header.

Introduce

SecurityCode

ClipboardUpdateReady

ClipboardUpdateConfirm

ClipboardUpdateSend

Confirm