Bonjour,

Je travaille en ce moment sur les sockets en c sharp, et suis amené à dialoguer avec un service de support en anglais. Il y a cet phrase que je ne comprend pas, dans le sens où je ne sais pas ce qu'est le "polling mode" :

"Make sure you're in the correct mode (polling vs non-polling)"

Merci

"To Poll" en anglais veut dire interroger. En matière d'échange réseau, cela veut dire que tu fonctionne suivant le principe de client-serveur à sens unique => C'est toujours le client qui initie une demande pour récupérer des données.

Par exemple, en Silverlight, le plus simple pour discuter avec un service reste de passer par HTTP (communication à sens unique donc)...Pourtant, il est possible synthétiser une communication à double-sens (client->serveur et serveur->client) en utilisant PollingDuplex. Cette méthode de liaison va, à intervalle réguliers, envoyer une requête au serveur pour voir si ce dernier n'a pas des messages à destination du client => C'est donc toujours le client qui interroge le serveur.

D'accord, donc remis dans son contexte :

"Make sure you're in the correct mode (polling vs non-polling) as some syntax and parameters are different or non existent. By the dialog here; I'm assuming you are in polling mode?"

Moi je fais des requêtes à mon serveur, qui me répond à chaque fois que je clique sur un bouton.
Polling mode.

Alors non-polling mode, c'est quand c'est le serveur qui t'interroge ?

Je ne sais pas comment marche ton système, du coup, je vais me baser sur le fonctionnement de PollingDuplex en Silverlight/WCF.

Le mode de polling se configure à la fois côté serveur, pour lui dire qu'il va recevoir des messages légers de la part des clients à intervalle régulier, et à la fois côté client , pour lui dire qu'il doit envoyer à intervalle régulier un message léger pour éviter de se faire dropper la session en cours par exemple, mais surtout, pour vérifier si le serveur n'a pas des messages en attente qui lui seraient destinés.

J'imagine que c'est toujours pour ton modem GSM => T'as pas une option dans l'activation de l'API HTTP du modem qui permet d'activer ou non ce système de polling?

En mode polling, tu aurais donc ce système actif et le serveur attendrais un message toutes les x <temps>, en plus des requêtes pouvant arriver n'importe quand.
En mode non-polling, ce système est désactivé et on retourne dans un système classique de "site web", sans requête à intervalle réguliers, où une requête peut arriver n'importe quand.

Citation : Nisnor

T'as pas une option dans l'activation de l'API HTTP du modem qui permet d'activer ou non ce système de polling?

J'ai ça : "Non Polling Receive API Configuration"

Il est décoché, donc en théorie il est en Polling Mode (non-non polling en fin de compte :p)
Du coup si l'option non-polling est désactivée, il attend des requêtes "légères" tous les x temps, sinon il kill le socket c'est ça ?

Ca expliquerait mes erreurs 10053 à chaque fois que je veux faire une deuxième requête.
En somme je dois soit envoyer des requêtes de manière régulière pour dire "eh ho je suis toujours là", soit re-créer un socket à chaque fois.

Dur.

Ou alors c'est pas du tout ça, et ça concerne la fonction de réception des SMS du modem, ce qui n'a RIEN à voir.

Citation : Firnael

Du coup si l'option non-polling est désactivée, il attend des requêtes "légères" tous les x temps, sinon il kill le socket c'est ça ?

C'est une possibilité...Ca ne veut pas dire que le modem va réagir comme ça. Il y a une histoire de session dans ce modem? Si oui, ça peut venir de là oui...Si non, ça viendra pas de là.

Citation : Firnael

En somme je dois soit envoyer des requêtes de manière régulière pour dire "eh ho je suis toujours là", soit re-créer un socket à chaque fois.

Oui pour l'envoi de message à intervalle réguliers...Il y a aura surement un truc à ce sujet dans la doc du modem.

D'accord.

J'ai rien trouvé à ce sujet dans la doc. Au pire re re-créer mon socket à chaque fois, si c'est pas trop dégueu ?

Pas fameux quand même :s . Recréer le client HTTP à chaque fois, ça veut dire réinstancier de nouveaux objets, nouvelle allocation de mémoire = perte de temps inutile (même si ça se joue à quelque ms près).

Et si tu t'identifies sur le modem, ça veut aussi dire que t'es obligé de stocker le mot de passe en mémoire (ou de le redemander à l'utilisateur de l'application, c'est mieux mais beaucoup plus chiant) => Faille de sécurité potentielle.

Bah enfait pour pouvoir utiliser les API sur le modem (par exemple send SMS), tu dois fournir une authentification dans la string que t'envoie (soit l'admin, soit un user avec les droits), donc c'est peut-être voulu que la connexion soit drop entre chaque envoi.

Mais dans tous les cas effectivement ça fait des couples login/mdp qui circulent en clair sur le réseau, c'pas tip-top