- Comprised of completely free-form agnostic data with two simple rules:
- 236-byte maximum payload size
- Five total transmissions allowed per end-user per minute.
What, besides plaintext can we encode into 236 bytes?
2 Likes
A quarter second of 8kb audio, or most of the new Google logo in scalable vector graphics.
I think SVG is actually very interesting. You can quickly draw very simple line sketches that are extremely small amounts of data.
The mesh protocol can also be useful with the API for a very lightweight BitTorrent style network to sync files during off peak times across the network. That would allow emails to be transferred across large distances for example without having to rewrite tcp/ip for optimizing packet delivery sequences.
5 Likes
This is incredible. Graphics are possible then. I don’t know to what extent, but as long as there’s a possibility…
I don’t know what useful thing we can do with 1.25 seconds of audio (5 messages at a time). PTT may be a possibility.
Can TCP/IP be adapted for this network? There’s a 1 min cooldown. 1KB/min essentially. I totally dig your bittorrent-esque network idea.
Now that I actually did the math. What can we pack into a kilobyte? What markup language is optimized for this?
I’ve got some more math to do. I’ll have more later.
2 Likes
Standard TCP/IP is probably too heavy for this small a bandwidth connection, although GIDs would act as IP addresses, and it would be possible. I’m pretty sure there is another lighter weight protocol for very high latency low bandwidth connections - as in, anything we have ever sent to space before the iPhone. I guarantee our tax dollars have done a lot of research on deep space data protocols. This is what is interesting about a mesh network that is stationary - overnight, or in the background using a low priority, it can sync a relatively large amount of data once you set up the nodes and confirm they can talk. 1k/minute = 480k overnight, which is 250 PAGES of text, or less with text+images+vector maps, etc. This gets interesting for submitting reports from disaster areas, syncing news/wiki articles, syncing emails, etc etc, especially pared with a single internet connection (Satellite etc) somewhere on the network.
3 Likes
I think you and I are on the same track. I started looking at wikipedia stats. Avg word count is nearly 400, but there’s over 2 million articles. I skipped trying to do the math there. So I don’t think replicating wikipedia over the meshnet being feasible, but we may be able to serve it. Surely there’s code out there to compress or cut-down a wiki article to the bare minimums.
That’s a very interesting suggestion. I’m going to enjoy researching early deep space communications.
I’d like to consult an android dev. I know a lot of apps communicate with XML. I wonder what those stats look like. I’m sure they’ve become fairly efficient, but again TCP/IP. I bet we can store a bunch of crap locally whether static designs or cache.
I like the idea of being able to store and propogate things off the meshnet, but accesible through the meshnet. Then we don’t really have to worry about propagating through the mesh. At least not first time nodes or complete datasets. If we ever have to rely soly on the mesh, updates and such should be feasible through the meshnet. The USB SDK is under works and that’s the next logical step is hooking this up to a raspberry pi.
1 Like
I was thinking about this more from the perspective of enabling a more generic, arbitrary transfer of data over the gotenna link. Because the addressing and message acknowledgement (or not) is provided by the radios, you don’t really want something like TCP. Instead you want UDP but with awareness of the delivery ack’s and GUID addressing.
Some interesting related reading:
https://wiki.wireshark.org/SMPP
2 Likes
What if you compress your text documents?
I’m sure we’ll rely heavily on compression. That would be more on the device side and dependent on the content we’re trying to transfer. What we’re trying to figure out now is which protocol to transport the data fits our needs and goTenna mesh the best.
@akraut UDP, of course! x.25 is awesome for this. I think. thanks for these fantastic suggestions. i noticed there’s an x400. still researching all those protocols. all the links on the cisco page are dead. So I took to google. Any suggestions on reference materials?
1 Like
I was just scraping the back of my brain for some of these older radio protocols. X.25, for example, is the basis for the Ham Radio APRS system. (AX.25)
What’s really interesting, though, is that a lot of radio-focused protocols have lots of built ins for detecting lost packets, collisions, retransmissions, etc. But the goTenna Aspen protocol takes care of that for you. It would be really neat to have something that could function like a router:
TCP/IP -> Phone/App -> goTenna Network -> Phone/App -> TCP/IP
However, in the more likely solution, the Phone/App/goTenna Network portion would likely have to all function as a large NAT with multiple exits, which brings in the question of connection stickiness/flapping, etc.
So, the more I think about this, the more I think it might end up looking more like the way Tor works on Android. There’s a “router” application, and then several other apps that know how to talk to it. For example: a slow mapping client. As you move, it asks any internet connected “router node” via goTenna messages for OSM segments around you.
3 Likes
Would something like IPFS, Inter-Planetary File System, make sense for this application?
1 Like
IPFS or similar would be perfect for the back-end filesystem. I don’t think it’ll function too well over the meshnet for the same reasons TCP/IP isn’t a good candidate. It’s great for when we get to the USB SDK under works and these get connected to the internet.
The x.25 protocol @akraut suggested was originally developed in 1976. It’s been revised several times up until 1992 IIRC. Bottom-up design brings us back to our roots 
(and waay before my time 
)
[quote=“linenoise, post:8, topic:1182”]
all the links on the cisco page are dead.
[/quote
use archive.org to see old dead links. Not everything will be there but I have used it a lot to look at old links and I have even managed to get old binaries that way.
One thing I thought was interesting in this bitcoin related talk was how they also want to reduce round trip communication. One technique was to use erasure codes to send data such that as long as some subset of the data was received, you could reconstruct the whole thing.
TCP works by sending data, waiting for an acknowlegement and/or resending missing or corrupted data. The delays for ack and nack hurt you when latency is high. We also want to avoid lots of small broadcasts. Using erasure codes you can instead send in one direction and just include some extra data and let the next node fix any errors.
Perhaps this is relevant for sending data over the goTenna. Not to save on latency, but to trade off between rebroadcasting and adding extra data. I haven’t studied the Aspen protocol they use, but I suspect it does something like this already.
A more way out idea is to use multiple internet gateways, each sending parts of the data to the receiver. As long as some n of m blocks reach the receiver, they can reconstruct the message. If the blocks from different gateways follow different paths to the receiver then you have effectively increase the bandwidth and reduced the latency by spreading it across multiple paths. Since the gateways all communicate over the internet for free, this is cheap for them to coordinate.
Probably not a solution for phase 1, but I thought you might find it interesting.
1 Like
I am not an expert at how this stuff works but would assume the largest scale challenge that the team is facing is limiting the scope of broadcast domain. IE not every message for every device should go to every node in a given geo, else you become bandwidth constrained at a fairly foundational level. Re transmits or not, inefficiencies or not, this is just not a way to scale.
There are algos for this sort of thing. An overlay of overlays comes to mind. IE algos that detect density of network and start to cluster node, with BGP-like announcement of location of a node, are possible. This way the broadcast domain is contained to a local overlay network and does not require every message go to the entire region. This is a well explored area of computer science with ample papers on the topic…but as was eluded to in another thread, is not an easy area of computer science.
This is all easier said than done.
2 Likes
@gtpnwadpt very good point; if I’m understanding correctly, you’re saying that in a high node density situation the long range of the radio could be a problem because they will interfere with each other. I assume to partition nodes you need a way to adjust the broadcast power and/or specific radio bands used. Are there other ways to create clusters?
Maybe you could also do something with allocating different clusters to different time slices, but I can’t see how that would help increase bandwidth.
1 Like
That’s part of it but there are larger problems still. Another part is just limiting # of hops to finite numbers as well as avoiding loops in the network. Imagine a full mesh network that accidentally broadcasts your message from one spot to another that is only 10 miles away ending up 1000 miles away. Think of all the wasted bandwidth (capacity).
Large mesh networks are hard to scale. you end up very bandwidth constrained and the amt of bandwidth is defined independent of the # of nodes in the network, even if you can do things like avoid loops/dupes. Other large scale networks avoid this in certain ways, but GoTenna presumably wants to avoid any sort of central node concept. There are P2P ways of doing this.
Again, I don’t know the GoTenna protocols at all. I’m speaking purely at a theoretical level about the computer science. This is a well explored area of CS.
1 Like