Hallo,
Nehmen wir mal als Beispiel Protokol HTTP.
Bei GET-Requests ist \r\n\r\n das Ende.
Bei POST-Anfragen gibt es im Header Content-length: x
Da muss man x Zeichen nach dem Header lesen.
ja, und wenn für x ein falscher Wert übermittelt wird, kommt sich der Kommunikationspartner mächtig verarscht vor. ;-)
POST / HTTP/1.1\r\n
Content-length: 5\r\n
... ...\r\n\r\n
f=34
Folge ist das ein Zeichen laut Headerinformation fehlt. Also warte ich auf das Zeichen. Aber es kommt hald keins.
Soll ich dann eine solche Anfrage verwerfen?
Nach "angemessener" Wartezeit, ja.
Das Problem tritt eigentlich bei allen Übertragungen auf, bei denen Zeichen sequentiell übermittelt werden, aber logische Blöcke bilden. Hast du schon einmal eine Kommunikation mit irgendeinem Gerät über die COM-Schnittstelle programmiert? Da kann dich so ein Problem genauso treffen. Beispielsweise verlangt das Protokoll, dass Anfragen immer mit einem \r enden, du bekommst aber nur ein paar druckbare Zeichen und dann lange Zeit nichts.
Du hast in so einem Fall keine andere Chance, als nach einer definierten Wartezeit die Anfrage zu verwerfen - entweder still ignorieren, oder eine Fehlermeldung ausgeben, oder dem Kommunikationspartner signalisieren, "Spiel's noch einmal, Sam".
Und das Warten soll dann durch ein Timeout abgebrochen werden?
Das wäre soweit ja ok.
Genau. Ist zwar ein bissl Programmieraufwand, muss aber sein, wenn das System einigermaßen stabil funktionieren soll.
Aber gibt es wirklich keine andere Möglichkeit ein Ende in so einem Stream zu finden? (Dateiendekennung?!)
Nein. Das ist eben etwas anderes, als wirklich eine Datei zu lesen, deren Länge das Betriebssystem genau kennt.
Ciao,
Martin
--
Most experts agree: Any feature of a program that you can't turn off if you want to, is a bug.
Except with Microsoft, where it is just the other way round.