Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk <administrator@huh.com> a  écrit:

patrice vient de nous annoncer :

"Emmanuel Haefele" <e.haefele@wanadoo.fr> a écrit dans le message de
news:48510048$0$872$ba4acef3@news.orange.fr...

"Bruno Wrk" <administrator@huh.com> :
 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