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. > I agree that UDP ought to be workable, and with your comments on > retransmission being handled differently but also acceptably. Right. It's not really any different except that all of the error handling that TCP does for an application, an application has to do for itself. That is what QUIC does. > 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. 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. > 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. > > 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. But all of the brokenness of NAT goes away with IPv6. > 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. 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
