Je ne suis pas expert en réseau, mais voilà comment il me semble que cela marche :
La couche physique envoie des messages encodés d'une certaine manière et n'est pas fiable (ou peu). C'est le câble.
La couche lien s'occupe de prendre une trame et de la convertir en un message encodé pour la couche physique. C'est le cas d'Ethernet, ou des normes WiFi. Encore une fois, même si elles font des choses pour limiter les pertes, elles ne sont pas fiables.
La couche protocole (IP) s'occupe d'envoyer un message à une destination distance (c'est à dire pas uniquement sur le lien local) et gère en particulier le routage. Encore une fois elle n'est pas fiable (enfin, autant que les couches en dessous)
Enfin, la couche transport (TCP/UDP) s'occupe des mécanismes plus haut niveau pour envoyer des messages via IP. En particulier, TCP va découper les messages, et même si les paquets arrivent dans le désordre il est capable de les remettre dans le bon. En plus, il gère dans une certaine mesure la perte de paquet et normalement il est fiable.
C'est le protocole TCP qui gère tout pour nous dans le cas du streaming : l'ordre, la perte, etc ...
Ça dépend pour quoi, UDP est un protocole qui gère les choses de manière très différente. Par exemple, il y a une notion de message, et on récupère/envoie des messages « en un bloc ». En revanche, il n'y a aucune garantie d'ordre d'arrivée, et pas de gestion des pertes. En contre partie, c'est beaucoup plus rapide que TCP.
De manière historique, TCP est clairement un protocole destiné à gérer des flux de données, et on peut le constater non seulement par la sémantique des appels recv et send, mais aussi en regardant le nom associé pour la création de la socket SOCK_STREAM.
Cela dépend de l'utilisation, ici j'avais l'impression qu'il voulait quelque chose de simple, et ajouter encore une couche (comme HTTP) serait un peu surfait.
Non il ne faut pas changer la valeur 1024, enfin, cela ne va pas changer grand chose. De toute manière, l'API socket est la suivante : quand on fait un recv (1024), il nous donne un contenu qui fera au plus 1024 octets, mais peut-être qu'il en fait beaucoup moins ! Du coup, même si la taille du fichier envoyé est inférieure à 1024, il se peut que TCP découpe et que deux/trois/mille recv soient nécessaires ...
[^] # Re: TCP
Posté par Aluminium95 . En réponse au message client serveur par socket en clientThread. Évalué à 1.
Je ne suis pas expert en réseau, mais voilà comment il me semble que cela marche :
C'est le protocole TCP qui gère tout pour nous dans le cas du streaming : l'ordre, la perte, etc ...
Ça dépend pour quoi, UDP est un protocole qui gère les choses de manière très différente. Par exemple, il y a une notion de message, et on récupère/envoie des messages « en un bloc ». En revanche, il n'y a aucune garantie d'ordre d'arrivée, et pas de gestion des pertes. En contre partie, c'est beaucoup plus rapide que TCP.
De manière historique, TCP est clairement un protocole destiné à gérer des flux de données, et on peut le constater non seulement par la sémantique des appels
recvetsend, mais aussi en regardant le nom associé pour la création de la socketSOCK_STREAM.Cela dépend de l'utilisation, ici j'avais l'impression qu'il voulait quelque chose de simple, et ajouter encore une couche (comme HTTP) serait un peu surfait.
Non il ne faut pas changer la valeur 1024, enfin, cela ne va pas changer grand chose. De toute manière, l'API socket est la suivante : quand on fait un
recv (1024), il nous donne un contenu qui fera au plus 1024 octets, mais peut-être qu'il en fait beaucoup moins ! Du coup, même si la taille du fichier envoyé est inférieure à 1024, il se peut que TCP découpe et que deux/trois/millerecvsoient nécessaires ...