Peer to peer operations

[Billy Bones]

Hi guys!

Does someone already worked with peer to peer applications?

I'm quite familiar with Bittorrent protocol on Desktop platforms like Linux and Mac OS but I thought it would be fun if Android could support it natively on the framework rather than having to use or create a third party library/framework to implement it anytime you create a new project.

Wifi Direct is one option that I explored, but it's not really usable anytime and do not provide a really unified and standardized approch as it mainly focus on devices to devices interactions where I'm rather interested on apps talking to apps or apps talking to devices.

I know that Bittorrent protocol himself is considered as closed sources but the company released the BTP/1.0 RFC long time (around 90's/00's) ago and it's the basement of a lot of open sources programs, so I consider it as a pretty strong, largely adopted and quite useful de facto standard for many projects.

For those of you which would be interested by why a P2P Framework should be available on android, here are some topics that I'm exploring right now:

- Home automation without additive and invasive installation.
- Operating Systems privacy, communication and extends.
- Interactivity for telepresence on museum, meeting rooms etc.

I know that this topic/question is a little bit messy, but I think that it would be a great discussion and permit me to order my thought and projects by reading your feedback on this.

Regards,
Billy.

[David Cowden]

I'm not sure how Bittorrent precludes any of those use cases.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

[Billy Bones]

Indeed, I'm rather advocating the peer 2 peer communication method, bittorrent is just an example of highly available and usable protocol.

For example, on the home automation topic, if you've got lights bubbles, button, coffee machine, tv etc which are all using standard communication bus like BTLE or WifiDirect etc, you can seamlessly make a peer to peer network where everyone is aware of each other and where your mobile is part of this management network.

having this standard communication bus associated with a native peer to peer APIs on the mobile will grant developers to develop management apps and projects with ease as everyone talk the same language on top of widely supported communication bus.

On the operating system side, this would allow a decentralized services plateform, providing a real alternative solution to Internet giants services providers.
I know that it could be somehow nasty thought regarding Google's implication on Android and in terms of business, but solutions exists and it's not to point of this topic.

Finally, regarding the telepresence etc, as for home automation wouldn't be cool to have a big screen a the entrance of the museum which talk natively with your phone and then provide you useful information regarding your visit, the most interesting path according to your settings, answering your questions quitely by text (Notifications / hangout / other) or through your headphones without having to install another boring application?

well, I don't know if I addressed your concerns, but keep me inform or let me know if you want deeper sketchs/schemas/infos.

[Paul Gardner-Stephen]

Hello,

The Serval Mesh is open-source software that aims to provide true peer-to-peer communications between Android devices.  This is rather frustrated by the lack of real peer-to-peer communications options on Android.  Ad-hoc Wi-Fi, for example, continues to not be supported on Android.  iOS now has a peer-to-peer communications facility, which we are also looking into.

Paul.

[Billy Bones]

Well, that what I'm talking about, the lack of integrated/native/whatever solution on Android to perform real peer to peer communication.

As I said it earlier, I know how to implement bittorrent protocol on top of wifi/IP communication but as you point it, it's too restrictive as it only rely on one bus where all smartphones can at least use three.

I'm wondering if integrate a more standard and generic solution to be able to perform peer to peer communication on Android without having to care about protocols and communication bus would be a good solution.

That why I post this topic, I'm deeply interested to expose my point and have returns of fellows developers.

About me, peer to peer communication is a relatively low level network interaction and should be taken in consideration as other standard network communication.

I want to be able to have a workflow like this right on my Android Framework:

1°/- Communication Bus availability checking (Find out which support of communication is available).

2°/- Communication Bus selection.

3°/- Networks availability.

4°/- Subscription / Authentication / Authorization and Advertisement on a specific network or a list of.

5°/- peer to peer communication on the application layer.

It may sounds crazy or irrelevant, but as I exposed it earlier on my example, it could help a lot on different topics and address numerous issues regarding latency, security and so on.

Waiting for your answers and point of view!

--
You received this message because you are subscribed to a topic in the Google Groups "android-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-platform/eq5Hwk-6lZs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-platfo...@googlegroups.com.

[Oļegs Briška]

