TIdTCPServer: erkennen ob String oder Stream?

[uups]

Ich habe zwei Anwendungen auf verschiedenen Plattformen (Windows und iOS), die Daten an den selben IdTCPServer-Socket übermitteln sollen. Dabei sendet die Windows-Anwendung die verschlüsselten Daten in Form eines einfachen Strings

Delphi-Quellcode:

TCPClient.IOHandler.WriteLn(ClientDataString, IndyTextEncoding_UTF8);

während die iOS-App die verschlüsselten Daten in einer TMemoryStream-ähnlichen Stream übermittelt, was in etwa dem

Delphi-Quellcode:

TCPClient.IOHandler.Write(ClientDataStream, 0, true);

entsprechen würde. Kann ich in OnExecute von TIdTCPServer irgendwie sicherstellen, ob es sich bei den ankommenden Daten um ein String oder eine Stream handelt?

[Neutral General]

Daten sind Daten. Wenn du unterschiedliche Daten unterscheiden können willst, musst du selber dafür sorgen.
Z.B. dadurch dass jeder erst mal ein Byte vor dem eigentlichen Inhalt schickt, dass festlegt (bzw. erkennen lässt) ob der Inhalt ein Stream oder ein String ist.

[uups]

Die Client-Anwendungen können aktuell leider nicht angepasst werden, ich muss es irgendwie schaffen, den Typ der Daten serverseitig zu erkennen.

[Neutral General]

Dann musst du raten.
Aber da kommt es dann stark drauf an was genau in den Strings bzw. Streams enthalten ist.
Falls in den Streams immer JPEG-Dateien wären, könntest du nach der JPEG-Signatur schauen, falls die Strings immer mit "ABC" anfangen kannst du das testen.
Falls die Streams und die Strings deutlich unterschiedliche Größen haben, kannst du versuchen es daran festzumachen.

All das hängt aber wie gesagt sehr stark davon ab was/wie viel inhaltlich in den Strings/Streams steht.
Eine andere Möglichkeit gibt es nicht.

[mjustin]

Zitat:

Zitat von uups (Beitrag 1427085)

Ich habe zwei Anwendungen auf verschiedenen Plattformen (Windows und iOS), die Daten an den selben IdTCPServer-Socket übermitteln sollen. Dabei sendet die Windows-Anwendung die verschlüsselten Daten in Form eines einfachen Strings

Delphi-Quellcode:

TCPClient.IOHandler.WriteLn(ClientDataString, IndyTextEncoding_UTF8);

während die iOS-App die verschlüsselten Daten in einer TMemoryStream-ähnlichen Stream übermittelt, was in etwa dem

Delphi-Quellcode:

TCPClient.IOHandler.Write(ClientDataStream, 0, true);

entsprechen würde. Kann ich in OnExecute von TIdTCPServer irgendwie sicherstellen, ob es sich bei den ankommenden Daten um ein String oder eine Stream handelt?

Für den Server ist erst einmal alles, was aus dem Socket kommt, ein "Stream". Wenn der von iOS gesendete DataStream aber so wie der von Windows mit einem eindeutigen ZeilenEnde-Terminator endet, kann man auf der Serverseite mit Indy genau bis zu diesem Terminator lesen, z.B. Linefeed. Damit wäre der Windows-Terminator (CR/LF) ebenfalls abgedeckt, man müsste denn nur noch das CR abschneiden.

Der IOHandler hat dazu eine Readn-Methode mit einem frei definierbaren Terminator.

[Neutral General]

Zitat:

Zitat von mjustin (Beitrag 1427099)

Für den Server ist erst einmal alles, was aus dem Socket kommt, ein "Stream". Wenn der von iOS gesendete DataStream aber so wie der von Windows mit einem eindeutigen ZeilenEnde-Terminator endet, kann man auf der Serverseite mit Indy genau bis zu diesem Terminator lesen, z.B. Linefeed. Damit wäre der Windows-Terminator (CR/LF) ebenfalls abgedeckt, man müsste denn nur noch das CR abschneiden.

Der IOHandler hat dazu eine Readn-Methode mit einem frei definierbaren Terminator.

Und wenn in dem Stream CR/LF Bytes vorkommen?
Das halte ich für keine gute Idee.

[mjustin]

Zitat:

