... | ... | @@ -370,6 +370,10 @@ This is useful because GATT has much greater support than L2CAP CoC among Androi |
|
|
The allocator characteristic system can be used in parallel with L2CAP CoC, by advertising the PSM of the peripheral's L2CAP server socket along with the UUID of the mesh service.
|
|
|
This allows L2CAP CoC to be used between centrals and peripherals that support it, with the allocator characteristic system providing a fallback for older devices.
|
|
|
|
|
|
The GATT protocol allows a central to read from any read characteristic, not only the one that has been allocated to it.
|
|
|
If the communication between a peripheral and a central needs to be confidential then higher-layer protocols must ensure that this remains the case even when the data sent from the peripheral to the central can easily be observed by other devices nearby.
|
|
|
In practice this is unlikely to make a big difference to the design of higher-layer protocols, which must already be designed around the assumption that any data sent over a wireless medium can easily be received by unintended recipients.
|
|
|
|
|
|
### BluetoothCommunicator
|
|
|
|
|
|
BluetoothCommunicator is a BLE library built upon the core Android `BluetoothGATT` objects similar to BLESSED. However, unlike BLESSED, BluetoothCommunicator is geared more towards async messaging, and not a general-use library. Because of the added flexibility working with BLESSED gives us, future development of BLE mesh networking tools will likely focus on our allocator characteristic framework. However it is useful to research the BluetoothCommunicator library because it gives us insight into how a higher-level messaging framework might be built upon the allocator characteristic system.
|
... | ... | @@ -475,26 +479,35 @@ Alternatively we could implement our own unicast protocol for fetching attribute |
|
|
Local Service Discovery (LSD) is the protocol used by BitTorrent clients to discover peers on the local network.
|
|
|
It is a simple multicast-based protocol in which each peer periodically announces the infohashes of the torrents it is sharing.
|
|
|
|
|
|
<https://www.bittorrent.org/beps/bep_0014.html>
|
|
|
|
|
|
#### Peer Advertisement
|
|
|
|
|
|
<https://www.bittorrent.org/beps/bep_0014.html#protocol>
|
|
|
A peer advertises the torrents it is sharing by periodically sending an advertisement packet to two predefined multicast addresses.
|
|
|
|
|
|
The protocol could be further modified for our purposes by removing the infohash and (optional) cookie field. This comes at the effect of giving the application a more noticeable "fingerprint".
|
|
|
The protocol could be modified for our purposes by removing the infohash and (optional) cookie field. This comes at the effect of giving the application a more noticeable "fingerprint".
|
|
|
|
|
|
#### Peer Discovery
|
|
|
|
|
|
Peer discovery is passive.
|
|
|
Peers are discovered by listening at the specified addresses: 239.192.152.143:6771 (IPv4 org-local) and [ff15::efc0:988f]:6771 (IPv6 site-local)
|
|
|
Peer discovery is passive: peers are discovered by listening at the predefined multicast addresses.
|
|
|
|
|
|
#### Peer Connectivity
|
|
|
|
|
|
Once peers are discovered, a normal TCP connection can be made with the `HOST:PORT` value shared in the announcement packet.
|
|
|
Once peers are discovered, a normal TCP connection can be made.
|
|
|
The source address of the advertisement packet is used for connecting to the discovered peer, together with the port number in the advertisement.
|
|
|
|
|
|
#### Notes
|
|
|
|
|
|
Some devices (eg Huawei P8 Lite 2015 and 2017) don't receive LSD advertisements, even when the screen is turned on.
|
|
|
These devices can send LSD advertisements, and can send and receive NSD advertisements.
|
|
|
So NSD (implemented by the Android platform) appears to get some kind of special treatment compared to LSD (implemented by the application).
|
|
|
NSD (implemented by the Android platform) appears to get some kind of special treatment compared to LSD (implemented by the application).
|
|
|
|
|
|
### LAN Broadcast
|
|
|
|
|
|
KDE Connect uses LAN broadcast, rather than multicast, for discovering peers.
|
|
|
We should investigate whether this could be used to work around the issues we've seen with LAN multicast on some devices and networks.
|
|
|
|
|
|
https://invent.kde.org/network/kdeconnect-android/-/blob/master/src/org/kde/kdeconnect/Backends/LanBackend/LanLinkProvider.java
|
|
|
|
|
|
## Wi-Fi
|
|
|
|
... | ... | |