[WD11] Utilisation des sockets, généralités

Le
Bruno Wrk
Bonjour !

Après avoir tester les webservices de windev et m'être rendu compte que
cela ne collé pas vraiment à mes besoins, j'ai testé l'utilisation des
sockets qui me donne pleine satisfaction.

Juste 2 petites questions :
- Est-ce possible d'avoir une information de type "chargement" ? Par
exemple si un buffer d'une certaine taille est un train d'arrivé,
peut-on évaluer le temps qu'il reste avant la fin de réception ?
- Des précautions particulières ? Est-ce possible de perdre des données
lors de transfert d'information ?

Ou petits pièges / astuces que vous avez découvert avec le temps.

Merci !

Bruno WRK
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Emmanuel Haefele
Le #14506861
"Bruno Wrk"
Bonjour Bruno,

Juste 2 petites questions :
- Est-ce possible d'avoir une information de type "chargement" ? Par
exemple si un buffer d'une certaine taille est un train d'arrivé,
peut-on évaluer le temps qu'il reste avant la fin de réception ?



Sans certitude mais je ne pense pas que ce soit possible, par contre tu
devrais pouvoir gérer cette contrainte toi-même en envoyant dans un
premier temps une trame contenant la taille de ton buffer puis dans un
second temps le contenu de ton buffer.

- Des précautions particulières ? Est-ce possible de perdre des données
lors de transfert d'information ?



Personnellement il m'est arrivé un truc bizarre, aléatoirement la trame
était envoyée mais jamais reçu. Je n'en ai jamais compris la raison et le
simple déplacement du programme émetteur sur une autre machine du réseau a
réglé le problème. A mon avis ça doit être tout à fait exceptionnel et si
tu n'as pas de coupure réseau (lien WIFI par exemple) tu ne devrais pas
perdre de données.


Amicalement,

Emmanuel Haefelé.
patrice
Le #14503071
"Emmanuel Haefele" news:48510048$0$872$
"Bruno Wrk"
Bonjour Bruno,

> Juste 2 petites questions :
> - Est-ce possible d'avoir une information de type "chargement" ? Par
> exemple si un buffer d'une certaine taille est un train d'arrivé,
> peut-on évaluer le temps qu'il reste avant la fin de réception ?

Sans certitude mais je ne pense pas que ce soit possible, par contre tu
devrais pouvoir gérer cette contrainte toi-même en envoyant dans un
premier temps une trame contenant la taille de ton buffer puis dans un
second temps le contenu de ton buffer.



c'est la meilleure solution


> - Des précautions particulières ? Est-ce possible de perdre des données
> lors de transfert d'information ?

Personnellement il m'est arrivé un truc bizarre, aléatoirement la trame
était envoyée mais jamais reçu. Je n'en ai jamais compris la raison et le
simple déplacement du programme émetteur sur une autre machine du réseau a
réglé le problème. A mon avis ça doit être tout à fait exceptionnel et si
tu n'as pas de coupure réseau (lien WIFI par exemple) tu ne devrais pas
perdre de données.




en tcp, il est possible de perdre des données si le receveur perd la
connexion
(aucune erreur à l'émission ne garantie pas que les données aient été
reçues)

donc meme en TCP, il vaut mieux acker les messages si on veut être sur de la
réception
Bruno Wrk
Le #14502791
patrice vient de nous annoncer :
"Emmanuel Haefele" news:48510048$0$872$
"Bruno Wrk"
Bonjour Bruno,

Juste 2 petites questions :
- Est-ce possible d'avoir une information de type "chargement" ? Par
exemple si un buffer d'une certaine taille est un train d'arrivé,
peut-on évaluer le temps qu'il reste avant la fin de réception ?



Sans certitude mais je ne pense pas que ce soit possible, par contre tu
devrais pouvoir gérer cette contrainte toi-même en envoyant dans un
premier temps une trame contenant la taille de ton buffer puis dans un
second temps le contenu de ton buffer.



c'est la meilleure solution


- Des précautions particulières ? Est-ce possible de perdre des données
lors de transfert d'information ?



Personnellement il m'est arrivé un truc bizarre, aléatoirement la trame
était envoyée mais jamais reçu. Je n'en ai jamais compris la raison et le
simple déplacement du programme émetteur sur une autre machine du réseau a
réglé le problème. A mon avis ça doit être tout à fait exceptionnel et si
tu n'as pas de coupure réseau (lien WIFI par exemple) tu ne devrais pas
perdre de données.




en tcp, il est possible de perdre des données si le receveur perd la
connexion
(aucune erreur à l'émission ne garantie pas que les données aient été
reçues)

donc meme en TCP, il vaut mieux acker les messages si on veut être sur de la
réception



Merci pour vos réponses.
Quelle est la facon de faire pour "acker" les messages ?
Romain PETIT
Le #14502781
Bruno Wrk a utilisé son clavier pour écrire :
Quelle est la facon de faire pour "acker" les messages ?



Comme pour ce qui est utilisé couramment avec les ports série.
On suit un protocole de communication.
(en gros, on répond ACK à l'émetteur quand on a bien reçu le message,
NACK quand on détecte une erreur).

