Synology-Forum.nl
Overige software => DDNS / Quick Connect / EZ-Internet / Portforwarding => Topic gestart door: Briolet op 26 juni 2015, 10:30:55
-
Oproep tot verzameling van de ervaring met Quick Connect op Ziggo Routers.
Er zijn een aantal meldingen geweest van mensen met een Ziggo router dat Quick Connect regelmatig niet kan verbinden als er niet ook poorten geforward zijn. Ik vermoed dat dat komt omdat de “tcp idle timeout” op de Ziggo routers op 5 minuten staat en de heartbeat van Quick Connect langer ingesteld staat waardoor Quick Connect niet betrouwbaar werkt op deze routers.
Ik kan me een discussie op het Ziggo forum herinneren waar deze korte tijd er ook voor zorgde dat WhatsApp berichten soms 15 minuten vertraagd binnen kwamen. Whatsapp gebruikt de "Google Cloud Messaging" van Android die slechts elke 15 minuten een heartbeat geeft.
Als je zoekt vind je dat er over de wereld meer mensen last hebben van een dergelijke korte “tcp idle timeout” van hun router. Uit het artikel (https://productforums.google.com/forum/#!topic/nexus/fslYqYrULto) kun je het volgende stuk halen.
By definition a TCP connection does not have a timeout. But in the real world, wifi routers and mobile carriers have some rules to limit the number of opened tcp connections. So they usually close/kill what they think to be an inactive connection after some times that no packets are transmitted. For example my wifi router kill connections after 300 seconds (5 minutes) of inactivity (no packets on the tcp connection).
What happens is that, when I don't have push notifications for 5 minutes, the router kill the connection because is inactive and android is not able (since the router didn't sent any ack to the phone) to intercept that the connection has been closed because of a tcp idle timeout rule. From that moment the GCM connection is a dead connection and no push notifications are received until the connection is re-established (switch wifi/mobile connection off and on, or an heartbeat is sent, see below).
Indertijd gaf een van de programmeurs van Google aan bekend te zijn met dit probleem, dus het kan zijn dat dit specifieke probleem nu in Android opgelost is.
Omdat ik vermoed dat Quick Connect tegen dit zelfde probleem oploopt, zou het aardig zijn als mensen hun ervaring hier posten met vermelding van het router type waarmee dit probleem optreed. En of het probleem verdwijnt als poorten geforward worden.
Als dit echt het probleem blijkt te zijn, zal er een feature request naar Synology moeten met het verzoek om de heartbeat van Quick Connect korter in te stellen, of zelf instelbaar te maken.
-
Dus alleen melden als je problemen ervaart?
-
Het lijkt mij onwaarschijnlijk dat dit er iets mee te maken heeft.
Het quickconnect mechanisme dat een link legt van je NAS naar de servers van Synology moet echt een keepalive/retry mechanisme hebben, anders zou het nooit kunnen werken.
Een tcp connectie over het internet kan per definitie verbroken worden en wordt dan normaal gesproken gewoon weer opnieuw opgezet.
Dus dat quickconnect mechanisme moet om de zoveel tijd een handshake met de synology server doen, anders zou het nooit werken.
Als de bestaande connectie door de router is verbroken, zal hij gewoon een nieuwe opzetten.
Het enige nadeel van zo'n router instelling is dat het mogelijk veel vaker nodig is de verbinding op te bouwen.
Als iemand dat quickconnect gebruikt en ook wireshark heeft moet je het zo kunnen zien.