En fait ma question est la suivante:
 
Quadn un thread client écrit dans un outputstream redirigé vers un socket, reste il bloqué jusqu'à recevoir la confirmation de la réception du packet par le serveur ?
 
TCP étant reliable je vois mal comment le thread pourrais continuer: en cas de non réception du packet, on est censé avoir une erreur... hors à ma connaissance on ne peut pas avoir d'erreur sur un code qui a déjà été effectué !!!
 
Ce qui signifie que le thread est bloqué tant que la reception du packet n'a pas été confirmé par le serveur. Mais dans ce cas la perte de temps me semble déraisonnable. (ms vs ns?)
 
Où est ce que mon raisonnement cloche???

non c'est correct je pense. Si tu écris sur un distant tu as la main qd ta pile TCP a recu un client ACK pour les paquets que tu as envoyés.
 
donc oui le write() peut prendre dès lors du temps

Ok merci... J'essaierai de me faire confirmer cette interpretation.
 
Dans la même catégorie, un autre point de detail. TCP garantie que les packet sont delivrés... qu'est ce que ca veut dire: Au moins qu ils arrivent sur la machine distante... mais est ce que cela garantie egalement qu'un serveur écoute sur ce port et que le paquet n'est pas tout simplement droppé faute de recepteur...  
 
... dsl mais sur des points de detail comme ca je ne trouve aucune doc.

bin la doc c'est le RFC de TCP qui est la référence ou bien un excellent bouquin "Computer Networks" de A. Tanenbaum.
 
Pour répondre à ta question, chaque paquet TCP doit recevoir un ACK  du récipient. Dans le cas contraire, le client retransmet automatiquement le dit paquet. Si personne n'ACK un paquet, une exception au niveau Java est lancée.

ok, mais qui acknoledge le packet:
- le hardware
- l OS
- le software qui ecoute sur ce port
J opterais plutot pour la seconde solution qui implique que la bonne reception d'un paquet ne garantie en aucun cas qu'un process l'a recuperé de l'autre coté. (Ce process pouvant etre down...)
donc on ne peut pas savoir comme cas si un process est down ou pas, il faut que ce dernier réponde explicitement (C'est juste un exemple).
 
Merci pour ton aide, je vais aller jeter un coup d oeil la bas.

 
ne pas mélanger les couches.
 
Si le processus est down, tu as un close au niveau du socket normallement et donc exception. Dans certains cas, l'implémentation TCP n'est effectivement pas consciente que le processus client est mort mais bon ca ne dure pas longtemps, vu que la taille des buffers est plus que limitée. Sinon pour la réponse explicite oui et non. Cela dit, un mécanisme de ping - pong (ou watchdog) est conseillé si la connection reste ouverte pendant un certain temps.
 
Ce qu'il faut comprendre avec TCP c'est que tu as 2 états: soit il recoit tout et c'est ok, soit il manque qqch et il y a une erreur. La couche TCP s'arrange pour que si tu envoies 'TOTO' le client ne recoives pas 'TOSO'. C'est un niveau plus bas que l'applicatif.
 
 
Un exemple de diagramme de transition d'états:
http://www.ssfnet.org/Exchange/tcp [...] es.html#ST
 
Le mécanisme de fenêtre glissante utilisé pour contrôller la congestion et l'acquittement des paquets:
http://www.ssfnet.org/Exchange/tcp [...] es.html#SW
 
Un cours en Français de mon maitre de stage si nécessaire:
http://www.icampus.ucl.ac.be/claro [...] odule1.pdf

Y a pas a dire tout est la.
Un trés grand merci, pour ton aide.

you're welcome

darklord: pourrais-tu remettre le lien du cours, j'ai une erreur 404 qd j'essaie de le lire??
Merci d'avance

j'pense que c'est parce qu'il faut etre loggé sur le site...

Ah oui, merci
Sinon pas mal ce site, ya plein de trucs en fait.

 
c'est basé sur claroline, un truc d'e-learning qui commence à être relativement connu. Malheureusement il y a bcp de profs qui refusent de publier leurs cours online ce que je trouve ridicule mais bon