http://en.wikibooks.org/wiki/Serial_Programming:Error_Correction_Methods

A+

--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Bruno Wrk
Le #14502771
Romain PETIT avait écrit le 16/06/2008 :
Bruno Wrk a utilisé son clavier pour écrire :
Quelle est la facon de faire pour "acker" les messages ?



Comme pour ce qui est utilisé couramment avec les ports série.
On suit un protocole de communication.
(en gros, on répond ACK à l'émetteur quand on a bien reçu le message, NACK
quand on détecte une erreur).

http://en.wikibooks.org/wiki/Serial_Programming:Error_Correction_Methods

A+



Ok merci ; )

A+
patrice
Le #14502751
"Bruno Wrk" news:
Romain PETIT avait écrit le 16/06/2008 :
> Bruno Wrk a utilisé son clavier pour écrire :
>> Quelle est la facon de faire pour "acker" les messages ?
>
> Comme pour ce qui est utilisé couramment avec les ports série.
> On suit un protocole de communication.
> (en gros, on répond ACK à l'émetteur quand on a bien reçu le message,


NACK
> quand on détecte une erreur).
>



pas besoin de controle de contenu (crc, checksum) en tcp car la couche
transport s'en charge
suffit juste de numéroter les messages et de renvoyer un "OK" avec le numéro
de message
(l'émetteur testant le "OK" et que le numéro du message "ok" est bien
identique a celui du message émis)
JB
Le #14502741
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk écrit:

patrice vient de nous annoncer :
"Emmanuel Haefele" news:48510048$0$872$
"Bruno Wrk" Bonjour Bruno,

Juste 2 petites questions :
- Est-ce possible d'avoir une information de type "chargement" ? Par
exemple si un buffer d'une certaine taille est un train d'arrivé,
peut-on évaluer le temps qu'il reste avant la fin de réception ?


Sans certitude mais je ne pense pas que ce soit possible, par contre
tu
devrais pouvoir gérer cette contrainte toi-même en envoyant dans un
premier temps une trame contenant la taille de ton buffer puis dans un
second temps le contenu de ton buffer.



c'est la meilleure solution


- Des précautions particulières ? Est-ce possible de perdre des
données
lors de transfert d'information ?


Personnellement il m'est arrivé un truc bizarre, aléatoirement la
trame
était envoyée mais jamais reçu. Je n'en ai jamais compris la raison et
le
simple déplacement du programme émetteur sur une autre machine du
réseau a
réglé le problème. A mon avis ça doit être tout à fait exceptionnel et
si
tu n'as pas de coupure réseau (lien WIFI par exemple) tu ne devrais pas
perdre de données.




en tcp, il est possible de perdre des données si le receveur perd la
connexion
(aucune erreur à l'émission ne garantie pas que les données aient été
reçues)

donc meme en TCP, il vaut mieux acker les messages si on veut être sur
de la
réception





Le protocole TCP assure la numérotation , séquencement et acquittement des
messages.

Il n'y a qu'à gérer les ruptures de connexion.



--
JB
patrice
Le #14502731
"JB" news:
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk écrit:

Le protocole TCP assure la numérotation , séquencement et acquittement des
messages.

Il n'y a qu'à gérer les ruptures de connexion.




TCP oui, mais pas la partie cliente
La fonctions "send" se contente de mettre les données à transmettre dans un
buffer
(par exemple, si "nagle" est activé et selon la taille de la "windows", le
buffer est gardé en mémoire histoire de voir si y'a pas d'autre donnée à
transmettre)

gérer la rupture de connexion, pourquoi pas...., mais apres faut retrouver
les x derniers packets et savoir lesquels n'ont pas été recus
beaucoup plus simple de gérer un ack pour chaque packet
JB
Le #14502721
Le Mon, 16 Jun 2008 11:33:27 +0200, patrice écrit:


"JB" news:
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk écrit:

Le protocole TCP assure la numérotation , séquencement et acquittement
des
messages.

Il n'y a qu'à gérer les ruptures de connexion.




TCP oui, mais pas la partie cliente
La fonctions "send" se contente de mettre les données à transmettre dans
un
buffer
(par exemple, si "nagle" est activé et selon la taille de la "windows",
le
buffer est gardé en mémoire histoire de voir si y'a pas d'autre donnée à
transmettre)

gérer la rupture de connexion, pourquoi pas...., mais apres faut
retrouver
les x derniers packets et savoir lesquels n'ont pas été recus
beaucoup plus simple de gérer un ack pour chaque packet




TCP_NODELAY est fait pour cela.

Tu fais comme tu veux.


--
JB
patrice
Le #14502631
JB a écrit :

gérer la rupture de connexion, pourquoi pas...., mais apres faut
retrouver
les x derniers packets et savoir lesquels n'ont pas été recus
beaucoup plus simple de gérer un ack pour chaque packet




TCP_NODELAY est fait pour cela.

Tu fais comme tu veux.




TCP_NODELAY garantie t'il aussi la réception physique.
(les packets tcp ne sont ils pas empilés chez le destinataire en attente
du traitement par la couche applicative ?)

Tu différencie comment une déconnexion du serveur apres réception d'une
déconnexion pendant la réception ?
Publicité
Poster une réponse
Anonyme