Est-ce que toutes les implémentations TCP/IP
sont immunisées face à ce problème ?
Sur un réseau local, j'ai un client Windows qui
communique avec une machine exotique;
l'application Windows étant particulièrement peu performante,
le dialogue entre les deux part en live au bout d'un moment;
l'analyse des dumps TCP montre que le client diminue sans cesse sa fenêtre
et le dialogue cesse à ce moment.
Le problème est que la partie 'exotique' ( un système embarqué ) bouffe
toutes ses ressources TCP ( mbuf ) a l'issue de cette situation.
Je me demande donc si elle gére correctement le phénomène cité en objet,
ou si ça vient d'ailleurs...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Herm
"Stan" a écrit dans le message de news:
Bonjour,
Bonjour,
Est-ce que toutes les implémentations TCP/IP sont immunisées face à ce problème ?
La théorie voudrait qu'on dise oui, sauf cas critique de la liaison totalement coupée, mais la réalité ...
Sur un réseau local, j'ai un client Windows qui communique avec une machine exotique; l'application Windows étant particulièrement peu performante, le dialogue entre les deux part en live au bout d'un moment; l'analyse des dumps TCP montre que le client diminue sans cesse sa fenêtre et le dialogue cesse à ce moment.
La fenêtre en question, c'est RWIN si je suis bien. Or RWIN va bufferiser des paquets entrants qui n'arriveraient pas dans le bon ordre. Notemment, s'il manque un paquet (perdu dans la nature, checksum erroné...), les paquets qui suivent sont stokés en RWIN, et dans les ACK qui partent du poste client, le RWIN sera diminué au fur et à mesure des paquets stockés.
Plusieurs mécanismes permetteraient au poste client Windows de signaler à son correspondant qu'un paquet manque : - Duplicate ACK (renvoi du même ACK, le dernier correct, plusieurs fois. En général, 3 réémission d'un ACK signale à celui qui le reçoit que le paquet contenant les données de la séquence qui suit le n° présent dans l'ACK est à re-émettre). - Selective ACK (Un message optionnel est ajouté à l'ACK qui décrit clairement le ou les paquets manquants).
Un utilitaire du type DrTCP de dslreports permet de forcer l'activation de ces options sur un système windows, mais il me semble qu'elles sont activées, par défaut.
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est sensée supporter...), cela permettrait peut-être de laisser le temps au système embarqué de s'apperçevoir qu'une trame est à re-émettre, et de faire cette re-émission, avant saturation totale du RWIN...
Le problème est que la partie 'exotique' ( un système embarqué ) bouffe toutes ses ressources TCP ( mbuf ) a l'issue de cette situation. Je me demande donc si elle gére correctement le phénomène cité en objet, ou si ça vient d'ailleurs...
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par cause d'abence d'ACK validant les données envoyées...
Merci pour vos reflexions ;-) -- -Stan
-- Herm
"Stan" a écrit dans le message de news:
Bonjour,
Bonjour,
Est-ce que toutes les implémentations TCP/IP
sont immunisées face à ce problème ?
La théorie voudrait qu'on dise oui, sauf cas critique de la liaison
totalement coupée, mais la réalité ...
Sur un réseau local, j'ai un client Windows qui
communique avec une machine exotique;
l'application Windows étant particulièrement peu performante,
le dialogue entre les deux part en live au bout d'un moment;
l'analyse des dumps TCP montre que le client diminue sans cesse sa
fenêtre
et le dialogue cesse à ce moment.
La fenêtre en question, c'est RWIN si je suis bien. Or RWIN va
bufferiser des paquets entrants qui n'arriveraient pas dans le bon
ordre. Notemment, s'il manque un paquet (perdu dans la nature, checksum
erroné...), les paquets qui suivent sont stokés en RWIN, et dans les ACK
qui partent du poste client, le RWIN sera diminué au fur et à mesure des
paquets stockés.
Plusieurs mécanismes permetteraient au poste client Windows de signaler
à son correspondant qu'un paquet manque :
- Duplicate ACK (renvoi du même ACK, le dernier correct, plusieurs fois.
En général, 3 réémission d'un ACK signale à celui qui le reçoit que le
paquet contenant les données de la séquence qui suit le n° présent dans
l'ACK est à re-émettre).
- Selective ACK (Un message optionnel est ajouté à l'ACK qui décrit
clairement le ou les paquets manquants).
Un utilitaire du type DrTCP de dslreports permet de forcer l'activation
de ces options sur un système windows, mais il me semble qu'elles sont
activées, par défaut.
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il
va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en
face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter
le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est
sensée supporter...), cela permettrait peut-être de laisser le temps au
système embarqué de s'apperçevoir qu'une trame est à re-émettre, et de
faire cette re-émission, avant saturation totale du RWIN...
Le problème est que la partie 'exotique' ( un système embarqué )
bouffe
toutes ses ressources TCP ( mbuf ) a l'issue de cette situation.
Je me demande donc si elle gére correctement le phénomène cité en
objet,
ou si ça vient d'ailleurs...
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par
cause d'abence d'ACK validant les données envoyées...
Est-ce que toutes les implémentations TCP/IP sont immunisées face à ce problème ?
La théorie voudrait qu'on dise oui, sauf cas critique de la liaison totalement coupée, mais la réalité ...
Sur un réseau local, j'ai un client Windows qui communique avec une machine exotique; l'application Windows étant particulièrement peu performante, le dialogue entre les deux part en live au bout d'un moment; l'analyse des dumps TCP montre que le client diminue sans cesse sa fenêtre et le dialogue cesse à ce moment.
La fenêtre en question, c'est RWIN si je suis bien. Or RWIN va bufferiser des paquets entrants qui n'arriveraient pas dans le bon ordre. Notemment, s'il manque un paquet (perdu dans la nature, checksum erroné...), les paquets qui suivent sont stokés en RWIN, et dans les ACK qui partent du poste client, le RWIN sera diminué au fur et à mesure des paquets stockés.
Plusieurs mécanismes permetteraient au poste client Windows de signaler à son correspondant qu'un paquet manque : - Duplicate ACK (renvoi du même ACK, le dernier correct, plusieurs fois. En général, 3 réémission d'un ACK signale à celui qui le reçoit que le paquet contenant les données de la séquence qui suit le n° présent dans l'ACK est à re-émettre). - Selective ACK (Un message optionnel est ajouté à l'ACK qui décrit clairement le ou les paquets manquants).
Un utilitaire du type DrTCP de dslreports permet de forcer l'activation de ces options sur un système windows, mais il me semble qu'elles sont activées, par défaut.
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est sensée supporter...), cela permettrait peut-être de laisser le temps au système embarqué de s'apperçevoir qu'une trame est à re-émettre, et de faire cette re-émission, avant saturation totale du RWIN...
Le problème est que la partie 'exotique' ( un système embarqué ) bouffe toutes ses ressources TCP ( mbuf ) a l'issue de cette situation. Je me demande donc si elle gére correctement le phénomène cité en objet, ou si ça vient d'ailleurs...
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par cause d'abence d'ACK validant les données envoyées...
Merci pour vos reflexions ;-) -- -Stan
-- Herm
Stan
"Herm" a écrit dans le message de news:45083d98$0$21151$
"Stan" a écrit dans le message de news:
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
Je pense qu'on est dans ce cas de figure là ( épuisement du tempon d'émission ).
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est sensée supporter...), cela permettrait peut-être de laisser le temps au
D'après le trafic TCP, le client Windows démarre avec cette taille là. Mais la taille diminue rapidement vu le peu de performance de l'application ( un truc développé en VB ;-) )
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par cause d'abence d'ACK validant les données envoyées...
Je ne met pas en cause le client Windows étant donné qu'il fonctionne avec d'autre machine.
Merci pour ces précisions.
-- -Stan
"Herm" <Herm@invalid.invalid> a écrit dans le message de
news:45083d98$0$21151$7a628cd7@news.club-internet.fr...
"Stan" a écrit dans le message de news:
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il
va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en
face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
Je pense qu'on est dans ce cas de figure là ( épuisement du tempon
d'émission ).
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter
le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est
sensée supporter...), cela permettrait peut-être de laisser le temps au
D'après le trafic TCP, le client Windows démarre avec cette taille là.
Mais la taille diminue rapidement vu le peu de performance de l'application
( un truc développé en VB ;-) )
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par
cause d'abence d'ACK validant les données envoyées...
Je ne met pas en cause le client Windows étant donné qu'il fonctionne
avec d'autre machine.
"Herm" a écrit dans le message de news:45083d98$0$21151$
"Stan" a écrit dans le message de news:
Si le système embarqué ne sait interpréter aucun de ces mécanismes, il va continuer à émettre jusqu'à épuisement du RWIN de la machine d'en face ou de son propre tampon d'émission, et là, arrêt forcé du dialogue.
Je pense qu'on est dans ce cas de figure là ( épuisement du tempon d'émission ).
A tester aussi, mais j'ai des doutes sur le résultat, c'est d'augmenter le RWIN du client Windows jusqu'à 65535 (la limite que toute pile IP est sensée supporter...), cela permettrait peut-être de laisser le temps au
D'après le trafic TCP, le client Windows démarre avec cette taille là. Mais la taille diminue rapidement vu le peu de performance de l'application ( un truc développé en VB ;-) )
Une hypothèse parmis d'autres : Tampon d'émission probablement plein par cause d'abence d'ACK validant les données envoyées...
Je ne met pas en cause le client Windows étant donné qu'il fonctionne avec d'autre machine.
