App Tethering - SendCommandWithResponse

[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