On Sat, 2019-03-30 at 10:30 -0400, Greg Troxel wrote: > > What I meant is just as you said it, which is that the phone gets a > wakeup message, and then connects to the server and gets whatever > information is to be sent.
That's one way. The FCM message can carry a payload for the application to just consume. This could be the case for IM applications for example where the FCM payload could carry the message to be sent and the IM application just displays that message without contacting it's own server. But the payload could be encrypted for the privacy conscious. > What I think was happening as you described slowness with TCP was > that > the phone had a TCP connnection, and in a world that didn't have > power > saving that requires FCM, the server would just send things over that > connection and they would arrive. Right. > But, the combination of having TCP that is expected to work, power > saving that means it does not work, and FCM wakeups mean that we > have a sequence > > phone sets up connection to server > phone goes to sleep > server sends data > server sends push > phone wakes up > (now what) Phone waits for server to retry sending the data after the TCP-retry- wait has expired. For non-time sensitive data, this is fine. The data will arrive when the TCP-retry-timeout expires. For time sensitive data, not so fine. > phone sets up connection to sip server > phone registers with push server and gets a token > phone sends token to sip server and tells it it is entering push > mode > phone disconnects from sip server > > phone goes to sleep > > server gets call and send wakeup via push server > > phone gets wakeup from push server > > phone connects to sip server and does a reconnect > > sip server sends INVITE Yes, this of course would be much better. This of course requires the SIP server to understand this "going to sleep, wake me when you need me" message. > Certainly I never heard the notion expressed. At the time TCP was > invented, endpoints weighed more than people and needed rooms with > air > conditioning! Indeed. But I don't think the networks were as reliable as today. Just guessing. > And if > it > went away, there'd be a new TCP connection to retry mail in hours. In fact, TCP survives network outages, as long as nothing in the path does something bad like sending an ICMP message reflecting the network outage. I used to do this over dialup all of the time. I'd ssh somewhere, phone line would drop, I'd bring it back up the next day and ssh just resumed. > It's not really the guarantees but the retransmission rules that > avoid > congestion collapse. Right, but the retransmission (rules) is part of providing the guarantee. > So, protocols that are going to be used with clients that have this > deep > sleep mode have to be aligned with how that works, and I think that > more > or less means not sending data to the client when it's in deep sleep, > which means the push registration sequence above. Don't disagree. A system where all parties know the state of the other parties and accordingly, and we don't have some parties pretending to be in one state when they are not, would be ideal. > Technically true of course. Do sip servers and clients usually do > DTLS? Probably not. I was just saying it's not like it doesn't exist. > It's been becoming yesterday's problem for 20 years. In another 10 > years we'll be there! I personally experience it broadly enough that it's "here" for me. :-) > But not firewall brokenness. This is true. They still need to track state. Cheers, b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
