Reduction of Bandwidth/Traffic Consumption

[srkunze]

Is there something we can do about it?

https://github.com/subliun/Antox/issues/6

[xavierle]

I agree with lucco

there shall be a light client for mobile device (with bandwith and battery limitations)

and a full p2p client function for machines with no power or bandwith limitations

Le 28 déc. 2015 17:47, "LuccoJ" notifications@github.com a écrit :

@srkunze As long as it's not written off as a non-issue, though... because the problem is most definitely there for mobile clients, and it was called a toxcore issue that the Antox developer could do nothing about at subliun/Antox#159 (comment)

Without knowing many implementation details, I tend to think that the right solution would be for toxcore to provide a "lightweight" mode of operation, possibly one where it tends to only connect to TCP relays if at all possible, and takes part in the DHT as little as possible. Constant internet usage is simply not acceptable (often for compelling battery reasons even more than data cap reasons) on mobile clients, and mobile clients are very important for any IM service today.

— Reply to this email directly or view it on GitHub.

[aaannndddyyy]

Primarily this issue is about reduction of bandwidth usage if toxcore, which would be beneficial not only for mobile clients.

If gcm is really the only method to push message notifications to a dozing phone, then its use should be optional. The user using Google play as appstore would likely use gcm by default whereas f-dried versions should do without.

But android really shouldn't rely for that feature exclusively on gcm servers...

[LuccoJ]

During the past few days, I have been using Tox on a capped data connection because I'm away from home, and surprise! My 3GB cap was completely eaten in the span of a few days. When I investigated today, it turned out that as soon as Tox starts running, I start having a bandwidth consumption between at least around 5 kilobytes per second with spikes of more than 100. That's... just a little excessive. What the heck is Tox transferring? This is still the case even after I disable UDP and IPv6, which should mean I'm now only using TCP relays...

[LittleVulpix]

On my computer, tox eats about 1.5-3GB per day, with 40% download 60% upload distribution.

The traffic is about ~20-40kB/s in both directions (As in 40-80kB/s in total), with ~800-1200 open connections.

This is with UDP mode on.

I don't necessarily mind but it is a bit crazy when you think about it.

[xavierle]

to my understanding this is due to the server/relay roles of every tox client (as there is no push central server like in xmpp each client is working as a server : checking which clients are connected all the time, and searching for messages to propagate )

this is not a problem for a stationary client ( with electrical plug and unlimited internet)

for a mobile client this is not sustainable for battery and bandwith consumption

i think mobile client for tox shall include lighter client-only functions

such mobile clients would not contribute to the tox network with server/relays functions but i think mobile clients cannot afford to for as p2P servers/relays

i do not know if this have to be included directly in the tox core or in the mobile app

2016-01-04 17:40 GMT+01:00 LittleVulpix notifications@github.com:

On my computer, tox eats about 1.5-3GB per day, with 40% download 60% upload distribution.

The traffic is about ~20-40kB/s in both directions (As in 40-80kB/s in total), with ~800-1200 open connections.

This is with UDP mode on.

I don't necessarily mind but it is a bit crazy when you think about it.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-168728046 .

[LuccoJ]

@xavierle with the current numbers, this is far from only a problem for mobile clients. Many people in the world have capped landline connections, often with caps in the order of 15 to 30GB per month. With the numbers that @LittleVulpix mentions (and which I can roughly confirm), such large caps would easily be exceeded.

