J'ai écrit un serveur en Python qui est destiné à envoyer des données au client dans le formulaire "En-tête: Message"
J'aimerais pouvoir avoir chaque message envoyé individuellement afin que le client ait besoin de Effectuer un travail minimal afin de lire "l'en-tête" et le "message" p>
Malheureusement, je ne peux pas comprendre comment affiner correctement une prise Python, alors lorsque j'ai plusieurs envois exécutés dans une succession rapide les messages Faites-vous regroupement dans le tampon de socket et envoyé comme un gros morceau. p>
Exemple: p>
Server envoie ... P>
header1:message1 header2:message2 header3:message3
3 Réponses :
Je suppose que vous parlez sur une connexion TCP.
Votre approche est défectueuse. Un flux TCP est défini comme un flux d'octets. Vous devez toujours utiliser une sorte de séparateur et ne pas compter sur la pile de réseau pour séparer vos messages.
Si vous avez vraiment besoin d'un commutateur de services basé sur le datagramme sur UDP. Vous aurez besoin de gérer votre retransmission dans ce cas.
clarifier:
Rincer Le tampon d'envoi crée généralement de nouveaux paquets, comme vous vous attendez. Si votre client lit ces paquets assez rapidement, vous pouvez obtenir un message par lecture.
Imaginez maintenant que vous communiquez sur une liaison satellite. En raison de la bande passante élevée et de la latence, le dernier routeur avant que le SAT attend une courte période jusqu'à ce que suffisamment de données soit dans le tampon et envoie tous vos paquets à la fois. Votre client recevra maintenant tous les paquets sans délai et mettra toutes les données dans le tampon de réception à la fois. Donc, votre séparation est de retour.
+1: J'ajouterais l'amour des œuvrages que, même si @ JAH était de chasser les sockets, son client recevrait toujours les messages exactement de la même manière - Rinçage consiste à éliminer les tampons au nom de la réduction de la latence et Pas Messages de démarquation.
+1: TCP est un flux. La synchronisation des données TCP est spécifiquement éliminée par le routage Internet et le protocole TCP. Les données doivent être tamponnées; "Flushing" ne signifie pas beaucoup beaucoup. Tout cela signifie que vos données sont hors de la mémoire tampon de votre application et dans le tampon de protocole TCP.
Ce que vous essayez de faire, est divisé vos données en "lots".
Par exemple, vous fonctionnez sur "lots" chaque fois que vous lisez "lignes" sur un fichier. Qu'est-ce qui définit une "ligne"? C'est une séquence d'octets terminés par '\ N'. Un autre exemple est: vous avez lu 64KIB "CHUnks" sur un fichier. Qu'est-ce qui définit un "morceau"? Vous faites, puisque vous lisez 65536 octets à chaque fois. Vous voulez une longueur variable "morceau"? Vous venez de préfixer votre "morceau" avec sa taille, puis lisez le "morceau". Les fichiers "AIFF" (dont les implémentations sont également les fichiers .wav et .avi de MS Windows) et des fichiers "MOV" sont organisés comme ça.
Ces trois méthodes sont les méthodes les plus fondamentales pour organiser un flux d'octets, quel que soit le support:
Ils peuvent être mélangés et / ou modifiés. Par exemple, vous pouvez avoir des "séparateurs de disques variables", comme un lecteur XML: lire les octets de la première '<' jusqu'à la première ">", ajoutez une barre oblique après d'abord "<" et appelez-la en fin de compte, lecture de flux jusqu'à ce que fin de compte. C'est juste une description brute.
Choisissez une méthode et mettez-la dans l'écrivain et le lecteur. Si vous documentez également vos choix, vous venez de définir votre premier protocole.
juste appendez \ n après chaque message ...
comme
"\ n" ne garantit pas que les messages sont séparés.
Cette réponse est toujours fausse et je ne peux pas croire personne non modifiée ni supprimé d'ici: le \ n ajoute seulement une nouvelle ligne à la fin de chaque message. Il ne fait pas "rincer" la prise. Tous les messages seront toujours dans le même flux de données. Il ressemble à 3 messages individuels car lorsque vous les imprimez, \ n ajoute une nouvelle ligne à la fin.
Duplicaté exact: Stackoverflow.com/ Questions / 1097974 / ...
Pas un duplicata: Le titre est littéralement un duplicata, mais la question est en fait fonctionnellement différente. L'OP a besoin d'une réponse comme @ebo ci-dessous.
Oups, cela semble être correct. Va essayer d'être un peu plus lent la prochaine fois ;-)