Apple

Kevin McQuown
CPO & Co-founder
Deck5 Software, Inc.
53 W. Jackson Blvd. Suite 450

Chicago, IL 60604

On Nov 11, 2013, at 8:30 AM, András Kövi <email@hidden> wrote:

Say you have a bipartite graph (http://en.wikipedia.org/wiki/Bipartite_graph) where the nodes are the roles of devices. A device with role can be Peripheral or Central (and the same node can implement both roles but this is still visualized as two nodes). One group is constituted by the peripherals, the other by the centrals (U and V in the image) There are edges (connections) only between U and V points. As long as you look at a single central, it will look like the center of a star graph where the leafs are the peripherals. But the same applies to peripherals. :) This is all to it.

Building a mesh is possible by using just single role nodes or nodes that implement both roles. Say you want a chat system:

With single role devices: you create clients (centrals) and servers (peripherals) and the clients communicate with each other over the servers
With dual role devices: you create a bittorrent architecture

(Disclaimer: the example is made up for demonstration purposes with lots of details not considered and discussed here)

Andras

2013/11/11 Kevin McQuown <email@hidden>

So, I’m curious what this means for a collection of devices communicating with each other. The Bluetooth specification states the it conforms to a “star topology” which I completely understand given the client and peripheral modes. If every client can also be a server and visa-versa, then, does this mean that devices can be combined in a way that is more like an adhoc “mesh” network rather than conforming to the stricter star topology?

Kevin McQuown
CPO & Co-founder
Deck5 Software, Inc.
53 W. Jackson Blvd. Suite 450

Chicago, IL 60604

http://about.me/iitgrad

On Nov 11, 2013, at 7:10 AM, András Kövi <email@hidden> wrote:

If you stick to a networking example, the central is the socket that starts the connection and the peripheral is the listening socket. Only a server socket and and a client socket can communicate with each other. Consequently, there exist only central-peripheral connections.

But the central and the peripheral roles can happily live together in the same device. (You can open listening and connecting sockets on the same device.) Your peripheral (be it an iOS device or anything else) can be a peripheral that exposes services and central that connects to other peripherals.

Most of the confusion comes from the unfortunate naming scheme. The BLE peripheral could have been Server and the BLE central could have been Client. The peripheral word is overloaded with the role and the device meanings that makes things hard to reason about for people with little or no BLE knowledge.

2013/11/11 Walter Stephan <email@hidden>

> No. While a service is in the database, any connected central can
> access, but it doesn't make sense for another peripheral to access.

Why not? As a central device, iOS publishes the Battery Service, Time Service and ANCS. I think it would be useful if my app can publish a proprietary service to connected peripherals.

> One
> way of thinking of this for those more used to HTTP is that central =
> client, peripheral = server. Servers do not connect to each other;
> servers listen and clients connect to them. However, the same device
> (the iPhone) can run both a client and a server at the same time.

As far as I understand the BLE spec, a central can act as a GATT server (and a peripheral can act as a GATT client).
I would like to know if this is possible to implement on iOS.
I am aware that it may not be the most straight-forward use case, but it is definitely allowed by the spec.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)

This email sent to email@hidden