Also, "every" Tox client doesn't - or at least, shouldn't - act as a relay: only those where TCP relaying has explicitly been enabled should (for potential legal reasons, as well as bandwidth usages ones, as you don't necessarily want to be relaying messages between third parties under jurisdictions where you can be held liable for them, such as Germany).

[xavierle]

at the end we come to the same idea

there shall be a difference between

:full clients" with relays function (unlimited machines)

:light clients" with client only function and minimum bandwidth recquirements (mostly mobile but not limited to them according tour precisions)

limitation of bandwidth consumption shall concern the light clients family in priority

difference between full client / light client shall be an easy to understand function.

actually i am mostly concerning by the android version.

actual

German law is crazy.... () i suppose in france you can claim internet service provider neutrality protection (translation is not good from french): you are responsible for service only. users are responsible for their own content. ( i am sure deutsche telekom is under such a protection. you cannot claim for the same in germany ?)

Le 4 janv. 2016 18:00, "LuccoJ" notifications@github.com a écrit :

@xavierle with the current numbers, this is far from only a problem for mobile clients. Many people in the world have capped landline connections, often with caps in the order of 15 to 30GB per month. With the numbers that @LittleVulpix mentions (and which I can roughly confirm), such large caps would easily be exceeded.

Also, "every" Tox client doesn't - or at least, shouldn't - act as a relay: only those where TCP relaying has explicitly been enabled should (for potential legal reasons, as well as bandwidth usages ones, as you don't necessarily want to be relaying messages between third parties under jurisdictions where you can be held liable for them, such as Germany).

— Reply to this email directly or view it on GitHub.

[LittleVulpix]

Any laws regarding "legal reasons" will not apply to tox. You cannot be responsible for any content your client may be relaying because the whole point of tox is that no-one else is able to determine what is being sent/received. They might see IP addresses and that there is traffic, but they cannot see or decrypt content. So you cannot be held responsible because no-one will know what your client is relaying :p

How scalable is tox anyway? Will this only get worse when more people join the network? Or will it get better?

[xavierle]

i have heard that germany is not so sweet for p2p usage. in germany, there are lawsuits for p2p sharing persons because they relay prohibited data. the german iser may be referring to this kind of lawsuit

but it is true that tox encryption shall mask all that

Le 4 janv. 2016 19:05, "LittleVulpix" notifications@github.com a écrit :

Any laws regarding "legal reasons" will not apply to tox. You cannot be responsible for any content your client may be relaying because the whole point of tox is that no-one else is able to determine what is being sent/received. They might see IP addresses and that there is traffic, but they cannot see or decrypt content. So you cannot be held responsible because no-one will know what your client is relaying :p

How scalable is tox anyway? Will this only get worse when more people join the network? Or will it get better?

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-168753887 .

[LuccoJ]

@LittleVulpix in theory, the very same thing that you said is true for RetroShare (the system that created a court precedent in Germany). But in practice, if authorities get a hold of content (such as Tox logs) from computer A that was sent from computer B, they can (from ISP logs, for instance) find out that it was relayed through computer C. User C couldn't know the content because it was encrypted, but now the authorities do know what the content was, and according to that court case, C can be held liable.

@xavierle "full clients" (like qTox or µTox) already do not come with TCP relaying enabled (i.e. they don't act as TCP relays), so that cannot be the difference between "full" and "mobile". It is already that way.

[GrayHatter]

@LuccoJ I'd like to read that court case, and the precedent?

@LittleVulpix Tox will scale to a point, I don't know where that point it, but It'll taper off at some point.

[xavierle]

@luccoj

i think that for most countries

the c person that was only a p2p relay service provider shall be considered as a neutral isp that is not responsible for content. (like most telecom or internet company)

but in germany. it seems there is an exception for p2p and lawsuits were done. against several protocols and use cases and p2p seems not so used in germany anymore because of those lawsuits

xavier Le 4 janv. 2016 19:53, "GrayHatter" notifications@github.com a écrit :

@LuccoJ https://github.com/LuccoJ I'd like to read that court case, and the precedent?

@LittleVulpix https://github.com/LittleVulpix Tox will scale to a point, I don't know where that point it, but It'll taper off at some point.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-168767488 .

[LuccoJ]

@GrayHatter you can read the complete court ruling in the original German at http://www.raschlegal.de/uploads/media/LG_Hamburg_308_O_319-12_24092012.pdf and a good article in German that covers how RetroShare works and the specifics of the court ruling is at https://irights.info/artikel/retroshare-storerhaftung-erreicht-das-„darknet/9862 while a simpler article in English about the ruling can be read at https://torrentfreak.com/anonymous-file-sharing-ruled-illegal-by-german-court-121123/

RetroShare, while offering more features than Tox (but also being quite a bit less user-friendly), is based on similar concepts, namely a DHT to discover friends' IP addresses, followed by direct communication, except in the case of relays (which was the issue here).

[LittleVulpix]

@GrayHatter that's messed up, I didn't know about that.

[GrayHatter]

@LittleVulpix what part?

[G10h4ck]

@timofonic It would be nice but I am not sure it is feasible, it seems to me that Tox overlap some RetroShare functionality but implemented in different way .

P.S. Its @csoler not csolder

[LuccoJ]

Unifying Tox with RetroShare is a little beyond the scope of this issue...

[LittleVulpix]

@GrayHatter that you are liable for stuff you don't even know what is and have no way of knowing.

[GrayHatter]

Yeah, that's a scary precedent to exist. On Jan 6, 2016 8:12 AM, "LittleVulpix" notifications@github.com wrote:

@GrayHatter https://github.com/GrayHatter that you are liable for stuff you don't even know what is and have no way of knowing.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-169372879 .

[irungentoo]

The DHT fixes that I pushed might have improved this.

[LittleVulpix]

I am testing this right now and will post back on this tomorrow around the same time, hopefully with good news. So far it looks like the connection count decreased almost tenfold (which is almost unbeliveable).

[xavierle]

i will have a look too Le 6 janv. 2016 23:20, "LittleVulpix" notifications@github.com a écrit :

I am testing this right now and will post back on this tomorrow around the same time, hopefully with good news. So far it looks like the connection count decreased almost tenfold (which is almost unbeliveable).

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-169480545 .

[GrayHatter]

@subilun, maybe you should checkout the new toxcore for Antox?

On Wed, Jan 6, 2016 at 2:24 PM, xavierle notifications@github.com wrote:

i will have a look too Le 6 janv. 2016 23:20, "LittleVulpix" notifications@github.com a écrit :

I am testing this right now and will post back on this tomorrow around the same time, hopefully with good news. So far it looks like the connection count decreased almost tenfold (which is almost unbeliveable).

— Reply to this email directly or view it on GitHub < https://github.com/irungentoo/toxcore/issues/1251#issuecomment-169480545>

.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-169482023 .

[LittleVulpix]

@GrayHatter @irungentoo after a day of monitoring (1-8 online contacts, varying throughout the monitored time, 3 small 500-1000kB filetransfers)

http://i.imgur.com/rl7HDmY.png

Previous results I don't have with me anymore, but the traffic was ~2.9GB, and 900 connections on average with peaks as high as 1800.

tl;dr - latest toxcore: 2x less data transferred and 8-10x fewer active connections (on average). Major improvement.

[xavierle]

i do not have a deep knowledge of antox and tox core.

but i maintain other technology im apps.

actually most im is organized around push notifications to get fastest messages from server.

notifications are done by : xmpp servers cloud im : gcm, google cloud message ( many im apps) websockets ( xmpp libre signal)

normal satus of the app is standby and only answering a living signal to the nearest notification server when the main server is asking for it. and the app really connect to receive data only after a push notification from server. most data transfert is done p2p without passing through server.

images files voice are already p2p even on centralised infrastructure.

maybe we can remimick this behavior for p2p with light client (in standby mode) and full client ( with push notification relay)

tox is said to be p2p but there is a still a kind of central introducer server. maybe the role of this introducer have to be reevaluated.

idea 1 maybe we have to work on a get way for light clients

continuous connection to one client if last message is less than x min with that client

when no activity from x minutes, light client inform all contact list that it goes in standby mode. connections are closed and connection will wake up every y minutes by itself (maybe 5) just to say other contact that light client is still alive and to get any messages from them light client never creates a connection to any client out of contact list (no relay function)

if a client is in that standby state. is it possible to send messages to it that will be recovered after x minutes

this will create a latency of y minutes of a conversation is inactive since y minutes. i think this is clearly acceptable to save resources a p2p network was never intended to be low latency.

i think x and y of 5 minutes is very ok. maybe this can be incremented. y = y+x until a maximum of a minutes

with y and x starting at one minute

2 maybe on the contrary we have to include push notification function on every full client that will act as a decentralised push servers ( maybe like websocket)

full client are connected to many clients (full light in contact list and out of contact list) full clients relays push notifications to wake up the standby light clientd

light clients reduce connection to the minimum (just asnwering to live ping) until they receive any kind of notification from any of the p2p full client

maybe i am wrong

Le 7 janv. 2016 22:56, "LittleVulpix" notifications@github.com a écrit :

@GrayHatter https://github.com/GrayHatter @irungentoo https://github.com/irungentoo after a day of monitoring:

http://i.imgur.com/rl7HDmY.png

Previous results I don't have with me anymore, but the traffic was ~2.9GB, and 900 connections on average with peaks as high as 1800.

tl;dr - latest toxcore: 2x less data transferred and 8-10x fewer active connections (on average). Major improvement.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-169818717 .

[GrayHatter]

@xavierle the problem with antox is that it's on android, and GCM is really the best option for battery life and actually working. Google it working hard to increase battery life, and has decided to go the software route; limiting apps and such. Rather than battery hardware R&D

[ghost]

I'd say they're working very hard to force everyone to become a part of the Google network or be left to die, and it seems to be working out very well. Better battery life is just a guise.

[xavierle]

my opinion is as following

there is no need to work on p2p project if it is to rely on gcm..

if i want gcm i use signal or even whatsapp or hangout.. Le 15 janv. 2016 21:13, "GrayHatter" notifications@github.com a écrit :

@xavierle https://github.com/xavierle the problem with antox is that it's on android, and GCM is really the best option for battery life and actually working. Google it working hard to increase battery life, and has decided to go the software route; limiting apps and such. Rather than battery hardware R&D

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172076720 .

[aaannndddyyy]

@xavierle +1 otoh, an app draining the battery and eating all your available data volume, will not be easy to "sell"

[GrayHatter]

Secure end to end anonymous encryption, you don't lose that from using GCM, you lose that by installing tox on any android device. If you're looking for Tox as a skype replacement, some sort of push system for your phone will be required. But if you're using tox for the same reason the concept was created. You shouldn't even be using an android.

[LuccoJ]

@xavierle +2 And others can keep saying that GCM is the "one and only" option on Android, and yet my XMPP client (Conversations) manages to work just fine, while taking up a negligible amount of battery, and without using GCM.

And XMPP is not even intrinsically a P2P protocol like Tox is, so it's pretty ironic that XMPP clients don't feel the need to go the GCM route, while Tox would give up its raison-d'être and go there.

Oh and I wonder if people realize that an app linking against the GCM support library (Google Play Services) can't even technically be free software according to the official definitions anymore.

[markwinter]

@LuccoJ The GCM requirement is for Android 6.0 only, it has nothing to do with your current phone and XMPP client. Please read into the new doze and and standby modes introduced in that version and how it affects the ability to do networking.

A lot of people seem to be getting confused with this GCM requirement without realising that it is only for Android 6.0 onwards, and that it is needed for Antox to stay connected when in the background because these new power-saving modes limit networking for background apps.

There may be ways to work around these new modes as I haven't kept up with Android development, but please do some reading yourself before questioning what is and isn't possible.

Some background on the new Doze state can be found here: http://www.androidcentral.com/inside-marshmallow-what-doze-how-do-i-use-it-and-what-does-it-do

After a while, everything goes to sleep. Well, almost everything. You'll still get notified when "high-priority" apps need your attention.

[..] high-priority notifications that aren't part of your carrier network (calls and texts) have to come through a Google Cloud Messaging server.

When they find someone abusing the system, and subsequently keeping your phone from dozing as intended, they can take action.

As you can see, the only way for Antox to stay connected when in the background is to specify it as a high-priority app. To do this you need to use GCM.

I do not know what the best solution is though, and I don't want to propose one either without knowing properly how Android 6 will work.

[xavierle]

android 6.0 is quite virtual

most of my app users avec still with android 4 android 5 is now growing and android 6 is nearly not existing in my communication app stats

i think users can keep with android 5 for some time to get benefits of tox Le 16 janv. 2016 19:00, "Mark Winter" notifications@github.com a écrit :

@LuccoJ https://github.com/LuccoJ The GCM requirement is for Android 6.0 only. Please read into the new doze and and standy modes introduced in that version and how it affects the ability to do networking.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172238200 .

[LuccoJ]

@Astonex I have read about it, and quite extensively. Why do you assume I haven't? (as a matter of fact, I have discussed Doze and App Standby in previous messages on this very thread)

However, there are several reasons why Doze and App Standby aren't necessarily such a huge problem. There is a whitelist of apps that are exempted from App Standby (and partly from Doze) that the user can manually set. Applications exposing the right permission in the manifest can also pop up a dialog asking the user to whitelist them directly. If they do this, they will only be accepted into the Play Store on the condition that bypassing Doze is essential for the app's "core function", but Google explain that an IM client that can't directly use GCM is the exact example of when this is acceptable, in their documentation.

(Various other permissions must be requested directly with a pop up to the user in Android 6.0, so this is nothing special to Doze whitelisting, and not something the user will consider unexpected.)

Please refer to http://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases for confirmation of what I said and further information.

[markwinter]

@LuccoJ I assumed you hadn't because your XMPP client working just fine without GCM didn't really relate to why Antox needs GCM (unless you happen to be on Android 6 already?).

Anyway, looking at that page you linked, it looks like Antox would be fine requesting the permissions to ignore the doze mode so it could keep on networking in the background, meaning no GCM would be needed.

Back to the main topic of this thread however, something still needs to be done about how much networking is done, and how much data is used just to run Tox, especially on a phone. Weren't offline messages supposed to have been developed last summer for GSoC? Maybe Antox could do no networking at all except checking in every now and then to look for those stored offline messages.

[subliun]

Based on the information in https://commonsware.com/blog/2015/11/11/google-anti-trust-issues.html I do not believe requesting exemption from doze through permissions is a viable solution.

[markwinter]

@subliun That post reiterates that apps must adhere to the acceptable use-cases Google has published, and that list already includes IM apps.

Antox is useless anyway until the battery and data usage is sorted.

[subliun]

The list includes only some IM apps with some vague wording about "breaking the core function". I suppose you can try it, but you still need the not-decentralised offline messaging servers which will require more core support.

[aaannndddyyy]

Couldn't it still be a randomly chosen normal peer act as a relay like tcp relays now, and send push notifications to the mobile client?

[GrayHatter]

normal. Can't serve as Google Cloud messenger relays because they have no way to know which and who to send to On Jan 16, 2016 12:12 PM, "aaannndddyyy" notifications@github.com wrote:

Couldn't it still be a randomly chosen normal peer act as a relay like tcp relays now, and send push notifications to the mobile client?

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172252138 .

[GrayHatter]

Correction no normal clients can't send messages via GCM because it has no way to know which GCM ID they need send to.

There's also no way to make GCM messages distributed so we can put that into a normal client anyways On Jan 16, 2016 12:12 PM, "aaannndddyyy" notifications@github.com wrote:

Couldn't it still be a randomly chosen normal peer act as a relay like tcp relays now, and send push notifications to the mobile client?

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172252138 .

[LuccoJ]

@Astonex The reason I mentioned XMPP clients is that, as you see, other people have been claiming GCM may be necessary for reasonable battery/bandwidth use even outside of the Android 6.0-specific Doze / App Standby issues.

I, on the other hand, think that as long as Tox is being used in TCP relay mode, which means something like ten concurrent connections (not hundreds) and no continuous DHT requests, it should be able to perform about as well as (for instance) XMPP clients, both bandwidth-wise and battery-wise, because it's essentially the same mechanism.

If it currently doesn't, that must be because keepalive packets are exchanged too often and/or communication isn't done enough in bursts when feasible. Which does not need GCM to be solved. And yet, having discussed this with others, I've repeatedly encountered insistence that, somehow, this won't be good enough for Tox (even though it appears to work for other things like XMPP clients).

I think offline messages wouldn't be a great solution to this: it's probably cheaper to keep a TCP connection to a relay permanently set up and deal with keepalives, than establish a link to the DHT periodically to check for offline messages.

@subliun Remember that in the worst case, Antox can always be distributed outside of Play Store, especially if Play Store have policies contrary to what a normal program needs to run without jumping through hoops. While F-Droid is an already-employed option, fortunately, Android still allows to just install standalone APKs.

[aaannndddyyy]

You misunderstood me. I didn't talk about gcm, but about a somehow decentralized push notification system. It would still be only one, but it could be any normal, i.e. non-mobile, client taking that role. That way you do not depend on a server and do not expose too much metadata to one central authority.

[GrayHatter]

Even TCP only mode the device is still online constantly and never has a chance to sleep so it will still kill the battery. using GCM is the best way to preserve battery life

There is no way to preserve battery life without using some sort of push messaging and talks does not support push messaging On Jan 16, 2016 12:22 PM, "LuccoJ" notifications@github.com wrote:

@Astonex https://github.com/Astonex The reason I mention XMPP clients is that, as you see, other people have been claiming GCM may be necessary even regardless of the Android 6.0-specific Doze / App Standby issues.

I, on the other hand, think that as long as Tox is being used in TCP relay mode, which means something like ten concurrent connections (not hundreds) and no continuous DHT requests, it should be able to perform about as well as (for instance) XMPP clients, both bandwidth-wise and battery-wise, because it's essentially the same mechanism.

If it currently doesn't, that must be because keepalive packets happens too often and/or communication isn't done enough in bursts when feasible. Which doesn't need GCM to be solved. And yet, having discussed this with others, I've repeatedly encountered insistence that, somehow, this won't be good enough for Tox (even though it appears to work for things like XMPP clients).

@subliun https://github.com/subliun Remember that in the worst case, Antox can always be distributed outside of Play Store, especially if Play Store have policies contrary to what a normal program needs to run without jumping through hoops. While F-Droid is an already-employed option, fortunately, Android still allows to just install standalone APKs.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172252893 .

[LuccoJ]

@aaannndddyyy I'm not sure I understand what people really mean when they talk about a generic "push notification solution", especially if it's decentralized. The concept of push notifications involves centralization: it is about, instead of having multiple connections to multiple entities active at the same time, keeping just one of them, which is optimized for "as much silence as possible", and only send short bursts of data when necessary.

This is not dissimilar to optimized TCP relaying in the first place.

GCM isn't magic, it's just centralization of short network communications (and special treatment by Google in Android 6.0).

[LuccoJ]

@GrayHatter You keep saying "there is no way", and I keep saying other apps, like XMPP clients, do it fine. They are also "online constantly". With GCM, you are also "online constantly". It's still the Internet through mobile data. There is no magic. The one difference is that GCM tries to centralize all internet-to-device communication into one connection, which it can optimize, instead of each app having its own connection.

@Astonex Do you understand why I have to keep insisting about XMPP and similar things now?

[GrayHatter]

Snow GCM isn't magic but its level of optimization greatly outstrip anything that we can do On Jan 16, 2016 12:29 PM, "LuccoJ" notifications@github.com wrote:

@aaannndddyyy https://github.com/aaannndddyyy I'm not sure I understand what people really mean when they talk about a generic "push notification solution", especially if it's decentralized. The concept of push notifications involves centralization: it is about, instead of having multiple connections to multiple entities active at the same time, keeping just one of them, which is optimized for "as much silence as possible", and only send short bursts of data when necessary.

This is not dissimilar to optimized TCP relaying in the first place.

GCM isn't magic, it's just centralization of short network communications (and special treatment by Google in Android 6.0).

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172255107 .

[LuccoJ]

Well... no. Conversations is an XMPP client that is open source, written mainly by one person, runs on Android and doesn't eat battery at all - and yet it doesn't use GCM. I know other programs like that. What you say that GCM is absolutely needed for reasonable optimization, @GrayHatter simply isn't true.

[aaannndddyyy]

With gcm you are also constantly online. The difference is that you are passive until you receive a push notification. Thus the tcp connection eats almost no ressources while you are idle. Yes, you only keep one connection open, not hundreds. That's what the relay would be needed for. That relay would act as the server, just like tcp relays already do for peers that are not reachable via udp - all comm goes through tcp relays.

What is needed here is a passive mode. No pings every few seconds to each friend and no active participation in the dht, becoming active once a push was received

[GrayHatter]

I don't remember say it's absolutely needed.

But it's the easiest, most battery efficient, and soon with Android 6, the only simple way.

Other than, there's other ways, and other than, google is centralized, or evil, or skynet. What's wrong with GCM? On Jan 16, 2016 12:49 PM, "aaannndddyyy" notifications@github.com wrote:

With gcm you are also constantly online. The difference is that you are passive until you receive a push notification. Thus the tcp connection eats almost no ressources whil you are idle. Yes, you only keep one connection open, not hundreds. That's what the relay would be needed for. That relay would act as the server, just like tcp relays already do for peers that are not reachable via udp - all comm goes through tcp relays.

What is needed here is a passive mode. No pings every few seconds to each friend and no active participation in the dht, bwcoming active once a push was received

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1251#issuecomment-172257007 .