[Vienna-pm] vermeiden von deadlocks bei tcp-communikation/ übertragen von beliebigen strings
Wolfgang Laun
Wolfgang.Laun at alcatel.at
Wed May 17 04:16:47 PDT 2006
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.
>
>
>
>
>
>
>
>
More information about the Vienna-pm
mailing list