App Tethering - SendCommandWithResponse

[weisswe]

Hallo!

Hab mir gerade App Tethering angesehen.
Für meine "kleine" Anwendung scheint es geeignet zu sein.
Jedoch finde ich nicht den richtigen Weg für mein Problem.

Habe eine "Hauptanwendung" mit einer Datenbank.
Die Clients sollen nun von dieser Anwendung Daten anfordern.
Client -> Kommando "HoleKunden" mit Parameter (Filter) "Land = DE")

Da ist mir gleich der SendCommandWithResponse ins Auge gesprungen.
Jedoch komme ich damit nicht klar (prinzipiell).
Auch finde ich kein Beispiel hierzu - nur für SendString, SendStream, ...
Vielleicht hat ja von euch jemand etwas ähnliches gemacht.
Kann ja auch sein das der SendCommand nicht das Richtige für mein Problem ist!?

Grüße,
Werner

[Mavarik]

Ich sehe das so:

App Tethering ist ein Transportlayer darauf baue ich mein eigenes Protokoll auf...

"Client": Schicke Request-Record -> RecordToStream -> Stream Senden
"Server": Verarbeite Request -> AntwortToRecord -> RecordToStream -> Stream Senden...

Ohne Werbung machen zu wollen... (s.u.) Ein Grund, warum ich für App Tethering einen SEHR aufwendigen Wrapper geschrieben haben der mir "beliebige" Datenstrukturen übertragen kann...

Aber wie beschrieben, sollte es gehen...

Mavarik

[weisswe]

Hi Mavarik!

Danke für die Antwort.
Ist vielleicht das Beste auf die Basisstrukturen zu setzen und den Rest selbst zu machen.
Hab auch gelesen das in diesem Bereich sich vieles in jeder Version von Delphi ändert.
Deinen Ansatz finde ich daher eh nicht schlecht.. :-D

Also nochmals Danke.
/Werner

[Bambini]

Zitat:

Zitat von weisswe (Beitrag 1345181)

Hab auch gelesen das in diesem Bereich sich vieles in jeder Version von Delphi ändert.

Das war in den ersten Versionen so. Da war das Protokoll von Delphi zu Delphi Version inkompatibel.
D.h. wenn du App mit einer anderen Delphi Version erstellst, als die Desktop Anwendung, geht gar nix.
Da wir es nicht kontrollieren können, welche App Version auf den mobilen Geräten installiert ist, war es ein absolutes NoGo.
Keine Ahnung ob das immer noch so ist, aber die verwendete UDP Kommunikation lässt sich ohne ohne viel Code selbst bauen.

[Mavarik]

Zitat:

Zitat von Bambini (Beitrag 1345184)

Keine Ahnung ob das immer noch so ist, aber die verwendete UDP Kommunikation lässt sich ohne ohne viel Code selbst bauen.

Naja - Selber UDP geht - hab ich in meiner App auch so gemacht, weil das AppT noch nicht gab... Aber AppT ist schon "schöner", alleine wegen dem Background Thread der alles handled usw...

Geändert hat sich

Delphi-Quellcode:

{$IF Compiler_SEATTLE_DOWN}
   TTetheringDataType = TArray<System.Byte>;
{$ELSE}
   TTetheringDataType = TByteDynArray;
{$ENDIF}

[Bambini]

Zitat:

Zitat von Mavarik (Beitrag 1345188)

... Aber AppT ist schon "schöner", alleine wegen dem Background Thread der alles handled usw...

Die "Schönheit" hat auch noch Schattenseiten:
http://stackoverflow.com/questions/3...cation-startup

[Rollo62]

Das war XE8, gibts auch Probleme mit 10.1 Berlin (ausser dem Flughafen) ?

Rollo

[jaenicke]

Wir haben App Tethering verwenden wollen, aber leider lief das ganze nicht stabil. Feste Ressourcen funktionierten und alle Demos bauen darauf auf, aber sobald dynamische / temporäre Ressourcen benötigt werden klappte das ganze nicht mehr richtig.

Manchmal wurden alle anderen Instanzen gefunden, manchmal nicht, manchmal kamen die Ressourcen an, manchmal nicht.

Dazu kamen immer wieder mal Umwandlungsfehler beim Empfang obwohl wir die konkreten Pakete ja nicht schnüren. Was da schief lief konnte ich nicht herausfinden.

Dazu kommt, dass die Größe der Pakete beschränkt ist (ca. 2080 Zeichen oder so glaube ich), wenn man Strings benutzt. Das ist allerdings nicht dokumentiert und wohl auch eher ein Programmierfehler, da der Rest der Transmission schlicht nicht verarbeitet wird. Sonst würde das wie mit Streams problemlos funktionieren.

Das Ende vom Lied war, dass wir nun eine Kombination von UDP-Server, UDP-Client im Thread und einem Datasnap-Server nutzen. Das funktionierte fast auf Anhieb problemlos, ist auch viel schlanker und wir bereuen die Zeit, die wir in die Versuche mit App Tethering gesteckt hatten...

[Sherlock]

