|
|
|
Sources:
|
|
|
|
* https://chat.briarproject.org/briar/pl/ndsfz3w6bjfgzfp5cq3pzdpr4a
|
|
|
|
|
|
|
|
avon wondered whether Bramble supports multiplexing:
|
|
|
|
> If anyone knows any resources on multiplexing packets over multiple transport layers I'm looking for some resources on that. Does the bramble layer do something similar?
|
|
|
|
|
|
|
|
akwizgran explained:
|
|
|
|
b> ramble doesn't multiplex packets. the abstraction btp uses is streams, where a simplex transport has one stream (incoming or outgoing) and a duplex transport has two (incoming and outgoing)
|
|
|
|
>
|
|
|
|
> the abstraction bsp uses is records (offer/request/message/ack), which are written to/read from streams
|
|
|
|
>
|
|
|
|
> if a transport offers you a stream abstraction, you can easily turn it into a packet abstraction by using some kind of framing to delimit packets (kiss is a good one if you don't have hard limits on the size of the packet - i think reticulum uses it)
|
|
|
|
>
|
|
|
|
> but turning a packet abstraction into a stream abstraction is harder. you can either add a layer for this purpose (like udt) or try to reuse tcp, for example by passing your packets through a tun/tap driver so the kernel can treat them as ip packets and use its existing tcp implementation. then apps can use the kernel's socket interface (or its bindings in pretty much any language) to interact with the stream abstraction. but this requires root for setting up the tun/tap driver
|
|
|
|
>
|
|
|
|
> vpns often do the tun/tap thing so they can use udp rather than tcp for the outer encrypted layer, which performs better than bundling various applications' tcp connections into the vpn's single tcp connection
|
|
|
|
>
|
|
|
|
> if i remember right, the thali project wanted to use http on top of their bluetooth/wifi/tor transport layers, so they had some kind of local proxy that spoke tcp on one end and bluetooth on the other end, so that everything would be tcp from the perspective of the http layer
|
|
|
|
>
|
|
|
|
> but again, that was a socket abstraction rather than a packet abstraction, as it was using bluetooth rfcomm if i remember right
|
|
|
|
>
|
|
|
|
> oh, something else worth mentioning about the tun/tap approach: if the transport uses very small packets (like ble or lora) then tcp headers will eat up a significant fraction of each packet. so i think you'd want to enable header compression, like you would over a dialup link
|
|
|
|
|
|
|
|
Later on, this evolved into a full-scale planning for "combining various transports":
|
|
|
|
|
