Et s'il n'arrive pas entiérement que se passera-t-il ? Si par exemple un routeur qu'il traverse prend feu !
-Est ce qu'on aura une moitié de fichier à destination ou rien du tout ?
-Est ce que tout les octects du fichiers seront à peu près en ordre ?
-Tu parles du streaming mais ce n'est pas plutot UDP qui est utilisé pour ca ?
Il y a peut-être un protocole plus sécure j'ai entendu parlé d'un truc qui est "l'encapsulation" : si TCP ne renvoit pas le fichier, on peut, peut-être avec l'encapsulation le forcer à afficher les données (incomplètes) qu'il envoit.
Mais peut-être que cela va surcharger le transport innutilement ? (duplication des données ou des entêtes de prôtocole ?)
Parsque peut-être que 1024 était choisis dans le but d'envoyer un message inférieur ou égal à 1024 il ne faut peut-être pas changer cette valeure.
En tous cas j'éspère que le serveur de michelle mad fonctionne désormais.
[^] # Re: TCP
Posté par n0wic . En réponse au message client serveur par socket en clientThread. Évalué à -9.
Et s'il n'arrive pas entiérement que se passera-t-il ? Si par exemple un routeur qu'il traverse prend feu !
-Est ce qu'on aura une moitié de fichier à destination ou rien du tout ?
-Est ce que tout les octects du fichiers seront à peu près en ordre ?
-Tu parles du streaming mais ce n'est pas plutot UDP qui est utilisé pour ca ?
Il y a peut-être un protocole plus sécure j'ai entendu parlé d'un truc qui est "l'encapsulation" : si TCP ne renvoit pas le fichier, on peut, peut-être avec l'encapsulation le forcer à afficher les données (incomplètes) qu'il envoit.
Mais peut-être que cela va surcharger le transport innutilement ? (duplication des données ou des entêtes de prôtocole ?)
Parsque peut-être que 1024 était choisis dans le but d'envoyer un message inférieur ou égal à 1024 il ne faut peut-être pas changer cette valeure.
En tous cas j'éspère que le serveur de michelle mad fonctionne désormais.