Kurze Zwischenfrage: Warum UDP? UDP ist nach meinem (zugegebenermaßen historischen) Verständnis eine recht schlechte Wahl, wenn es um Zuverlässigkeit und Datenmengen von mehr als, sagen wir mal, zwei Paketen geht. Für Delphi Entwickler gibt es auch bei der Entwicklung keine Vorteile, ob UDP oder TCP, es muss lediglich eine andere Komponente verwendet werden. Also warum nimmt jeder UDP?

Sherlock

[Bambini]

Soweit ich erinnere, wird das UDP nur zum Finden der Clients mittels Broadcast verwendet.
Die eigentliche Verbindung läuft dann per TCP/IP.

[Benedikt Magnus]

Zitat:

Zitat von Sherlock (Beitrag 1345236)

Kurze Zwischenfrage: Warum UDP? UDP ist nach meinem (zugegebenermaßen historischen) Verständnis eine recht schlechte Wahl, wenn es um Zuverlässigkeit und Datenmengen von mehr als, sagen wir mal, zwei Paketen geht. Für Delphi Entwickler gibt es auch bei der Entwicklung keine Vorteile, ob UDP oder TCP, es muss lediglich eine andere Komponente verwendet werden. Also warum nimmt jeder UDP?

Sherlock

Wenn man eine eigene Funktion erstellt, um eventuell verloreren Pakete zu erkennen und erneut zu versenden, dann kann das Ganze durchaus merklich schneller sein als TCP.

[Sherlock]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1345241)

Wenn man eine eigene Funktion erstellt, um eventuell verloreren Pakete zu erkennen und erneut zu versenden, dann kann das Ganze durchaus merklich schneller sein als TCP.

Genau, warum dann nicht TCP? Dann kann man sich den Teil schenken, und von welcher Geschwindigkeit reden wir hier? Geht es um Onlinespiele? Videotelefonie? Oder Nutzdaten, mit einer vorhersehbaren Menge von verlorenen Paketen in einem WLAN, so daß der Geschwindigkeitsvorteil bereits im Average Case hinfällig ist?
Ich würde halt gerne wissen, ob das ein klassischer Fall von "hat man immer so gemacht" ist, oder ob tatsächlich Einzelfallentscheidungen gefällt werden, die den zusätzlichen Code zur UDP-Verwaltung rechtfertigen. Ich stand schon mehrfach vor der Implementierung einer kleinen Kommunikation per IP, und hatte jedesmal UDP zu Gunsten von TCP verworfen, weil ich eine weitere Fehlerquelle hätte einbauen müssen (die Paketverwaltung halt). Bisher kann ich über Geschwindigkeitsprobleme nichts berichten.
Das UDP hervorragend geeignet ist, um per Broadcast "Artgenossen" zu finden steht auf einem anderen Blatt, da bedarf es ja aber auch keiner Paketverwaltung. Eventuell sollte dieses hier aber in einen anderen Thread ausgelagert werden... wird wohl zu OT.

Sherlock

[Benedikt Magnus]

Zitat:

Zitat von Sherlock (Beitrag 1345243)

Genau, warum dann nicht TCP? Dann kann man sich den Teil schenken, und von welcher Geschwindigkeit reden wir hier? Geht es um Onlinespiele? Videotelefonie? Oder Nutzdaten, mit einer vorhersehbaren Menge von verlorenen Paketen in einem WLAN, so daß der Geschwindigkeitsvorteil bereits im Average Case hinfällig ist?
Ich würde halt gerne wissen, ob das ein klassischer Fall von "hat man immer so gemacht" ist, oder ob tatsächlich Einzelfallentscheidungen gefällt werden, die den zusätzlichen Code zur UDP-Verwaltung rechtfertigen. Ich stand schon mehrfach vor der Implementierung einer kleinen Kommunikation per IP, und hatte jedesmal UDP zu Gunsten von TCP verworfen, weil ich eine weitere Fehlerquelle hätte einbauen müssen (die Paketverwaltung halt). Bisher kann ich über Geschwindigkeitsprobleme nichts berichten.
Das UDP hervorragend geeignet ist, um per Broadcast "Artgenossen" zu finden steht auf einem anderen Blatt, da bedarf es ja aber auch keiner Paketverwaltung. Eventuell sollte dieses hier aber in einen anderen Thread ausgelagert werden... wird wohl zu OT.

Sherlock

Für die meisten Anwendungsfälle ist TCP wirklich geeigneter. Und bei solchen, bei denen Paketverlust unerheblich ist (Videotelefonie hast du ja schon angesprochen) oder Broadcasting ist UDP sinnvoller.
Aber bei zeitkritischen Projekten, wie z.B. den von dir angesprochenen Onlinespielen und Mehrspielerspielen (und das ist ein ziemlich großer Punkt), aber auch in Umgebungen mit geringem Paketverlust (LAN-Netzwerken) hat UDP mit einer rudimentären Paketverwaltung (die im Grunde ziemlich schnell erstellt ist) durchaus Vorteile schon aufgrund der Statusfreiheit: Man braucht einfach keine durchgängig offene Verbindung. Immer dann, wenn Kommunikation nur unregelmäßig erfolgt, kann der Einsatz von UDP nicht nur schneller, sondern auch weniger fehleranfällig sein, weil das Offenhalten bzw. Neuaufsetzen einer Verbindung ineffizienter und mitunter komplexer ist. Das ist auch der Grund, warum HTTP auf UDP (mit Cookies) setzt.

