Différence entre les sockets STREAM du domaine UNIX et les sockets DATAGRAM?
Cette question est NE PAS pour la différence entre les prises INTERNET de type STREAM et de type DATAGRAM. Je sais que les sockets STREAM utilisent TCP, les sockets Datagram utilisent UDP et tous les trucs TCP, UDP, les paquets arrivant dans l’ordre, ACK, NACK etc. .. Je comprends l’importance de ces informations sur Internet.
Q1) Lorsque je crée un socket de domaine UNIX qui est un socket local, quelle importance aurait-il si le socket est un socket STREAM ou un socket DATAGRAM? Ce type de socket écrirait les données dans le fichier socket. Le protocole importerait-il dans ce cas puisque je ne transmets pas de données sur un réseau? Y at-il un risque de perte de données dans ce cas si j'utilise des sockets DATAGRAM basés sur UNIX?
Q2) Les sockets UNIX DATAGRAM offrent-ils de meilleures performances que les sockets UNIX STREAM?
Q3) Comment choisir un socket basé sur STREAM/DATAGRAM UNIX dans mon application?
Merci
Tout comme la page de manuel indique que les sockets Unix sont toujours fiables. La différence entre SOCK_STREAM et SOCK_DGRAM réside dans la sémantique de la consommation de données hors du socket.
Le socket de flux permet de lire un nombre arbitraire d'octets, tout en préservant la séquence d'octets. En d'autres termes, un expéditeur peut écrire 4K de données dans le socket et le destinataire peut utiliser ces données octet par octet. Le contraire est également vrai: l'expéditeur peut écrire plusieurs petits messages sur la prise que le destinataire peut consommer en une lecture. Le socket de flux ne préserve pas les limites des messages.
Le socket de datagramme, en revanche, conserve ces limites - une écriture de l'expéditeur correspond toujours à une lecture du destinataire (même si le tampon du destinataire attribué à read(2) ou recv(2) est plus petit que ce message) .
Donc, si votre protocole d'application contient de petits messages avec une limite supérieure connue sur la taille du message, mieux vaut utiliser SOCK_DGRAM, car il est plus facile à gérer.
Si votre protocole appelle des charges longues de messages arbitraires ou est simplement un flux non structuré (comme de l'audio brut ou quelque chose de ce genre), choisissez SOCK_STREAM et effectuez la mise en mémoire tampon requise.
Les performances doivent être identiques, car les deux types passent simplement par la mémoire locale dans le noyau, seule la gestion des tampons est différente.
La principale différence est que l’un est basé sur la connexion (STREAM) et l’autre est sans connexion (DGRAM) - la différence entre les communications orientées flux et celles sur les paquets est généralement beaucoup moins importante.
Avec SOCK_STREAM, vous obtenez toujours toute la gestion de la connexion, c'est-à-dire listen/accept et vous pouvez savoir si une connexion est fermée de l'autre côté.
Notez qu'il existe également un type de socket SEQPACKET qui est toujours orienté connexion, mais conserve les limites des messages (ce qui peut vous éviter de mettre en œuvre une couche orientée message au-dessus d'un socket STREAM).
Je m'attendrais à ce que les performances de transfert de données soient similaires pour tous ces types, la principale différence réside simplement dans la sémantique que vous souhaitez.
- Une différence probable sont les limites des messages. Les datagrammes seront livrés dans leur ensemble, les datagrammes constituant les limites naturelles du message. Avec les sockets de flux, vous pouvez lire N octets et le socket bloquera jusqu'à ce que N octets soient prêts. Mais cela ne signifie aucune frontière de message évident.
- Peut être. Un socket de flux avec TCP au moins nécessite la négociation à trois voies initiale pour établir la connexion. Un socket UDP ne le fait pas.
- Toutes choses étant égales par ailleurs, si la vitesse est une préoccupation, un instrument et une mesure. (Je suppose que vous savez déjà que seul un socket de flux TCP fournit un transport en ordre fiable et intégré, et que seuls les sockets de datagramme peuvent être utilisés pour envoyer à multiple récepteurs).
Si les clients et les serveurs sont toujours sur le même ordinateur et que l'objectif est d'obtenir une latence minimale et une bande passante maximale, utilisez la mémoire partagée.