A while ago I was researching a possibility to implement a WS-Discovery protocol on an Android and quickly realised, that a battery-powered mobile device can only be used to ping devices at certain specific moments, e.g., device discovery. However, these devices cannot listen network messages for a prolonged time and hence cannot be searched by means of WS-Discovery or any other pro-active discovery protocol due to high power demand of communication equipment. In other words, whenever you power up a WiFi chip, you burn your battery life by a lot. There are other means of network discovery already available in the Android API, but availability of these protocols depend on your network infrastructure.

 

That said, peer to peer protocols heavily depend on avalability of network nodes, which is very hard to achieve using battery powered devices, like phones and tablets. I think you should solve your problems using some server side thechnology, e.g., Google Cloud Messaging rather than running BitTorrent or whatever daemons on Android devices.

[Billy Bones]

Hi Oleg, thanks a lot for your really interesting example, it's crystal clear and you make a point! I'll had this "problem" on my technical barrier list.

On the other hand, to improve battery saving, you can rather choose to use BTLE solution instead of the Wifi one, as it's more energy savior, but yeah you've catch something on the energy topic.

I've also think to implement a sort of location aware algorithm specially made to save a lot of battery by "pinging" location times to times and then activate the adequate communication bus depending of the answer.

Here is an example:

1°/- The device emit a ping on Wifi/BTLE/Other communications bus each hour during a whole week and inspect the energy behavior habit of the user during this period.

2°/- Depending of the answers, it map the available "gateways" and ask the user to grant or not those connection endpoints as "activator locations".

3°/- Depending of the energy comportment on those "activator locations" during the week analysis period the device can provide suggestions to the user to rather grant or not the bus activation.

4°/- Suggestions and/or user settings are override in case of the battery saving agent threshold is triggered on the device (~15% on Android 5.0 if I remember).

Anyway, this setup is a little bit out of range but can't help to go forward on some issues and improve the discussion.

About Google Cloud Messaging etc, yes, it would works to, but, as I wrote, I'm also deeply concerned by data ownership and protection, that why I rather prefer to use real peer to peer communication rather than a centralized or even server centric solution.

I'm glad that some of you folks take time to answer on this topic as your answers are really positives and help me a lot to build my thoughts and by extension projects.

Le mer. 18 mars 2015 à 14:53, Oļegs Briška <gum...@gmail.com> a écrit :

A while ago I was researching a possibility to implement a WS-Discovery protocol on an Android and quickly realised, that a battery-powered mobile device can only be used to ping devices at certain specific moments, e.g., device discovery. However, these devices cannot listen network messages for a prolonged time and hence cannot be searched by means of WS-Discovery or any other pro-active discovery protocol due to high power demand of communication equipment. In other words, whenever you power up a WiFi chip, you burn your battery life by a lot. There are other means of network discovery already available in the Android API, but availability of these protocols depend on your network infrastructure.

 

That said, peer to peer protocols heavily depend on avalability of network nodes, which is very hard to achieve using battery powered devices, like phones and tablets. I think you should solve your problems using some server side thechnology, e.g., Google Cloud Messaging rather than running BitTorrent or whatever daemons on Android devices.

--

[Paul Gardner-Stephen]

Hello,

You are quite right that the power consumption is a big problem -- especially when using Wi-Fi because just listening on a Wi-Fi channel consumes a lot of energy.  We have a PhD student here looking at some possible solutions to this.

Of course, the question must also be considered as to whether communications for a few hours is worse than no communications at all.  The answer varies on your situation.  In a disaster zone, those few hours of communications can be literally life-saving.  This is why I am not satisfied with Android failing to incorporate any option for true p2p radio communications (wifi or otherwise).

Paul.

[Kristopher Micinski]

What kind of peer to peer communication do you want to do that you
can't piggyback on top of GCM anyway?

Reimplementing something that is always connected to the internet is
probably the wrong way to go: GCM already does this anyway. The
protocol for push notifications is set up to do this. If you want to
ferry larger amounts of data across, the traditional way is to store
them on a server and have a protocol where you push a notification
from one client to the other with a continuation (link) to get the
data from the server.

Doing "real" peer to peer, as other people pointed out, isn't really
reasonable for Android devices. Turning on another radio sucks
because it kills the battery. But I think a ton of use cases fit into
the model where they can survive simply using GCM as their backend.
This is definitely the model that Android has been optimized to
handle.

Kris

> --
> You received this message because you are subscribed to the Google Groups
> "android-platform" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[David Cowden]

