Synchronisation(s)
Cette opération de synchronisation(s) intervient:
- toutes les 5 minutes environ (sous réserve qu'il n'y ait pas déjà de synchronisation en cours) en cas d'usage de serveur partagé entre plusieurs clients (POC, déploiement limité ou sans exigence de performances), et jamais plus souvent (même en cas de réidentification ou changement d'identification)
- toutes les minutes environ (sous réserve qu'il n'y ait pas déjà de synchronisation en cours) en cas d'usage de plateforme dédiée par votre seule organisation, recommandée pour les applications métier, et jamais plus souvent (même en cas de réidentification ou changement d'identification)
Ce qu'on appelle abusivement la "synchronisation" SynergyTab inclut 5 opérations distinctes dont l'exécution est faite en parallèle et en arrière-tâche de vos usages (interface) de l'application, pour une meilleure efficacité.
- Le téléchargement des données "base de données" (API REST JSON), dont l'avancement s'affiche via une barre de progrès (si connexion active, sinon, la barre va se compléter selon le réglage timeout ou disparaitre rapidement si en mode avion avec Wifi désactivé), uniquement à l'identification (pour ne pas perturber les usagers ensuite). Celui-ci fait actuellement 17 requêtes HTTPS parallèles vers synergytab.usitab.fr pour un serveur partagé ou votre serveur dédié (avec chacune un temps maximum d'attente avant réponse du serveur égal à ce qui est défini sur l'écran A Propos > Timeout). En cas de mauvaise connexion usuelle, il est donc recommandé d'abaisser ce paramètre (à 3s par exemple) pour ne pas saturer inutilement les ressources de votre tablette.
- Le téléchargement des fichiers binaires (photos, videos) qui se fait pendant l’usage de l’application en arrière-plan (pour ne pas vous gêner pendant son usage) et dont le progrès (en Ko) est visible par les compteurs de la page A Propos, par des requêtes aussi nombreuses que le nombre de fichiers binaires téléversés sur le portail d'administration.
- L’insertion dans une base de données (Base de données SQLite), que vous voyez évidemment de façon résumée sur l'écran A Propos
- Le téléversement des fichiers binaires de l'application vers le portail d'administration (envoi des fichiers binaires photos)
- Le téléversement des données texte vers le portail d'administration (API REST JSON)
Cette opération de synchronisation(s) intervient:
- toutes les 5 minutes environ (sous réserve qu'il n'y ait pas déjà de synchronisation en cours) en cas d'usage de serveur partagé entre plusieurs clients (POC, déploiement limité ou sans exigence de performances), et jamais plus souvent (même en cas de réidentification ou changement d'identification)
- toutes les minutes environ (sous réserve qu'il n'y ait pas déjà de synchronisation en cours) en cas d'usage de plateforme dédiée par votre seule organisation, recommandée pour les applications métier, et jamais plus souvent (même en cas de réidentification ou changement d'identification)
Ce qu'on appelle abusivement la "synchronisation" SynergyTab inclut 5 opérations distinctes dont l'exécution est faite en parallèle et en arrière-tâche de vos usages (interface) de l'application, pour une meilleure efficacité.
- Le téléchargement des données "base de données" (API REST JSON), dont l'avancement s'affiche via une barre de progrès (si connexion active, sinon, la barre va se compléter selon le réglage timeout ou disparaitre rapidement si en mode avion avec Wifi désactivé), uniquement à l'identification (pour ne pas perturber les usagers ensuite). Celui-ci fait actuellement 17 requêtes HTTPS parallèles vers synergytab.usitab.fr pour un serveur partagé ou votre serveur dédié (avec chacune un temps maximum d'attente avant réponse du serveur égal à ce qui est défini sur l'écran A Propos > Timeout). En cas de mauvaise connexion usuelle, il est donc recommandé d'abaisser ce paramètre (à 3s par exemple) pour ne pas saturer inutilement les ressources de votre tablette.
- Le téléchargement des fichiers binaires (photos, videos) qui se fait pendant l’usage de l’application en arrière-plan (pour ne pas vous gêner pendant son usage) et dont le progrès (en Ko) est visible par les compteurs de la page A Propos, par des requêtes aussi nombreuses que le nombre de fichiers binaires téléversés sur le portail d'administration.
- L’insertion dans une base de données (Base de données SQLite), que vous voyez évidemment de façon résumée sur l'écran A Propos
- Le téléversement des fichiers binaires de l'application vers le portail d'administration (envoi des fichiers binaires photos)
- Le téléversement des données texte vers le portail d'administration (API REST JSON)
La première est forçable via une simple mise à jour sur le portail d'administration.
En raison d'une mauvaise compréhension des mécanismes d'envoi manuel/réenvoi/réémission, aucune opération manuelle d'envoi n'est désormais offerte à l'utilisateur dans l'application.
De fait, votre temps de synchronisation INITIALE (installation) est donc dépendant dans l’ordre
En raison d'une mauvaise compréhension des mécanismes d'envoi manuel/réenvoi/réémission, aucune opération manuelle d'envoi n'est désormais offerte à l'utilisateur dans l'application.
De fait, votre temps de synchronisation INITIALE (installation) est donc dépendant dans l’ordre
1. De la volumétrie de votre compte (pour téléchargement et insertion de données) visible sur le portail d'administration dans la section Compte > Statistiques d'usage et dans l'application sur l'écran A Propos > Volume
2. Des performances réseau descendant (pour téléchargement uniquement) et montant (pour téléversement uniquement). Wifi actif et performant en permanence ne signifie pas connexion à Internet disponible, stable et performante, ce sont 2 informations complètement distinctes.
3. Des performances matérielles (CPU, RAM) de votre iPad (pour insertion des données en base de données)
4. De votre usage de l’iPad simultané ou pas (pour insertion des données principalement)
Si vous interrompez cette synchronisation INITIALE (perte de réseau ou impatience), les données disponibles dans l'application seront partielles (non affichage de certains objets), jusqu'à temps qu'elle puisse redémarrer et arriver à son terme (donc sous réserve de connexion pendant toute sa durée)
De fait, votre temps de synchronisation en usage NORMAL (après synchronisation INITIALE) est donc dépendant dans l'ordre
Bases des réseaux TCP/IP (dont Internet)
Pour comprendre le principe des synchronisations client/serveur, il faut également connaître les rudiments du réseau Internet. Le standard TCP/IP utilisé par Internet (et donc toute application comme la nôtre), qui applique un overhead (supplément d'informations) non négligeable aux contenus transmis, est d'autant moins efficace que:
- la connexion n'est pas stable: la perte de connexion induit des réémissions, c'est à dire des renvois d'informations (en double, triple, etc) qui réduisent d'autant la bande passante disponible
- la latence (ping) est forte (temps requis pour atteindre la destination, et pour que celle-ci informe l'expéditeur qu'une information est bien arrivée "ACK")
Il est recommandé de s'adresser à votre prestataire réseau, lorsque Usitab vous signale un dysfonctionnement, d'autant plus lorsque ce dysfonctionnement n'est pas reproduit sur une simple "connexion résidentielle à 30 Euros par mois". Celui-ci nous fournira des captures réseau (ex: Wireshark) comparatives pour démontrer les capacités du réseau en parallèle de la volumétrie.
Vous trouverez ici les rudiments du TCP/IP de manière vulgarisée si néanmoins l'investigation de cette problématique vous intéresse
http://sebsauvage.net/comprendre/tcpip/
https://www.commentcamarche.net/contents/539-tcp-ip
https://itigic.com/fr/capture-traffic-with-wireshark-and-analyze-it/
Speedtest
https://speedtest.usitab.com
Si vous interrompez cette synchronisation INITIALE (perte de réseau ou impatience), les données disponibles dans l'application seront partielles (non affichage de certains objets), jusqu'à temps qu'elle puisse redémarrer et arriver à son terme (donc sous réserve de connexion pendant toute sa durée)
De fait, votre temps de synchronisation en usage NORMAL (après synchronisation INITIALE) est donc dépendant dans l'ordre
1. De la volumétrie de mise à jour de votre compte entre l'instant t de dernière synchronisation avec connexion et celle en cours
2. Des performances réseau descendant (pour téléchargement uniquement) et montant (pour téléversement uniquement). Wifi actif et performant en permanence ne signifie pas connexion à Internet disponible, stable et performante, ce sont 2 informations complètement distinctes.
3. Des performances de votre iPad (pour insertion des données en base de données)
4. De votre usage de l’iPad simultané ou pas (pour insertion des données principalement)
5. De l'activité globale des clients si vous êtes en serveur partagé (mode FIFO)
Une synchronisation cherchera toujours à mettre à jour l'intégralité des données disponibles, mais la réalité de la synchronisation sera dépendante de la qualité de votre réseau. Pour forcer une synchronisation d'un objet, il suffit de le modifier (comme par exemple, le passer en inactif/actif), il sera alors automatiquement mis à jour lors de l'occurrence suivante de synchronisation (sous réserve de connexion disponible pendant toute sa durée)
Pourquoi la synchronisation envoie les informations d'objets inactifs ?
Parce qu'il faut bien que l'information "objet désactivé", ou "droits désactivés" soit transmise à la tablette pour que celle-ci n'en propose plus l'affichage. En revanche, seul l'objet modifié est transmis (par exemple, les champs d'un formulaire désactivé ne sont pas transmis)
5. De l'activité globale des clients si vous êtes en serveur partagé (mode FIFO)
Une synchronisation cherchera toujours à mettre à jour l'intégralité des données disponibles, mais la réalité de la synchronisation sera dépendante de la qualité de votre réseau. Pour forcer une synchronisation d'un objet, il suffit de le modifier (comme par exemple, le passer en inactif/actif), il sera alors automatiquement mis à jour lors de l'occurrence suivante de synchronisation (sous réserve de connexion disponible pendant toute sa durée)
Pourquoi la synchronisation envoie les informations d'objets inactifs ?
Parce qu'il faut bien que l'information "objet désactivé", ou "droits désactivés" soit transmise à la tablette pour que celle-ci n'en propose plus l'affichage. En revanche, seul l'objet modifié est transmis (par exemple, les champs d'un formulaire désactivé ne sont pas transmis)
Bases des réseaux TCP/IP (dont Internet)
Pour comprendre le principe des synchronisations client/serveur, il faut également connaître les rudiments du réseau Internet. Le standard TCP/IP utilisé par Internet (et donc toute application comme la nôtre), qui applique un overhead (supplément d'informations) non négligeable aux contenus transmis, est d'autant moins efficace que:
- la connexion n'est pas stable: la perte de connexion induit des réémissions, c'est à dire des renvois d'informations (en double, triple, etc) qui réduisent d'autant la bande passante disponible
- la latence (ping) est forte (temps requis pour atteindre la destination, et pour que celle-ci informe l'expéditeur qu'une information est bien arrivée "ACK")
Il est recommandé de s'adresser à votre prestataire réseau, lorsque Usitab vous signale un dysfonctionnement, d'autant plus lorsque ce dysfonctionnement n'est pas reproduit sur une simple "connexion résidentielle à 30 Euros par mois". Celui-ci nous fournira des captures réseau (ex: Wireshark) comparatives pour démontrer les capacités du réseau en parallèle de la volumétrie.
Vous trouverez ici les rudiments du TCP/IP de manière vulgarisée si néanmoins l'investigation de cette problématique vous intéresse
http://sebsauvage.net/comprendre/tcpip/
https://www.commentcamarche.net/contents/539-tcp-ip
https://itigic.com/fr/capture-traffic-with-wireshark-and-analyze-it/
Speedtest
https://speedtest.usitab.com