Hacker News Reader

Hm, you are conflating a few things there. Bluetooth "scatternets" were first of all never standardized, AFAIK, but had to be implemented in the application layer, which led to vast incompatibilities.

Bluetooth profiles, and vendors restricting their devices to sport only certain profiles, are a good thing for compatibility, since it ensures (if done correctly) that devices (i.e. applications in fact) from different vendors can talk to each other.

"WiFi direct" is yet another completely different thing, that is meant for peer-to-peer connections (note: two communication partners) without needing an AP, which 802.11 consumer standards (b,g,n,ac) all did and do otherwise.

Also this standard has nothing to to with flash-mob gaming, and won't allow for it. This is AFAIK meant as a standardization of several so far vendor-specific efforts to extend networks through the use of several APs (similarly to how repeaters were used). Still a good thing, because it is no longer vendor-specific if my devices support the standard.

By expecting mesh networking to solve your applications needs you are IMO skipping a few layers in between. You want ad-hoc, high throughput mesh networks, stateless auto-configuration, service discovery, and quite a few other things regarding routing, QoS and flow management as well as connection management (reliability, multicast?)...

This is not the standard you are looking for. For now you would need to look for solutions in the application layer IMO.

> "WiFi direct" is yet another completely different thing, that is meant for peer-to-peer connections (note: two communication partners) without needing an AP, which 802.11 consumer standards (b,g,n,ac) all did and do otherwise.

Wi-Fi Direct is nothing more than running (e.g., 802.11n) software AP with WPS on one device ("Group Owner") and having (multiple) peers connect to it to form a "group" -- it's just a normal AP, you can even connect legacy Wi-Fi devices to it. It does add functionality to automatically negotiate which device becomes the access point and to do some service discovery on the link layer before connecting.

The way you just described WiFi Direct sounds closer to true mobile-to-mobile mesh connectivity than what is described above. WiFi Direct allows nodes to trade off AP duties; EasyMesh allows nodes to optimize AP selection; scatternet allowed (if I recall correctly) multi-AP piconet connections over Bluetooth, using application layer as a workaround for inadequate link-layer protocols. ... But I wouldn't say it's like comparing apples & oranges; more like comparing Newtons & Macintosh. It seems obvious to me that they approach the same challenge (flexible connectivity) from different directions, but if you have time, please clarify how these three protocols are substantially different in purpose?

The problem with WiFi Direct is that all its local mobile-to-mobile capabilities are disabled if the group doesn't have a node connected to a tower at all times. For example, you can't have three devices up in the mountains exchange files or messages, unless one of them can get the OK from a service provider's tower. WiFi Direct stops as soon as you lose cellular signal or experience a service timeout. It's crippled by design.

EasyMesh doesn't seem to offer any neighbor-to-neighbor utility; It appears to be focused solely on expanding coverage of single-point-of-control networks which are already overcrowded (hence the need for so many range extenders). When are we not in range of half a dozen or more WiFi networks?

I see adding more APs as an exercise in futility. The primary issue is overcrowding, not signal strength. Remove all the other nearby networks & one router easily reaches across most buildings.

Sorry, I guess that's two topics in one comment, but I'll repeat my primary question: In what way are these different approaches "completely" different? They seem to all be chasing roughly the same goal. I also feel that "mesh" has stagnated due to lack of hardware support (& accompanying lack of open source firmware).

(Replying because I can't Edit, for some reason...)

I'M SORRY! I was thinking of LTE Direct, which is crippled by design. Please disregard my statement about "WiFi Direct" needing a cellular tower.

Wifi direct exists independent of cell phones. There's even a windows 10 protocol adapter for it. The phone implementation could be terribly broken, but the standard says nothing about 4G connectivity or go-ahead (as it shouldn't!).

16 years after that grand dream of ubiquitous personal mesh networking, and still today given a top of the line pair of headphones and a top of the line computer, the two will still reliably fail to communicate for some subset of users.

Nice try blaming it on political pressure, but I'd call it sound engineering! "Let's get the simple stuff right before we discuss the support costs of making mesh work over this junk"

I'm in complete agreement with your comment. I have yet to see a sane looking bluetooth implementation. I think OpenBSD even dropped it entirely due to it being a hacky mess.

Thing is that bluetooth kinda clash with the unix /dev concept.

Because each pairing is effectively a new device in /dev, and doing anything with bluetooth require that one cross the user/root divide multiple times.

Holding a stack that can handle losses (TCP/IP) to the same standards as bluetooth audio is silly.

We're talking about a max 72KiB/sec connection (AptX HD) at one meter range between 2 peers, parent comment refers to flash mob gaming on a bus. A modern London bus seats 62 over a 11.23x2.52x4.39m area surrounded by numerous metallic partitions in a continuously changing RF environment (driving through a city).

