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.