Brauchst du überhaupt den Zustand "verbunden" und den damit verbunden
Overhead (Verbindungsaufbau, Anzeige des Verbindungs-Status, Reaktion
auf unerwartete Trennung, warten auf ACK wenn es mal hakt)?
Je nach Anwendung ist es viel simpler, die Kommunikation per UDP zu
machen. Jede Eingabe in der App wird als ein UDP Paket an den µC
gesendet und jede Antwort von ihm wird in der App dargestellt.
Wenn mal was verloren geht - so what? Dann tippt man halt nochmal auf
den Button. In vielen Anwendungen reicht das so.
TCP ist nur nötig, wenn die Pakete in beide Richtungen in definierter
Reihenfolge und garantiert ohne Verluste übertragen werden. Bedenke,
dass Übertragungsstörungen die Kommunikation in beide Richtungen für
einige Sekunden blockieren können. Erst nach einigen automatischen
Wiederholversuchen wird die Verbindung getrennt. Dann weiß der Sender
nicht, ob sein Paket den Empfänger erreicht hat oder nicht.
Während der automatischen Wiederholversuche kann der User nicht erneut
auf den Button tippen. Aus seiner Sicht hängt die Anwendung. Und wenn
sie getrennt wurde, muss erstmal eine neue Verbindung aufgebaut werden.
Das ist lästig.
Ich habe einige Anwendungen mit TCP (genauer HTTP) gemacht, damit es in
einem Web-Browser ohne Softwareinstallation laufen kann. Aber so richtig
zufrieden war ich mit den Ergebnissen nie.
Das Verhalten von UDP erscheint mir "natürlicher", denn es verhält sich
eher wie die zahlreichen Fernsteuerungen mit denen wir jeden Tag zu tun
haben. Wenn der Fernseher nicht reagiert, drückt man nochmal. Reagiert
er wieder nicht, geht man näher heran und drückt nochmal.
TCP braucht man eigentlich nur für kontinuierliche Datenströme. Doch
selbst bei Video Streams nutzt man inzwischen UDP weil die
Anwendungsprogramme damit bessere Möglichkeiten haben, auf Fehler zu
reagieren.
