
Ask HN: How does firechat accomplish mesh networking? - notastartup
I was very impressed when I tried it out on the Android. I can&#x27;t help but wonder, how did they manage to solve the problem of peer to peer mesh networking between iOS and Android devices? They are mum on the whole thing.<p>Alljoyn SDK seems to offer same feature but not sure how different they are compared to Open Garden&#x27;s technology.<p>I&#x27;m just throwing this out to see if it&#x27;s possible to pull off what firechat is doing in terms of their cross platform p2p peer meshing capabilities.
======
jackmec
At first I thought along with others that they're probably relying on some
combination of Bluetooth and Wifi. When I launch FireChat though, it tells me
that to use the chatroom that does not require Internet, it only works "up to
210 feet." Well, that's interesting because Bluetooth LE should work up to
over 300 feet. If we're talking about two users on the same WiFi, they should
be able to chat for as far a distance as that WiFi network, which again should
be greater than 210 feet, depending on the system. So, if they're using a
combo of WiFi and Bluetooth, how do they end up with a shorter distance?

~~~
notastartup
I would like to know this as well. I am very curious to know how they are able
to do this with both bluetooth and wifi

------
pdx
I'm excited to know this exists. I've been watching the Serval Mesh project
for awhile.
[https://play.google.com/store/apps/details?id=org.servalproj...](https://play.google.com/store/apps/details?id=org.servalproject)

But it requires rooting your phone. This is very cool, and I hope it becomes
ubiquitous, as a method of circumventing the grid, either because it's
compromised or it's down, or it's just not present to begin with, is huge.

------
lsh123
It sounds pretty straightforward for WiFi: you have two devices connected to
WiFi on the same network. These two devices can broadcast to let each other
know that there is someone else there. After that, the IPs are known and
devices can talk to each other. There is nothing platform specific in this
model: standard UDP and TCP, nothing more than that.

I am not familiar with BT protocol so I can't comment on how it is done with
BT.

------
chatmasta
I've researched this area and there are a few issues to be aware of. First of
all, it's important to note that Android does not have the same built in "off
the grid" networking that iOS recently introduced. So, as OpenGarden stated on
Techcrunch, Android clients rely on some combination of Bluetooth and wifi.

Second of all, a common issue with implementing peer-to-peer networks is NAT
traversal. Because the internet has more devices than it does IPv4 space, it's
segmented into siloed networks (NATs), each with it's own IP space. So
connecting two peers is nontrivial, because the public address of one might
mean something totally different to another. To accomplish peer to peer
tunneling, you need some kind of intermediary to coordinate the addressing.
Because of that, many p2p applications require changes to router/firewall
rules to solve the addressing problem. Obviously this is suboptimal,
especially on mobile. But recently, Google has made a lot of strides in this
area with it's technology underlying Google Talk and WebRTC. This tech,
encapsulated in a library called libjingle, relies on the STUN and TURN
protocols for intermediary servers to coordinate addressing between peers. For
92% of devices on the Internet, the STUN servers are able to coordinate
addressing between peers without having to relay any of the data. For the
other 8%, TURN servers sit in between the peers and relay data. This is the
technology that enables Google Talk and WebRTC to be so scalable. When 92% of
bandwidth can be offloaded to peers, there's much less of a need for central
servers and bandwidth.

Now consider that any p2p IP tunnel can be opened between two devices
connected to the Internet, using this STUN/TURN protocol via something like
libjingle. (See socialvpn.org for an example.) This tunnel can be a generic
transport, or it can act as a UDP proxy (I believe this is how Hola! Chrome
extension works).

You now have the ability to create a p2p overlay network, with direct tunnels
between peers, on top of any Internet or generic network of devices. The key
component is libjingle along with STUN and TURN servers, which enable direct
p2p addressing.

My hypothesis is that OpenGarden used some combination of all these
technologies. I think the reason they're quiet about how they accomplished it
is because, 1) Android probably doesn't work as well as iOS in sparse offline
areas (not enough Bluetooth parity), and 2) they are relying to some extent on
central servers, for the TURN/STUN protocol.

That's just my hypothesis, and I've never actually implemented anything with
this technology, but rather have only read about it. If someone wants to
correct me on any number of the points I'm sure I got wrong, please do.