Well, I think the ask is for platform support for a protocol that can be used in the event that a centralized service such as GCM is not available. Whether it's a good idea for apps to use it frequently or not seems orthogonal to the merit of its existence from a technical perspective. I disagree that bittorrent needs to be the implementation, but I sympathize with the request for a native p2p communication mechanism.

[Kristopher Micinski]

Ah, I see.

It's possible that one should be supported, but I think for various
infrastructural reasons it would be hard to pick up steam. E.g., most
apps are written under the assumption that there will be some cloud
service through which they communicate. For better or worse, this
model seems to have won for now.

I worked on the implementation of a P2P protocol through local wifi,
where you simply addressed machines and had some ad-hoc DNS mechanism.
It was sufficient for a research environment, and I could see
something like that working for a focused application, but I don't see
such a thing gaining widespread use from apps. E.g., I am not aware
of many app developers using the wifi direct APIs,
http://developer.android.com/guide/topics/connectivity/wifip2p.html

There was some attempt to develop some APIs for this (e.g., AllJoyn by
Quallcom), but I don't think there was ever really sufficient steam to
get people using it.

Kris

[Paul Gardner-Stephen]

For me the use-case is disaster, remote and developing world use where for a variety of reasons devices may be cut-off from any global communications network.

In such environments the battery draining nature of true P2P communications is secondary to the need to actually be able to communicate.

Wi-Fi Direct does not allow formation of large networks.

Paul.

[Kristopher Micinski]

What limits wifi direct from establishing large networks? Typically
in these situations you'll have a sort of MANET or DTN routing
protocol overlaid on top of a mesh topology anyway (e.g., AODV), since
presumably the nodes won't have full connectivity.

Previously, I've implemented an AODV-like thing using Bluetooth, but I
would suspect that wifi direct would provide a lot better support for
doing so.

Kris


On Fri, Mar 20, 2015 at 4:18 PM, Paul Gardner-Stephen

[Billy Bones]

Hi guys, I'm sorry for the late, I had a quite busy week :D

Well, the whole point with the p2p communication, as pointed it many folks here is not primary to avoid central servers (although, regarding the recent events I'm not so enthusiast to give my data to Google and so on.) but to allow optimized communication in some specific cases.

As I pointed it out, I have some project which are real and already use my own implementation of this on top of android, those projects are real cases and already in use on clients sites.

My point here, (and regarding the answers I'm not the only one concerned of that question) is to know:

1°/- If it would be interesting to a sufficient amount of people to drive and init some integration natively on the Android Framework.

2°/- What kind of issues and problems my peers developers had to face on this particular topic and how did they resolved them.

About Wifi Direct (and wifi generally):
It's a great support on controlled environments with large bandwidth needs, but on the other side, it's not really energy efficient and can drastically drain your batteries, on the other hand we've got BTLE which is awesome for energy saving regarding any other communication support but suffer from a low bandwidth and the necessity to pair each devices one by one.

One my previous example, all the communications are relatively short and do not need for a large bandwidth, I've not been really focused on real heavy network exchange but I know that our main problem on this side will obviously be the batteries/energy issue.

However, I'm not only focusing my projects on Android for mobile users but widely on projects based on Android would it be for mobile or other emerging supports.

For example, I've got a Cubieboard 4 here equipped with android 5.x which I use as a "server" with my own p2p apps to test p2p communications, and it's running smoothly by know, BUT I'm on a quite well controlled environment etc.

I deeply think that implement natively an easy way for developers to use p2p communications will drastically improve the usage of it and the amount of apps using it.

And when I'm talking about p2p I'm not only looking at Wifi or BTLE support channel, but a wider solution using ANY communication channel available like 3G/4G etc.

> email to android-platform+unsubscribe@googlegroups.com.
> To post to this group, send email to android-platform@googlegroups.com.

> Visit this group at http://groups.google.com/group/android-platform.
> For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "android-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-platform/eq5Hwk-6lZs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to android-platform+unsubscribe@googlegroups.com.
To post to this group, send email to android-platform@googlegroups.com.

[Dallas Singletary]

I suggest taking a look at apps like Open Garden and FireChat by OpenGarden. Look at the way these apps implement P2P in a way it doesn't drain your batter and allows for some what Medium bandwidth needs

[Billy Bones]

Thanks a lot for your apps example, I'll take a look at the way they energy drain.

Still, the problems of native integrations and standard/universal library remain.

To unsubscribe from this group and all its topics, send an email to android-platfo...@googlegroups.com.