Je développe actuellement une application client mail et j'ai une question
quand aux paquets que m'envoie un serveur pop. Après connection au serveur
de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond
+OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets?
(une boucle sur recv() )
Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans
boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs
fois?
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
el8fr
En theorie, rien ne garanti que le message arrive en une seule fois. Le MSS (maximum segment size si mes souvenirs sont bons) est calculé au début de la connexion TCP. Si celui-ci est inférieur à la longueur du paquet envoyé par le serveur alors le paquet sera fragmenté. Il faut donc que tu lise la réponse du serveur tant qu'il y a quelquechose à lire: utilisation de select() sur une socket blocante ou alors read() en boucle sur une socket non blocante. (Voir le groupe dédié à ton OS pour de plus amples informations).
"Nicolas Favre-Félix" wrote in message news:<3f26aeaa$0$1799$...
Bonjour tout le monde.
Je développe actuellement une application client mail et j'ai une question quand aux paquets que m'envoie un serveur pop. Après connection au serveur de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond +OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets? (une boucle sur recv() ) Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs fois?
Merci de votre aide.
En theorie, rien ne garanti que le message arrive en une seule fois.
Le MSS (maximum segment size si mes souvenirs sont bons) est calculé
au début de la connexion TCP. Si celui-ci est inférieur à la longueur
du paquet envoyé par le serveur alors le paquet sera fragmenté.
Il faut donc que tu lise la réponse du serveur tant qu'il y a
quelquechose à lire: utilisation de select() sur une socket blocante
ou alors read() en boucle sur une socket non blocante. (Voir le groupe
dédié à ton OS pour de plus amples informations).
"Nicolas Favre-Félix" <n.favrefelix@__NOSPAM__free.fr> wrote in message news:<3f26aeaa$0$1799$626a54ce@news.free.fr>...
Bonjour tout le monde.
Je développe actuellement une application client mail et j'ai une question
quand aux paquets que m'envoie un serveur pop. Après connection au serveur
de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond
+OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets?
(une boucle sur recv() )
Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans
boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs
fois?
En theorie, rien ne garanti que le message arrive en une seule fois. Le MSS (maximum segment size si mes souvenirs sont bons) est calculé au début de la connexion TCP. Si celui-ci est inférieur à la longueur du paquet envoyé par le serveur alors le paquet sera fragmenté. Il faut donc que tu lise la réponse du serveur tant qu'il y a quelquechose à lire: utilisation de select() sur une socket blocante ou alors read() en boucle sur une socket non blocante. (Voir le groupe dédié à ton OS pour de plus amples informations).
"Nicolas Favre-Félix" wrote in message news:<3f26aeaa$0$1799$...
Bonjour tout le monde.
Je développe actuellement une application client mail et j'ai une question quand aux paquets que m'envoie un serveur pop. Après connection au serveur de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond +OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets? (une boucle sur recv() ) Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs fois?
Merci de votre aide.
T0t0
"Nicolas Favre-Félix" wrote in message news:3f26aeaa$0$1799$
Je développe actuellement une application client mail et j'ai une question quand aux paquets que m'envoie un serveur pop. Après connection au serveur de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond +OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets? (une boucle sur recv() ) Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs fois?
En fait, la fragmentation n'est pas gérée par la couche applicative mais par la couche 3 IP. Donc vu de ton application, tu n'as pas besoin de te soucier d'une quelconque fragmentation. Cela se fera silencieusement par la couche 3 s'il y en a besoin. C'est l'avantage du modèle en couches. Chaque couche assure des tâches particulières et ne se soucie pas des autres.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Nicolas Favre-Félix" <n.favrefelix@__NOSPAM__free.fr> wrote in message
news:3f26aeaa$0$1799$626a54ce@news.free.fr
Je développe actuellement une application client mail et j'ai une question
quand aux paquets que m'envoie un serveur pop. Après connection au serveur
de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond
+OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets?
(une boucle sur recv() )
Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans
boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs
fois?
En fait, la fragmentation n'est pas gérée par la couche applicative
mais par la couche 3 IP. Donc vu de ton application, tu n'as pas besoin
de te soucier d'une quelconque fragmentation. Cela se fera
silencieusement par la couche 3 s'il y en a besoin.
C'est l'avantage du modèle en couches. Chaque couche assure des tâches
particulières et ne se soucie pas des autres.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Nicolas Favre-Félix" wrote in message news:3f26aeaa$0$1799$
Je développe actuellement une application client mail et j'ai une question quand aux paquets que m'envoie un serveur pop. Après connection au serveur de mail, j'envoie des requetes comme "USER xxxxx" et le serveur me répond +OK ou -ERR. Mais ces réponses peuvent-elles arriver en plusieurs paquets? (une boucle sur recv() ) Dans mon bouquin de programmation réseau, ils ne font qu'un recv sans boucler. Est-ce correct ou ces messages peuvent-ils arriver en plusieurs fois?
En fait, la fragmentation n'est pas gérée par la couche applicative mais par la couche 3 IP. Donc vu de ton application, tu n'as pas besoin de te soucier d'une quelconque fragmentation. Cela se fera silencieusement par la couche 3 s'il y en a besoin. C'est l'avantage du modèle en couches. Chaque couche assure des tâches particulières et ne se soucie pas des autres.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
T0t0
"Patrick_91" wrote in message news:
Mais le boulot de la couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une application, et se doit de rester absolument transparent faut de quoi de bon vieux problemes d'interoperabilite sont a prevoir !! ..
Tout à fait.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Patrick_91" <patrick_91@nospam.com> wrote in message
news:1073899.iRZI44ZhVM@news.wanadoo.fr
Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite
les data d'origine de facon transparente pour les applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une
application, et se doit de rester absolument transparent faut de quoi de
bon vieux problemes d'interoperabilite sont a prevoir !! ..
Tout à fait.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Mais le boulot de la couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une application, et se doit de rester absolument transparent faut de quoi de bon vieux problemes d'interoperabilite sont a prevoir !! ..
Tout à fait.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Nicolas Favre-Félix
Idealement et meme pratiquement ca n'a aucune importance, pour programmer au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5) .
Tout à fait d'accord mais la fragmentation pose problème
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une application, et se doit de rester absolument transparent faut de quoi de bon vieux problemes d'interoperabilite sont a prevoir !! ..
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK ") puis je m'attendais à recevoir 0 puisque le serveur attends une commande USER. Mais la fonction recv boucle pendant au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas détecter la fin de son message, et si le serveur fragmente sa réponse je ne pourrais pas recevoir la fin. Comment faire?
Amicalement
-- Patrick Dept 91
Merci
Idealement et meme pratiquement ca n'a aucune importance, pour programmer
au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se
preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation
et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de
la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite
les data d'origine de facon transparente pour les applications (couche 5)
.
Tout à fait d'accord mais la fragmentation pose problème
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une
application, et se doit de rester absolument transparent faut de quoi de
bon vieux problemes d'interoperabilite sont a prevoir !! ..
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être
sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le
nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre
soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK
<423.6546465461@pop1-2.free.fr>") puis je m'attendais à recevoir 0 puisque
le serveur attends une commande USER. Mais la fonction recv boucle pendant
au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas
détecter la fin de son message, et si le serveur fragmente sa réponse je ne
pourrais pas recevoir la fin. Comment faire?
Idealement et meme pratiquement ca n'a aucune importance, pour programmer au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5) .
Tout à fait d'accord mais la fragmentation pose problème
Donc a mon avis ceci ne doit absolument pas influer sur l'ecriture d'une application, et se doit de rester absolument transparent faut de quoi de bon vieux problemes d'interoperabilite sont a prevoir !! ..
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK ") puis je m'attendais à recevoir 0 puisque le serveur attends une commande USER. Mais la fonction recv boucle pendant au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas détecter la fin de son message, et si le serveur fragmente sa réponse je ne pourrais pas recevoir la fin. Comment faire?
Amicalement
-- Patrick Dept 91
Merci
Patrick_91
T0t0 wrote:
"Patrick_91" wrote in message news:
Mais le boulot de la couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
OUi raccourci allegre de ma part, je voulais dire : frag et defrag (couche 3 reseau ) mais la restitution de l'integralite des datas est du ressort de la couche 4 (session tcp dans ce cas )
Dont acte ..
Amicalement
-- Patrick Dept 91
T0t0 wrote:
"Patrick_91" <patrick_91@nospam.com> wrote in message
news:1073899.iRZI44ZhVM@news.wanadoo.fr
Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer
l'integralite les data d'origine de facon transparente pour les
applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
OUi raccourci allegre de ma part, je voulais dire : frag et defrag (couche 3
reseau ) mais la restitution de l'integralite des datas est du ressort de
la couche 4 (session tcp dans ce cas )
Mais le boulot de la couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Houla, fragmentation en couche 3, pas 4 :-)
OUi raccourci allegre de ma part, je voulais dire : frag et defrag (couche 3 reseau ) mais la restitution de l'integralite des datas est du ressort de la couche 4 (session tcp dans ce cas )
Dont acte ..
Amicalement
-- Patrick Dept 91
Patrick_91
Nicolas Favre-Félix wrote:
Idealement et meme pratiquement ca n'a aucune importance, pour programmer au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Bonjour
Comme ditet suite a la remarque de "T0t0 " c'est la couche 3 (couche reseau IP) qui fragmente et reassemble les packets au gre des besoins (carracteristiques des interfaces), et non pas la couche 4 (session tcp). En effet la couche 4 extrait les donnees d'un packet reassemble et donc , si vous travaillez au niveau session tcp il n'y a pas de raison de s'apercevoir qu'il y a eu ou non Frangmentation.
D'autre part, lors de la negociation d'ouverture de session pop3 il n'y a aucune raison qu'une fragmentation se fasse car il sagit de packets tres courts . Certainement un bug quelque part car dans cette phase la il n'y a pas matirer a fragmentation.
Amicalement
-- Patrick Dept 91
Nicolas Favre-Félix wrote:
Idealement et meme pratiquement ca n'a aucune importance, pour programmer
au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se
preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation
et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de
la
couche 4 c'est aussi de defragmenter tout ca et de restituer
l'integralite les data d'origine de facon transparente pour les
applications (couche 5)
Bonjour
Comme ditet suite a la remarque de "T0t0 <bibi@antionline.org>" c'est la
couche 3 (couche reseau IP) qui fragmente et reassemble les packets au gre
des besoins (carracteristiques des interfaces), et non pas la couche 4
(session tcp). En effet la couche 4 extrait les donnees d'un packet
reassemble et donc , si vous travaillez au niveau session tcp il n'y a pas
de raison de s'apercevoir qu'il y a eu ou non Frangmentation.
D'autre part, lors de la negociation d'ouverture de session pop3 il n'y a
aucune raison qu'une fragmentation se fasse car il sagit de packets tres
courts . Certainement un bug quelque part car dans cette phase la il n'y a
pas matirer a fragmentation.
Idealement et meme pratiquement ca n'a aucune importance, pour programmer au
niveau application (couche 5 tcp/ip) il n'y a aucune raison de se preoccuper de ce qui se passe au niveau session tcp (couche 4) .
Ben justement si:
Si la taille pratique du packet excede MSS alors il y aura fragmentation et les donnees
seront envoyees sur plusieurs packets (Fragmentation). Mais le boulot de la
couche 4 c'est aussi de defragmenter tout ca et de restituer l'integralite les data d'origine de facon transparente pour les applications (couche 5)
Bonjour
Comme ditet suite a la remarque de "T0t0 " c'est la couche 3 (couche reseau IP) qui fragmente et reassemble les packets au gre des besoins (carracteristiques des interfaces), et non pas la couche 4 (session tcp). En effet la couche 4 extrait les donnees d'un packet reassemble et donc , si vous travaillez au niveau session tcp il n'y a pas de raison de s'apercevoir qu'il y a eu ou non Frangmentation.
D'autre part, lors de la negociation d'ouverture de session pop3 il n'y a aucune raison qu'une fragmentation se fasse car il sagit de packets tres courts . Certainement un bug quelque part car dans cette phase la il n'y a pas matirer a fragmentation.
Amicalement
-- Patrick Dept 91
Olivier Macchioni
On Wed, 30 Jul 2003 11:38:52 +0200, "Nicolas Favre-Félix" wrote:
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK ") puis je m'attendais à recevoir 0 puisque le serveur attends une commande USER. Mais la fonction recv boucle pendant au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas détecter la fin de son message, et si le serveur fragmente sa réponse je ne pourrais pas recevoir la fin. Comment faire?
"Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit qu'un message POP fait 512 caractères : si ton client attaque un serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2 messages courts concaténés, reçus lors d'un seul recv(). Il faudrait donc également le prendre en compte.
Olivier
P.S. les 30 secondes, on dirait que ça correspond au timeout TCP.
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être
sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le
nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre
soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK
<423.6546465461@pop1-2.free.fr>") puis je m'attendais à recevoir 0 puisque
le serveur attends une commande USER. Mais la fonction recv boucle pendant
au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas
détecter la fin de son message, et si le serveur fragmente sa réponse je ne
pourrais pas recevoir la fin. Comment faire?
"Responses in the POP3 consist of a status indicator and a keyword
possibly followed by additional information. All responses are
terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit
qu'un message POP fait 512 caractères : si ton client attaque un
serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2
messages courts concaténés, reçus lors d'un seul recv(). Il faudrait
donc également le prendre en compte.
Olivier
P.S. les 30 secondes, on dirait que ça correspond au timeout TCP.
On Wed, 30 Jul 2003 11:38:52 +0200, "Nicolas Favre-Félix" wrote:
J'avais commencé par faire ça "proprement" en bouclant sur le recv pour être sûr de tout recevoir en cas de fragmentation. La fonction recv renvoie le nombre d'octets reçus, je faisais donc une boucle jusqu'à ce que ce nombre soit égal à 0. Mais je recevais d'abord l'dentification du serveur ("+OK ") puis je m'attendais à recevoir 0 puisque le serveur attends une commande USER. Mais la fonction recv boucle pendant au moins 30 secondes avant de renvoyer SOCKET_ERROR. Je ne peux donc pas détecter la fin de son message, et si le serveur fragmente sa réponse je ne pourrais pas recevoir la fin. Comment faire?
"Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit qu'un message POP fait 512 caractères : si ton client attaque un serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2 messages courts concaténés, reçus lors d'un seul recv(). Il faudrait donc également le prendre en compte.
Olivier
P.S. les 30 secondes, on dirait que ça correspond au timeout TCP.
PYT
La fragmentation des datagrammes IP est traitée au niveau de la couche 3, et cela n'a aucune importance pour les applications utilisant TCP. Par contre, il ne faut pas oublier que TCP transmet des FLUX, et non pas des datagrammes. Il n'y a donc aucune raison pour que les appels de primitives correspondent à un datagramme IP au niveau de la machine locale; et a fortiori aucune raison pour que les send et recv de deux machines distantes soient appairés. Charge aux applications de retrouver dans le flux les marqueurs convenus pour identifier les unités sémantiques.
Au contraire, UDP transmet des DATAGRAMMES: ils sont restitués tels que émis (sans faute et complets: le traitement des fragments assuré par IP**, et il y a un CRC pour éliminer les erreurs). Mais comme c'est n'est PAS un protocole de flux, il n'y a aucune raison pour que N datagrammes émis arrivent tous, et encore moins de raison qu'ils arrivent dans l'ordre d'émission. Et là, on ne peut même pas resynchroniser les applications en fermant la socket.
** Enfin presque, parceque l'implémentation que j'ai pu utiliser était erronnée en mélangeant le problème du MTU avec la couche 4, dans la machine de départ. Resultat: les datagrammes n'arrivaient même pas complets!
La fragmentation des datagrammes IP est traitée au niveau de la couche 3, et
cela n'a aucune importance pour les applications utilisant TCP.
Par contre, il ne faut pas oublier que TCP transmet des FLUX, et non pas des
datagrammes. Il n'y a donc aucune raison pour que les appels de primitives
correspondent à un datagramme IP au niveau de la machine locale; et a
fortiori aucune raison pour que les send et recv de deux machines distantes
soient appairés.
Charge aux applications de retrouver dans le flux les marqueurs convenus
pour identifier les unités sémantiques.
Au contraire, UDP transmet des DATAGRAMMES: ils sont restitués tels que émis
(sans faute et complets: le traitement des fragments assuré par IP**, et il
y a un CRC pour éliminer les erreurs). Mais comme c'est n'est PAS un
protocole de flux, il n'y a aucune raison pour que N datagrammes émis
arrivent tous, et encore moins de raison qu'ils arrivent dans l'ordre
d'émission. Et là, on ne peut même pas resynchroniser les applications en
fermant la socket.
** Enfin presque, parceque l'implémentation que j'ai pu utiliser était
erronnée en mélangeant le problème du MTU avec la couche 4, dans la machine
de départ. Resultat: les datagrammes n'arrivaient même pas complets!
La fragmentation des datagrammes IP est traitée au niveau de la couche 3, et cela n'a aucune importance pour les applications utilisant TCP. Par contre, il ne faut pas oublier que TCP transmet des FLUX, et non pas des datagrammes. Il n'y a donc aucune raison pour que les appels de primitives correspondent à un datagramme IP au niveau de la machine locale; et a fortiori aucune raison pour que les send et recv de deux machines distantes soient appairés. Charge aux applications de retrouver dans le flux les marqueurs convenus pour identifier les unités sémantiques.
Au contraire, UDP transmet des DATAGRAMMES: ils sont restitués tels que émis (sans faute et complets: le traitement des fragments assuré par IP**, et il y a un CRC pour éliminer les erreurs). Mais comme c'est n'est PAS un protocole de flux, il n'y a aucune raison pour que N datagrammes émis arrivent tous, et encore moins de raison qu'ils arrivent dans l'ordre d'émission. Et là, on ne peut même pas resynchroniser les applications en fermant la socket.
** Enfin presque, parceque l'implémentation que j'ai pu utiliser était erronnée en mélangeant le problème du MTU avec la couche 4, dans la machine de départ. Resultat: les datagrammes n'arrivaient même pas complets!
Nicolas Favre-Félix
"Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit qu'un message POP fait 512 caractères : si ton client attaque un serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2 messages courts concaténés, reçus lors d'un seul recv(). Il faudrait donc également le prendre en compte.
Merci à vous tous c'est parfait. En effet les messages ne font pas 512 caractères, je vais donc chercher le CRLF.
"Responses in the POP3 consist of a status indicator and a keyword
possibly followed by additional information. All responses are
terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit
qu'un message POP fait 512 caractères : si ton client attaque un
serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2
messages courts concaténés, reçus lors d'un seul recv(). Il faudrait
donc également le prendre en compte.
Merci à vous tous c'est parfait. En effet les messages ne font pas 512
caractères, je vais donc chercher le CRLF.
"Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair." (RFC 1939)
-> et hop, on cherche un CRLF (et on ne se fie pas à la RFC qui dit qu'un message POP fait 512 caractères : si ton client attaque un serveur qui n'obéit pas à la RFC, il risque de mal se comporter)
Attention, j'ai déjà observé le cas inverse à la défragmentation : 2 messages courts concaténés, reçus lors d'un seul recv(). Il faudrait donc également le prendre en compte.
Merci à vous tous c'est parfait. En effet les messages ne font pas 512 caractères, je vais donc chercher le CRLF.
