On-multiplexing-over-transport-layers.md

@@ -23,3 +23,126 @@ akwizgran explained:
 
 Later on, this evolved into a full-scale planning for "combining various transports":
 
+> i'm considering the following plan for combining various transports:
+> * ble is the main transport that all peers are expected to support
+>   * if we detect that the device doesn't support ble advertising at all, we can warn the user that the app won't work properly
+>   * there are some (older?) devices that claim to support ble advertising but it doesn't seem to work. two devices like this won't be able to connect to each other
+> * bluetooth l2cap and rfcomm will be used opportunistically if available
+> * wi-fi direct legacy mode will be used opportunistically if available
+> * wi-fi direct peer discovery and service discovery will not be used
+> * nsd will be used opportunistically, but without resolution, which is broken on all devices
+>   * rationale: nsd works on some android devices where other multicast protocols (eg lsd) don't work
+> * in future we might also want to use another multicast protocol in parallel with nsd, for easier interoperation with other platforms, but we don't need that at this stage
+> 
+> plan for bluetooth:
+> * publish a gatt service, open an rfcomm server socket, open an l2cap server socket if available
+> * advertise the service uuid
+> * connect to any discovered peers via gatt
+> * fetch peer's peer id and transport info: l2cap psm, rfcomm address, maybe other transports
+> * decide whether to switch to l2cap or rfcomm or continue with gatt
+> * if continuing with gatt, use allocator characteristic to wait for a connection slot
+> * if using rfcomm, use bro mode to discover own address, which can then be included in own transport info
+> * transport info is fetched via gatt because many older devices don't support scan records, and space in the scan record is very limited
+>
+> plan for wi-fi direct legacy mode:
+> * we only use the wi-fi direct api for connecting to hotspots (client must have api >= 29)
+>   * rationale: this avoids the soft ap attack
+> * hotspots are only started on demand
+> * if two peers are connected via a non-lan transport, they determine whether it's possible for one of them to start a hotspot and the other to connect to it, or whether it's possible for one of them to connect to the hotspot that the other is connected to
+> * if so, a hotspot is started if necessary and hotspot creds are exchanged via the existing transport
+> * if not, the peers keep each other updated about their status and may try again later
+> * use nsd to discover other peers connected to the same hotspot
+> * disconnect from the hotspot when all connections have been idle for some time
+> * stop the hotspot when all clients have disconnected
+> 
+> non-plans for wi-fi direct legacy mode:
+> * providing a hotspot while connected to a hotspot (or a normal access point)
+> * sharing creds for normal access points
+> * manually created hotspots (which share the device's internet connection) are treated as normal access points and we don't connect to them automatically
+> 
+> plan for nsd:
+> * encode the ip address and port in the instance name so we don't need to use resolution
+> * probably don't bother with attributes, as they aren't supported on older devices and we're going to connect to every discovered peer anyway, so we can exchange the info after connecting
+> 
+> plan for normal access points:
+> * if two peers are connected via a non-lan transport, they exchange their lan ip addresses and ports and try to connect to each other
+> * this allows peers to connect via lans that don't support multicast but do allow clients to connect to each other (or where multicast is broken on one/both devices)
+>
+> what could we potentially gain by adding wi-fi direct service discovery? we can't connect to wi-fi direct services without user interaction. we don't know our own ble address, so i don't think we could make a gatt connection to a peer discovered by wi-fi direct service discovery (to work around issues with ble advertising being broken on some devices). likewise for l2cap. we could advertise our rfcomm address, if known, and our lan ip address and port, and the creds for any hotspot we're currently providing or connected to
+> 
+> overall this doesn't seem very compelling, bearing in mind the energy cost and possible stability issues with constant service discovery. but it might perhaps be useful as an extra manually triggered type of scan
+> 
+> the devices that are likely to do worst under this plan fall into two groups:
+> * devices that don't support ble advertising, as mentioned above - hopefully these are all older devices that will die out eventually
+> * devices running android 8.1 or 9:
+>   * they don't have access to their own rfcomm address, except via bro mode
+>   * they don't support l2cap (some newer devices don't support it either)
+>   * they can't connect to hotspots due to the soft ap attack, but they can run hotspots
+>
+> prospects for interoperating with other platforms (as far as i can tell):
+> * ios:
+>   * bluetooth: gatt and l2cap should work, rfcomm won't work
+>   * nsd: should work
+>   * other multicast protocols: unknown
+>   * wi-fi direct: won't work
+> * windows:
+>   * bluetooth: gatt and rfcomm should work, but would require native code (privileged?)
+>   * nsd: probably won't work
+>   * other multicast protocols: should work
+>   * wi-fi direct: unknown
+> * linux:
+>   * bluetooth: gatt and rfcomm should work, but would require native code (privileged?)
+>   * nsd: should work if avahi is installed, might require native code
+>   * other multicast protocols: should work
+>   * wi-fi direct: should work if hardware supports it, but would require privileged native code
+> * macos:
+>   * bluetooth: gatt and rfcomm should work, but would require native code (privileged?)
+>   * nsd: should work
+>   * other multicast protocols: should work
+>   * wi-fi direct: unknown
+> 
+> the plan above can be implemented incrementally, starting with gatt. but if we want to interop with desktop platforms, we need to look into what's required for doing ble advertising and gatt (or rfcomm) on windows/linux/macos
+> 
+> this project provides a c api for ble on windows, linux and macos, so we could try accessing that via jna:
+> https://github.com/OpenBluetoothToolbox/SimpleBLE
+> (as far as i can tell the primary api is c++ but there's also a c api)
+> 
+> only seems to support operating as a central: https://simpleble.readthedocs.io/en/latest/simpleble/tutorial.html
+> 
+> looks like blessed-bluez only supports operating as a central too
+> 
+> the macos native api supports both modes. there are sane-looking native apis for rfcomm on windows and macos
+> 
+> for rfcomm to be useful, we need ble advertising or scanning (ideally both, otherwise we can't make desktop -> desktop connections)
+> 
+> on second thoughts, if the rfcomm api allows making the device permanently discoverable then we could do desktop -> desktop connections via rfcomm, although it's not ideal to do classic discovery constantly as it supposedly uses a lot of energy
+> 
+> so the plan would be something like this:
+> 
+> * ios:
+>   * use ble as the main transport
+>   * use nsd and perhaps another multicast protocol opportunistically
+>   * connections to legacy mode hotspots and other access points would probably be manual
+> * windows:
+>   * use ble in central mode (via simpleble) for discovering and connecting to android, ios and macos (but not vice versa!)
+>   * maybe use rfcomm for discovering and connecting to windows and linux (needs native code, sane api)
+>   * use a non-nsd multicast protocol opportunistically
+>   * connections to legacy mode hotspots and other access points would probably be manual
+> * linux:
+>   * use ble in central mode (via simpleble or blessed-bluez) for discovering and connecting to android, ios and macos (but not vice versa!)
+>   * maybe use rfcomm for discovering and connecting to windows and linux (needs native code, no sane api)
+>   * use a non-nsd multicast protocol opportunistically
+>   * connections to legacy mode hotspots and other access points would probably be manual
+> * macos:
+>   * use ble as the main transport (needs native code for peripheral mode)
+>   * use nsd and another multicast protocol opportunistically
+>   * connections to legacy mode hotspots and other access points would probably be manual
+> 
+> the situation for desktop isn't great, especially when there are no mobile devices nearby. but that's the same issue we're already facing with briar
+
+avon replied with:
+> Running a peripheral on Linux is definitely possible using the python bluez library: https://github.com/bluez/bluez/blob/master/test/example-gatt-server
+> 
+> I didn't realize the blessed library didn't support this though. 
+> 
+> I'll look into it a bit more when I get a chance
\ No newline at end of file