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.
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é.
"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.
- 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.
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
"Emmanuel Haefele" a écrit dans le message de 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
"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
"Emmanuel Haefele" a écrit dans le message de 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
patrice vient de nous annoncer :
"Emmanuel Haefele" a écrit dans le message de 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 ?
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
Merci pour vos réponses.
Quelle est la facon de faire pour "acker" les messages ?
"Emmanuel Haefele" a écrit dans le message de 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
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).
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
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).
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).
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Bruno Wrk
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).
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).
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).
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)
"Bruno Wrk" <administrator@huh.com> a écrit dans le message de
news:mn.826a7d868fcddd61.85589@huh.com...
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)
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 Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a écrit:
patrice vient de nous annoncer :
"Emmanuel Haefele" a écrit dans le message de 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
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...
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.
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a écrit:
patrice vient de nous annoncer :
"Emmanuel Haefele" a écrit dans le message de 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
"JB" a écrit dans le message de news:
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a é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" <j.bres@on.invalid.invalid> a écrit dans le message de
news:op.uct37uni8kdmmw@jbxp...
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk <administrator@huh.com> a
é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
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a é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 Mon, 16 Jun 2008 11:33:27 +0200, patrice a écrit:
"JB" a écrit dans le message de news:
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a é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
Le Mon, 16 Jun 2008 11:33:27 +0200, patrice <patrice@idea.dnsalias.net> a
écrit:
"JB" <j.bres@on.invalid.invalid> a écrit dans le message de
news:op.uct37uni8kdmmw@jbxp...
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk <administrator@huh.com> a
é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
Le Mon, 16 Jun 2008 11:33:27 +0200, patrice a écrit:
"JB" a écrit dans le message de news:
Le Mon, 16 Jun 2008 09:41:53 +0200, Bruno Wrk a é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
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 ?
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 ?
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 ?
