"Brian J. Murrell" <[email protected]> writes:
> On Sat, 2019-03-30 at 09:40 -0400, Greg Troxel wrote: >> >> The FCM way is, I think, for the client to reconnect and query, with >> the >> server not having pushed anything. > > I'm not sure I'm completely understanding what you are saying. > > The FCM way is that information server/services that want to send > something to an app -- this can be instant messaging, etc. -- send it > to the app via an FCM push. This is done by the server sending an API > query to the FCM service identifying the phone that it wants to send > the payload to and the payload it wants to send. In the case of IM > type applications, this message from FCM can have what the service > wants to send, or it can simply be a "hey, come to me and get your > message". The latter is how linphone is using it. 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. 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. This is how many things on my phone work, including XMPP and IMAP. 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) so now we have async retransmits happening. Instead, I think the FCM (or any oob push; this is not about the non-free/tracking issue of FCM) way is: 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 so there there is no timing race between retransmit and everyting else; things are only sent on channels that are expected to work. >> But in this case I think it's about working around a system that >> isn't processing packets correctly in a way that none of this was >> designed to handle. > > That's not an unfair statement. Even though TCP was invented so long > ago that networks were inherently unreliable, I doubt it was imagined > that endpoints would be so transient as phones are getting to be today. Certainly I never heard the notion expressed. At the time TCP was invented, endpoints weighed more than people and needed rooms with air conditioning! From the early days of the ARPANET, the network was mostly there (or it was uucp when it was mostly not there). And if it went away, there'd be a new TCP connection to retry mail in hours. I first saw wireless lan interfaces in the late 90s. Even then, there was no real notion of keeping a TCP connection alive across network disconnects as the normal approach. I think it's only recently that we are seeing the aggressive power saving of turning off wifi and ignoring incoming data on a TCP connection. > It's mostly workable though. Most things don't need the kind of timely > delivery that SIP does and so a bit of TCP-retry-delay backlog goes > unnoticed. But some protocols like SIP really do need timely delivery > and so the guarantees that TCP provides actually hinders it. It's not really the guarantees but the retransmission rules that avoid congestion collapse. If most traffic were UDP we'd need the same rules to avoid congestion collapse. But what I'm trying to say is that in a world where IP packets can be buffered for times that are longer than a few seconds, any retransmission plan is troubled, as retransmission strategies have to try to cope with ambiguity between congestion and loss, and then would have to cope with ambiguity among congestion, loss, and delay. 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. >> I see the TCP/UDP connection issue as having two larger points: >> >> TCP can and should use TLS, to hide the username and password in >> register messages > > TLS does not require TCP. DTLS is TLS over UDP. Technically true of course. Do sip servers and clients usually do DTLS? Is there some STARTDTLS sort of thing that happens on port 5060? I have never seen this in config in a client. >> TCP seems more likely to traverse possibly multiple layers of perhaps >> broken firewall and NAT devices. > > Yes, this is true. But fortunately, becoming yesterday's problems. > IPv6 is coming, and arriving. I have 3 IPv6 connections to the > Internet on my consumer services. Two are with ISPs and one is an IPv6 > tunnel. My mobile provider gives me IPv6 addresses. It also gives me > IPv4 with broken NAT so I actually prefer IPv6. It's been becoming yesterday's problem for 20 years. In another 10 years we'll be there! > But all of the brokenness of NAT goes away with IPv6. But not firewall brokenness. I've had to set keepalives on TCP to keep firewalls from timing out ssh connections. >> Yes, UDP ought to work, but I think it's more likely to lose with >> broken devices, and that's part of the source of the notion > > I'm not sure I buy a prevalence of broken UDP devices either though. > Surely not saying they don't exist, but I don't think they exist to the > level of FUD about UDP that seems to float around here. I haven't been tracking the FUD. I would only say that TCP with keep-alive data of some sort every 15 minutes is overwhelmingly likely to work (because if it doesn't the network is just plain broken), and that TCP that is quiet for longer, and UDP, is somewhat more likely to be broken. I would not say it's usually broken. But, unless DTLS works almost everywhere (and one can easily configure the client and server to not allow cleartext registration), then TLS seems to be the only reasonable approach. _______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
