[TCP/IP] TCP/IP Problemchen: Längenangabe im Paket, Callbacks

[CrazyKai]

Hallo zusammen,

 

ich habe am Wochenende versucht eine iOS Anwendung zu schreiben, die per TCP/IP auf die Bricklets zugreift. Die C/C++ API Bindings wollte ich nicht verwenden, sondern mich an einer objektorientierten eigenen Implementierung der API versuchen.

 

Erste Frage: hat jemand Erfahrung mit der C/C++ API unter iOS?

Zweite Frage: für wann ist mit der iOS API von tinkerforge zu rechnen ("Coming soon")?

 

Und hier nun meine Beobachtungen. Ich habe bei den ersten Versuchen den Fehler gemacht, bei der Längenangabe im versendeten Datenpaket den Header (Stack-ID, Funktions-ID...) nicht mitzurechnen. Das hat leider nicht nur nicht funtkioniert, sondern den brickd komplett in den Abgrund gerissen. Musste ihn danach abschießen und neu starten. Das passiert z.B. mit einem Paket wie: 02010000 an den Rotary Poti mit Stack-ID 2. Richtig wäre das Paket so: 02010400.

 

Nachdem das korrigiert war, hat es gut funktioniert. Ich konnte das Bricklet (z.B. Poti, Distance IR) auslesen und habe auch schön brav die Werte zurückbekommen. Habe mich dann an die Callbacks gemacht. Und da liegt aktuell noch mein Problem. Ich starte die Callbacks (z.B. am Poti) und bekomme nichts zurück. Ich habe dann weiter gesucht und mit Wireshark den Netzwerkverkehr beobachtet. Es sieht so, dass nach Absetzen der Funktion zum Setzen des Callback Intervalls mein TCP Client nach einigen Sekunden den Readstream beendet. Zuvor sehe ich einigermaßen reproduzierbar in Wireshark einen "TCP Dup ACK".

 

Bisher habe ich eine iOS-Library verwendet, die das TCP Protokoll verschalt (https://github.com/robbiehanson/CocoaAsyncSocket). Vielleicht liegt das Problem darin. Ich werde demnächst mal versuchen, auf das Framework zu verzichten und mit Bordmitteln (CFNetwork/Streams) die Kommunikation herzustellen.

 

Den Callback habe ich mit folgendem Paket versucht zu starten: 02030800 14000000

 

Hatte jemand schon mal ähnliche Problemchen oder eine andere Idee, was da bei mir schief gehen könnte?

 

PS: ich verwende den brickd auf MacOS, mit dem brickv funktioniert alles, auch die Callbacks.

 

Schöne Grüße,

Kai

 

 

[batti]

Hallo Kai,

 

wir haben es nie getestet, die C/C++ Bindings könnten allerdings ohne Änderungen funktionieren. Wir haben atm kein iOS Gerät hier, wenn du Zeit und Lust hast würden wir uns freuen wenn du das mal testen kann.

 

Wir haben dein Problem mal händisch nachgespielt, bei uns waren anschließend die Callbacks aktiv. Vll. wirklich ein Problem mit dem Framework?

 

Wann wir iOS Unterstützen werden kann ich dir nicht sagen. Vll. unterstützen wir es ja schon (siehe oben).

 

Grüße

 

Bastian

 

[AuronX]

@batti: Auf jeden Fall sollte der brickd aber nicht sterben gehen, wenn er kaputte Pakete erhält. Ist zum einen unschön, aber auch gewissermaßen ein Sicherheitsproblem (zwar nur DoS, aber immerhin ^^).

[CrazyKai]

So, ich habe es jetzt mit direkter Stream-Programmierung in Objektive-C versucht, leider mit dem selben Resultat, ich erhalte keine Callbacks.

 

Dafür habe ich jetzt auch die C/C++ API Bindings von Tinkerforge versuchsweise in die iOS App eingebunden. Damit geht es Bisher auf die schnelle getestet habe ich nur das Distance IR Bricklet (direktes Auslesen und Distance-Callback, geht beides). Ich habe auch auf dem iPhone getestet, nicht nur im Simulator.

[CrazyKai]

Nun funzt es über TCP/IP direkt. Allerdings nur, wenn man zuerst mit der UID per Funktion get_stack_id die Stack-ID erfragt. Versucht man, mit bekannter Stack-ID den Callback zu triggern, ohne vorher get_stack_id aufzurufen, kommt kein Callback Paket vom brickd.

 

[Loetkolben]

Allerdings nur, wenn man zuerst mit der UID per Funktion get_stack_id die Stack-ID erfragt. Versucht man, mit bekannter Stack-ID den Callback zu triggern, ohne vorher get_stack_id aufzurufen, kommt kein Callback Paket vom brickd.

 

Muss das immer vor einen Callback Paket passieren oder reicht es einmal nach anstecken des Bricks an den USB Port?

 

Der Loetkolben

[borg]

Das muss einmal pro IP Connection passieren. Das hatte ich doch glatt in der Zwischenzeit vergessen, mir ist erst nach dem Thread hier wieder eingefallen was da Sache ist .

 

Werden wir gleich morgen früh mit in die Dokumentation aufnehmen.

 

Was da passiert ist folgendes: der Brick Daemon müsste rein theoretisch zu jeder Socket Verbindung Callbacks von jedem auch nur irgendwie angeschlossenen Brick/Bricklet schicken (da er grundsätzlich erstmal nicht weiß welche Socket Verbindung sich für welches Brick/Bricklet interessiert).

 

Um das zu verhindern guckt er sich die Pakete an und schickt Callbacks nur dann raus wenn eine Socket Verbindung zu dem Brick/Bricklet schon einmal eine Stack ID abgefragt hat (das ist bei den Bindings natürlich immer der Fall).

 

Wenn man direkt TCP/IP verwendet kann das natürlich auf einmal zu einem Fallstrick werden.

 

Also: Wenn ein Brick/Bricklet verwendet werden soll, immer vorher die Stack ID zu der UID holen!