[Vienna-pm] vermeiden von deadlocks bei tcp-communikation/ übertragen von beliebigen strings

[Wolfgang Laun]

Ich kenne drei grundsätzlich verschiedene Methoden:

1. Länge am Anfang. Das impliziert, dass die Daten beim Sender so 
vorliegen, dass diese Länge bestimmbar ist. Der Empfänger hat freie 
Hand: Er kann alles empfangen und danach verarbeiten oder (wenn es 
möglich ist) auch in beliebigen Blöcken.

2. Die Struktur der Daten ist ohnehin so, dass der Empfänger das Ende 
gesichert erkennen kann. (Ein well-formed XML-Dokument wäre so etwas.) 
Der Empfänger liest, was er so bekommt; die Verarbeitung muss in der 
Lage sein, portionsweise gefüttert zu werden (und den nicht 
verarbeiteten Teil der letzten Portion zurückzumelden, wenn der Sender 
mehrere Daten-Transfers hintereinander machen darf.

3. Länge vorab unbekannt; beliebiger Dateninhalt. Sender und Empfänger 
verabreden (zB) dass das Ende mit einem Null-Byte gemeldet wird; jedes 
Null-Byte in den Daten wird als ESC NUL gesendet und jedes ESC als ESC 
ESC. Klarerweise kann das das Volumen um bis zu 100% erhöhen, 
idealerweise sollte man wenigstens eine Ahnung haben, wie der Inhalt 
aussieht.

Die Befürchtung, dass die Länge am Anfang zu Problemen führen könnte, 
kann ich nicht teilen. E/A auf Sockets verwendet Byte-Counts. Für die 
Verarbeitung muss Einigkeit über Codierung und/oder Darstellung binärer 
Daten gegeben sein, sonst ist sowieso alles sinnlos.

mfg
WL



peter pilsl wrote:

>Ich hab ein sehr einfaches szenario:
>
>ein client sendet einen string an den server und der server schickt dann 
>einen antwortstring zurück und der client terminiert.
>
>
>Das Problem ist, dass der string selbst ein serialized (module Storable) 
>hash (mit vielen unter- unter- hashes ist) und daher eigentlich jedes 
>zeichen enthalten kann.
>
>Wie weiss nun der Server, wenn der Client mit dem Senden seines Strings 
>fertig ist?
>
>Ich hab jetzt ein paar Lösungen selbstgestrickt, die auch funktionieren, 
>die mich aber alle nicht wircklich überzeugen:
>
>* der client sendet zuerst die länge des strings, damit der server weiss 
>wieviele bytes er lesen muss
>* der client sendet einen ganz komplexen string-ende-string ala 
>\0\n\0\0\0\0\n und der programmierer betet, dass dieser string nie im 
>übertragenen string vorkommt und setzt $/ entsprechend:)
>
>ich habe einfach das gefühl, dass es in der praxis fälle geben wird, die 
>diese lösungen aushebeln werden. (stringlänge und utf8 schreit schon 
>wieder nach ärger, wenn client und server auf unterschiedlichen systemen 
>laufen usw.)
>
>
>Wie macht man das vernünftig/einfach/verlässlich?
>
>Soll man den string encoden?
>Kann man ein meta-EOF schicken?
>Wie machen das die anderen?
>
>wie ist das mit dem datei-EOF eigentlich? Da funktioniert das alles ganz 
>einfach. Man setzt $/ auf undef und schlürft alles in einem rein? Das 
>fkt. bei meinem Server/Client-Modell nicht.
>
>Bisher hatte ich nur mit Server/Client-modellen zu tun, wo ein 0x10 ein 
>echter zeilenumbruch war und das ende einer eingabe markiert hat.
>
>danke
>lgp
>
>
>
>
>
>
>
>
>
>
>
>
>Ich versuch mal, mein Problem zu schildern und hoffe, die Frage ist
>nicht zu komplex hier:
>
>Ein Client muss mit einem Daemon Daten austauschen.  Defacto müssen zwei
>  Datenstrukturen/Objekte ausgetauscht werden.
>
>step1: der client schickt einen hash an den daemon
>step2: der daemon schickt den antworthash zurück
>step3: der client terminiert.
>
>die hashes sind dabei zT komplexe strukturen, die wieder hashes
>enthalten usw. usf.
>
>Die Daten müssen also serialisiert werden. Dazu bietet sich das Module
>Storable an, aber ich hab da grad einen Knopf im Kopf und laufe von
>einem Deadlock in den nächsten.
>
>Die Serialisierung wandelt eine beliebige referenz in einen string um.
>Diesen String schicke ich nun hin und her.
>
>Aber ich krieg kein einfaches EOF zurande. Der Server weiss nicht, wann
>er alle Daten vom Client hat.
>
>
>
>
>
>
>  
>