Zitat von Neutral General (Beitrag 1427100)

Zitat:

Zitat von mjustin (Beitrag 1427099)

Für den Server ist erst einmal alles, was aus dem Socket kommt, ein "Stream". Wenn der von iOS gesendete DataStream aber so wie der von Windows mit einem eindeutigen ZeilenEnde-Terminator endet, kann man auf der Serverseite mit Indy genau bis zu diesem Terminator lesen, z.B. Linefeed. Damit wäre der Windows-Terminator (CR/LF) ebenfalls abgedeckt, man müsste denn nur noch das CR abschneiden.

Der IOHandler hat dazu eine Readn-Methode mit einem frei definierbaren Terminator.

Und wenn in dem Stream CR/LF Bytes vorkommen?
Das halte ich für keine gute Idee.

Wenn CR/LF in den Daten vorkommen können, hat man in beiden Fällen ein Problem, das Ende zu erkennen:

TCPClient.IOHandler.WriteLn(StringDerCRLFEnthält, IndyTextEncoding_UTF8);

kann der Server nicht erkennen, nach welchem CRLF Schluss ist. Das könnte so auch jetzt schon nicht funktionieren.

Es gibt keine Möglichkeit, den "Typ" abzufragen, der im Socket ankommt. Man kommt nur mit Kenntniss des Protokolls weiter.

Wenn die Daten z.B. eine konstante Länge haben, ist es einfach.

Es wäre gut zu sehen, wie bisher die Daten von iOS serverseitig eingelesen wurden.

[Redeemer]

Zitat:

Zitat von Neutral General (Beitrag 1427100)

Zitat:

Zitat von mjustin (Beitrag 1427099)

Für den Server ist erst einmal alles, was aus dem Socket kommt, ein "Stream". Wenn der von iOS gesendete DataStream aber so wie der von Windows mit einem eindeutigen ZeilenEnde-Terminator endet, kann man auf der Serverseite mit Indy genau bis zu diesem Terminator lesen, z.B. Linefeed. Damit wäre der Windows-Terminator (CR/LF) ebenfalls abgedeckt, man müsste denn nur noch das CR abschneiden.

Der IOHandler hat dazu eine Readn-Methode mit einem frei definierbaren Terminator.

Und wenn in dem Stream CR/LF Bytes vorkommen?
Das halte ich für keine gute Idee.

Richtig. PNG-Dateien z.B. enthalten per Definition immer Absätze.

[mjustin]

Zitat:

Zitat von Redeemer (Beitrag 1427105)

Richtig. PNG-Dateien z.B. enthalten per Definition immer Absätze.

Der Server sammelt dann die Absätze ein bis der letzte eintrifft.

=> wenn das Dateiformat bekannt ist, ist das Einlesen einfach.

(Besser wäre natürlich, die Länge vorher zu senden, so wie IOHandler.Write() das optional kann. Im konkreten Fall ist das leider nicht gegeben - gesucht wird daher ein Workaround, der mit beiden Clients funktioniert)

[Neutral General]

Zitat:

Zitat von mjustin (Beitrag 1427104)

Wenn CR/LF in den Daten vorkommen können, hat man in beiden Fällen ein Problem, das Ende zu erkennen

CR/LF sind ja nichts stringspezifisches. Das sind Bytes mit den Werten 13 und 10. Die können potenziell in jeder Datei vorkommen.
Bei einer Kommunikation (über TCP) muss man Messages mit definierten Strukturen definieren an die sich beide Seiten halten müssen.
Alles andere kann quasi nur in die Hose gehen.
Falls die Client-Anwendungen wie uuups sagte tatsächlich nicht angepasst werden können (sicher? wirklich? Ist das zu 100% unmöglich? Falls nicht sollte das auf jeden Fall gemacht werden, auch wenn das vllt. etwas Arbeit ist) kann man sich nur irgendwas zurechtwurschteln und beten, dass nichts schief geht.

Zitat:

Zitat von mjustin (Beitrag 1427106)

Der Server sammelt dann die Absätze ein bis der letzte eintrifft.

=> wenn das Dateiformat bekannt ist, ist das Einlesen einfach.

Das ist genauso rumgepfusche wie alles andere auch.
Unterm Strich gibt es keine (richtige) Lösung, wenn er die Clientanwendungen nicht anpassen kann/will.