Socket.getInputStream() -> einzelne Packete?

[Soahc]

Hallo,

ich habe eine Stromsteckerleise mit TCP/IP inteface, mit dem ich die einzelnen Steckdosen fern aus und anmachen kann. Zu diesem Zweck habe ich auch eine kleine Windows Anwendung mitbekommen mit der man das sehr einfach machen kann. Nun möchte ich mir aber eine kleine Android-Anwendung schreiben, mit der ich das auch von unterwegs machen kann.

Zu diesem Zweck habe ich mir mit Wireshark angeschaut, wie sich die Steuersoftware mit der Steckdose verbindet und was dann für Daten übertragen werden.
Den Verbindungsaufbau und das senden/empfangen der ersten steuersingnale konnte ich inzwischen mit einem java.net.Socket und OutputStream bzw. InputStream nachbauen. Langsam wird es aber ein bisschen komplizierter und mich nerft dieses Konstrukt mit der while-schleife um den input.read();. Um nämlich die einzelnen TCP-Packete von einander zu trennen, packe ich die ankommenden Bytes in ein Array und vergleiche dann die letzten Stellen mit den Varianten, die ich im Wire-Shark-Trace gesehen habe. Das ist natürlich sehr fehleranfällig und funktioniert auch nur so lange, wie ich die Struktur des ankommenden Packetes kenne.

Nun zu meiner Frage. Gibt es nicht eine einfachere bzw. elegantere Lösung um die einzelnen TCP-Packete von ein ander zu trennen und dann auszuwerden?

liebe Grüße, Soahc

 

[XHelp]

Wo genau ist denn jetzt dein Problem? Du solltest ja anhand der Wireshark Daten das Protokoll erkennen und es nachbauen. Dazu brauchst du ja kein Zugriff auf einzelne TCP Pakete. Zumal ich mir nicht mal vorstellen kann was du damit anfangen willst.

 

[Soahc]

Die Steuersignale, die Antworten darauf, wie auch die Loginformation und die dazugehörige Bestätigung sind laut Wireshark jeweils immer in einzelnen TCP Paketen verpackt. Der Inhalt und die Länge der Pakete können jedoch varieren. Der Inputstream hingegen ist theoretisch unendlich und ich muss mir den Datenteil der Packeten immer umständlich aus dem Stream raushacken und diesen dann gegenchecken.

int[] array = new int[]; 
while (true){
  if (!arrayBekannt(array){
    int in = input.read();
    addToArray(array,in);
  }else{
    int[] array = new int[]; 
  }
}

In arrayBekannt prüfe ich, ob das, was bisher angekommen ist einem der Pakete(Also dem Datenteil der Pakete) entspricht, die ich in Wireshark mitgelesen habe und führe im True-Fall auch gleich eine aktion durch (z.B. weitere Informationen über den Output-Stream schicken). Wäre bis zu der Stelle ein Array gelesen, dass von arrayBekannt nicht erkennt wird, aber der Server schickt keine weiteren Daten, dann hängt das Programm(bzw. der Thread) an der Stelle int in = input.read(); fest, was ja auch logisch ist, denn das InputStream-Objekt wartet darauf, dass ein neues Byte gelesen wird.

Meine Frage war nun, ob es hier noch andere Möglichkeiten gibt um herrauszubekommen, dass ein weiteres Packet gelesen wurde, als über den Weg, zu analysieren, was bisher gelesen wurde. Oder habe ich hier generell ein Verständnissproblem??

 

[musiKk]

Oder habe ich hier generell ein Verständnissproblem??

Wahrscheinlich. In TCP müssen Dich die Pakete nicht interessieren (übrigens: im Deutschen Paket, im Englischen packet), da TCP Stream-orientiert ist. Dass bestimmte semantische Informationen in verschiedenen Paketen sind, ist Zufall und/oder ein Implementierungsdetail.

Wann Du etwas lesen kannst und wann Du etwas senden musst, wird auf einer anderen Schicht festgelegt (Anwendungsschicht). Dazu müsstest Du das Protokoll genau kennen. Dort ist auch klar definiert, wie lange die einzelnen Nachrichten jeweils sind.

 

[XHelp]

Du müsstest ja mit dem Sniffer rausgefunden haben, z.B.:
1. Ich schicke 4 bytes an Logindaten raus
2. Ich bekomme 2 bytes an Statusnachricht rein
3. Ich schicke 3 bytes an Steuersignales raus
usw.

Dementsprechend musst du auch deine Anwendung bauen. Wie die jeweiligen Informationen verschickt werden ist ja egal.

 

[Soahc]

ok. vielen Dank noch mal für die Erklärung. ich hatte wirklich ein etwas falsches Verständnis von der Sache. inzwischen habe ich auch bemerkt, dass die ersten 4 Bytes der "Nachrichten" den Inhaltstyp eindeutig festlegen und ich daraus letztendlich schließen kann, wie groß das byte-Array sein muss.