EDIT:
Bei HTTP hatte ich etwas verwechselt.

[jaenicke]

Zitat:

Zitat von Sherlock (Beitrag 1345236)

Kurze Zwischenfrage: Warum UDP?

Wie stellst du dir das vor? Alle IP Adressen im Subnetz durchscannen um die anderen Teilnehmer zu finden? Das halte ich für keine gute Idee.

Der konkrete Datentransfer passiert sowohl bei App Tethering als auch bei uns via TCP. Nur dafür muss man den Teilnehmer ja erst einmal gefunden haben.

// EDIT:
Wobei du das Teilnehmer finden ja schon selbst angesprochen hast. Dann verstehe ich die Frage nicht?

[Bambini]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1345251)

Das ist auch der Grund, warum HTTP auf UDP (mit Cookies) setzt.

RFC sagt etwas anderes

Zitat:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used.

Quelle: http://www.ietf.org/rfc/rfc2616.txt

[Mavarik]

Genau... Mit UDP Erkennen dann per TCP senden...

Auf iOS habe ich leider das Problem (ggf. wegen Indy) das UDP nicht durch kommt... Dann muss man das Device 1x neu starten und dann geht es sofort.

TCP ist ja nur der Transportlayer - meine "Protokoll" das ich darauf fahre ist eine Case die Kommandos abfragt:

Delphi-Quellcode:

Type
  TTCPCommand     = (tcpError,tcpRead,tcpnop,tcpend,tcpAllend,tcpGetFile,tcpPutFile,tcpAllSize);

sind 250,300 Zeilen - und fertig...

[Mavarik]

Zitat:

Zitat von Bambini (Beitrag 1345256)

RFC sagt etwas anderes

Zitat:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used.

Quelle: http://www.ietf.org/rfc/rfc2616.txt

UDP wird doch nur für Spiele und VoiceoverIP genutzt... Alles andere setzt auf TCP auf... Ist doch der niedrigste Datenversand auf Netzwerkebene, der sicher stellt, dass alle Daten auch ankommen. (Handshake)

[mjustin]

Zitat:

Zitat von Mavarik (Beitrag 1345260)

UDP wird doch nur für Spiele und VoiceoverIP genutzt... Alles andere setzt auf TCP auf... Ist doch der niedrigste Datenversand auf Netzwerkebene, der sicher stellt, dass alle Daten auch ankommen. (Handshake)

TCP/IP verwendet Handshakes nur beim Aufbau und Abbau von Verbindungen.

Für alle Datenpakete die dazwischen versendet werden, gibt es kein Handshake, sondern es wird das Timeout-Verfahren benutzt, bei dem der Sender Pakete erneut sendet, wenn keine Bestätigung eintrifft. Der Sender bemerkt daher nicht sofort, wenn die Gegenseite nicht mehr da ist.

https://de.wikipedia.org/wiki/Transm....C3.A4ssigkeit

[Mavarik]

Zitat:

Zitat von mjustin (Beitrag 1345272)

Für alle Datenpakete die dazwischen versendet werden, gibt es kein Handshake, sondern es wird das Timeout-Verfahren benutzt, bei dem der Sender Pakete erneut sendet, wenn keine Bestätigung eintrifft.

Stimmt... Für mich ist die Bestätigung auch ein Handshake... Das ist ja genau der unterschied zu UDP... Gesicherte Reihenfolge und Vollständigkeit der Pakete...

Aber wir können es auch einfach Bestätigung nennen... :stupid:

[Rollo62]

Zitat:

Auf iOS habe ich leider das Problem ...

Gibt es eigentlich so etwas wie Bonjour-Kompatible oder Apple-AirPlay kompatible Libraries ?
Die sollten doch mit Apple zusammen funktionieren.
Bin zwar kein Bonjour-Fan aber wenn es die inter-Platform Kommunikation verbessert ist alles Recht.

Das basiert ja sehr wahrscheinlich auch auf UDP ... aber eben mehr Apple-Like :stupid:

Rollo

[Mavarik]

Zitat:

Zitat von Rollo62 (Beitrag 1345280)

Gibt es eigentlich so etwas wie Bonjour-Kompatible oder Apple-AirPlay kompatible Libraries ?

Ich hab - noch - keine gefunden. Abgesehen davon, bin ich kein Freund davon iOS speziell zu programmieren...
Am liebsten habe ich Source der auf iOS genauso läuft wie auf Android!

Wobei in der Regel, Android das Problem macht und nicht/NIE iOS... Außer in diesem Fall!

[Rollo62]

Apple first - Mobile first - Cloud first - .... - dann mal irgendwann M$ :-D