QuantumGate Bluetooth Protocol
QuantumGate supports peer-to-peer connections using the Bluetooth RFCOMM protocol starting from version 0.3.5. There is little difference in the way connections work in QuantumGate using Bluetooth compared to TCP. Once a Bluetooth connection has been established, QuantumGate uses the same protocol to communicate with peers that is used with TCP connections. This means that the same initial handshake is performed and key updates are done during configurable intervals.
The main difference with TCP connections is that for Bluetooth connections it's possible to optionally enable Bluetooth authentication and encryption when establishing a connection.
With authenticated Bluetooth connections, two devices have to be paired first via Bluetooth before connections using QuantumGate will succeed. QuantumGate does not handle device pairing; this is left to the operating systems of the devices. For example in Windows, when QuantumGate is configured to require Bluetooth authentication, upon trying to establish a connection with a peer the Windows operating system will prompt the users of both devices to first pair their devices. Only after device pairing has been completed, will the connection initiated with QuantumGate succeed. By default, QuantumGate is configured to require Bluetooth authentication, but this can be specified and changed using the StartupParameters (for incoming connections) and the ConnectParameters (for outgoing connections). When QuantumGate is configured to require Bluetooth authentication it automatically also enables Bluetooth encryption as an additional layer of encryption, apart from the encryption that is always used as a regular part of the QuantumGate communications protocol.
Device pairing is not required when using unauthenticated Bluetooth connections and this allows for a more ad-hoc communications style that can make it easier, for example, to establish peer-to-peer mesh networks using Bluetooth.
Again, whether Bluetooth authentication and encryption are used or not, connections via QuantumGate always remain encrypted and secured (and optionally authenticated) through the QuantumGate communications protocol just like with TCP and UDP connections.
Bluetooth device discovery allows a device to look for and find nearby devices that support Bluetooth. This can make it considerably easier to find nearby devices to connect to using QuantumGate. By default QuantumGate is configured to not make the device discoverable over Bluetooth while it is listening for incoming Bluetooth connections (which is good for privacy), but this can be configured using the StartupParameters. A device that is not discoverable can still be connected to as long as its Bluetooth address (and port or Bluetooth service class ID) is known to peers.
When QuantumGate is configured to make the device discoverable over Bluetooth, it will instruct the operating system to make the device discoverable to nearby devices only while it is listening for incoming Bluetooth connections (i.e. while the Bluetooth listener is enabled). If the Bluetooth listener is not enabled then QuantumGate will not make the device discoverable over Bluetooth.
When a Bluetooth device is discoverable and is nearby, the local QuantumGate instance can find it and look up its Bluetooth address (via the Local::Environment) and connect to it using the default QuantumGate Bluetooth service class ID (assuming the peer is using the default service class ID, configurable via the StartupParameters). If the device is not discoverable, then another way should be provided by application developers to find the Bluetooth address of the device and the port that it's listening on, and share it with other devices in order for them to be able to connect to it.
Relayed connections on the QuantumGate network can also be established over Bluetooth, and it’s even possible for one relayed connection to be established across peer-to-peer connections using a mix of protocols for each hop.
For example, looking at the image above we can see 6 peers, A—F, connected to each other. Peer A is connected to peer B over Bluetooth (RFCOMM), while peer B is connected to peer C over TCP. And peer C is connected to peer D over UDP. Simultaneously peer A is also connected to peer D via relayed connection 1 (yellow) over 3 hops, where each hop is tunneled through a different protocol (RFCOMM for hop 1, TCP for hop 2 and UDP for hop 3).
If peer A didn’t have access to the Internet, it could connect to peer B over Bluetooth and reach peer C over the Internet through peer B. In other scenarios traffic analysis also becomes more difficult when communications suddenly goes off the grid over Bluetooth and reappears somewhere else, possibly even on another network.
Probably the most important use case for Bluetooth support is when applications built on top of QuantumGate need to communicate with each other when there’s a problem with the Internet, for example, when robberments around the world deny their slaves (AKA ‘citizens’) access to the Internet. When the Internet is shut down, it would be possible to keep communications going via a peer-to-peer mesh network over Bluetooth. And if there is still one peer on the network with access to the Internet, other peers could eventually still reach the Internet, for example, via relayed connections.
Keep in mind that transfer speeds over Bluetooth can be considerably slower compared to TCP and UDP, and this is due to limitations of Bluetooth.
The QuantumGateBluetooth example project that is provided along with other examples shows how to scan for nearby Bluetooth devices, establish connections over Bluetooth and sending simple messages to peers. Refer to the comments that are provided in the source code for more detailed explanations.
The TestApp can also be used to try out Bluetooth support. For example, it's possible to establish connections (including relayed connections) over Bluetooth using the TestApp, and to use the Test Extender to send messages.