Assuming audio between 2 peers at 1 meter was somehow a solved problem (per above it's not), and collision avoidance was a non-issue (problem worsens exponentially with additional peers), that's 1.16KB/sec in some idealized non-existent reality of bandwidth to run a compelling game for 62 people. Perhaps parent comment refers to a flash mob game of Chess.

Assuming Bluetooth only reliably fails between two peers 1% of the time (oh, but to dream), that's a 99%^62 = 5.36% chance of a bus full of people successfully joining a single mesh.

Silliness is in the eye of the beholder!

99%^62 = 53.6%

Out by an order of magnitude but your point still stands.

What do you mean? 0.99^62=0.53626

Yes, which is 53.6%, not 5.36%.

Not to mention AptX HD is a proprietary audio codec. Many (most?) phones don't support it.

> Now that bluetooth has returned to its roots with Bluetooth Low Energy, maybe we have another chance at flash-mob mobile gaming - everyone on the same bus can join in to a chatroom or a roleplaying game for the duration of the ride.

Note that the Nintendo 3DS effectively has this capability. I believe it's all WiFi-based.

Yes. Even the original DS had this with pictochat.

the biggest value of Bluetooth, to me as a user, are the profiles.

This means that there are baked in standard ways for devices to communicate.

Damn it, back in the day i had a Nokia N800 going online via a SE featurephone, while listening to music via Jabra headphones from the same phone, and typing comments on various forums using a folding keyboard paired with the N800.

Available since iOS 7 https://developer.apple.com/documentation/multipeerconnectiv...

I was working on a private mesh standard for a startup a few years back because of a perceived opportunity resulting from the fractured nature of the ecosystem, resulting in no devices really using mesh. We have Bluetooth mesh, Wifi mesh standards, Thread, Alljoyn, and plenty more, but no one is benefitting from any mesh protocols in day to day life.

Some of these standards are decent technologically, but the real problem comes down to device drivers. Most wifi/bluetooth devices have drivers (and sometimes firmware, too) which are completely inflexible in sending out frames outside of their standard protocols. This is especially difficult with the abstraction layers programmed into the firmware and the fact that very different hardware is used to share spectrum (to optimize for time hopping on bluetooth, for example).

The solution: adoption of a standardized, Linux-like driver protocol for enabling custom frames to easily be sent and received on shared spectrum BEFORE adoption of the protocols built on top.

That being said, augmenting the Wifi standard to support mesh is probably the closest development to that goal that I've seen in a while, since vendors typically start supporting the new 802.11 standards pretty quickly.

The biggest problem with mesh networking is that the word “mesh” is used for many different things involving self configuring network devices.

Any use of the word “mesh” online invites commenters who, not having RTFA, will opine endlessly based on an incorrect understanding of a completely different use of “mesh”.

Agreed, I feel that "mesh" has been reduced to a buzzword akin to "web" 10+ years ago. In particular, this usage of it for EasyMesh begins to feel like a misappropriation. Unfortunately for anyone concerned with clarity, the term describes a topology, not which layer it is implemented on.

I constantly find myself using qualifiers like "hybrid mesh cellular" (doesn't exist due to hostile regulation), "link-layer optimization for mesh processing", & "app-layer mesh protocols for decentralized Directed Acyclic Graph consensus". "Mesh", "matrix", "net", & "web" are all terms which are virtually interchangeable in contexts outside the IT realm. "Star" most accurately describes the topology of most people's single-AP WiFi implementations, yet the term is deprecated due to association with a specific old protocol nobody's done much with in thirty years, as far as I know.

The whole thing is a linguistic nightmare, from anything but a marketing perspective (marketing loves conflation; it's one of the industry's primary tools).

EasyMesh protocol finalization looks like great news for installers & WiFi network admins, but I expect the new range extenders it enables to make the overcrowding situation worse, not better.

If it doesn't enable peer nodes to communicate without a centralized point of control, I'd vastly prefer the term "mesh" not be used at all.

From Wikipedia: "Wi-Fi Direct allows two devices to establish a direct Wi-Fi connection". That's not mesh networking though. You could build a mesh on top of it, but the main purpose seems to be very single-peer-2-single-peer.

And you still have to hope the two devices have a sane protocol between them to layer on top of the wifi...

Well, if I compare Bluetooth (often doesn't work for no apparent reason) to WiFi (works, and when it doesn't there are comprehensible reasons) - this one might actually work. Mesh networking is very hard to do right so I can imagine how well Bluetooth's attempt worked. Probably might as well not have it at all level.

Edit: I was thinking of more dynamic and larger meshes - those are really hard. This standard seems to have a smaller scope. It's still more difficult than one-to-one.

>another mesh standard

Standards!

https://m.xkcd.com/927/ ;)

> flash-mob mobile gaming - everyone on the same bus can join

This can be already delivered without mesh networking. Too many privacy issues.