[P2P] Was nimmt man da besser: TCP oder UDP?

[LH_Freak]

So eine Frage: Was nimmt man für nen P2P Chat am besten:
TCP oder UDP?
Ich hab gehört TCP wäre langsamer als UDP, da es das verschickte ja noch irgendwie überprüft.
UDP dagegen ist zwar schneller, es besteht aber die Gefahr, dass er des fehlerhaft schickt.

[JasonDX]

Es is zwar "lange" (3 Monate :mrgreen: ) her, dass ich das gelernt habe, aber es ist gut möglich, dass ich mich an so manche Dinge etwas falsch erinnere:
TCP ist verbindungsorientiert, d.h. es beginnt schon mal mit dem netten Three-Way-Handshake, und geht weiter, bis zur Garantie der vollständigen Übertragung der Pakete (oder zumindest einer Benachrichtigung, falls es einen Timeout gab).
UDP ist hingegen verbindungslos, d.h. Pakete werden einfach auf die Reise geschickt, ohne Garantie, ob und wie sie ankommen.
Nun, dass TCP langsamer ist kann ich mir vorstellen. Schließlich muss eine Empfangsbestätigung gesendet werden, und auf der sendenden Seite darauf gewartet werden.
Was man für einen P2P-Chat nimmt? Nun, ich gehe mal davon aus, dass du dir zu 100% sicher sein willst, dass deine Pakete auf der anderen Seite auch ankommen. Entweder kannst du UDP nehmen und selbst die Verantwortung über den Verlust von Paketen übernehmen, oder du nimmst TCP und kümmerst dich nicht darum.
Wobei: bei einem Chat ist der Geschwindigkeitsfaktor nicht der allerwichtigste Faktor, zumindest denke ich nicht, dass man einen bemerkbaren Geschwindigkeitsgewinn bemerkt, wenn man UDP nimmt.
Also würde ich für einen P2P-Chat TCP nehmen, da der "große" Nachteil von TCP in einem Chat nicht eine sonderlich große Rolle spielt.


Da ich aber kein großer Netzwerkspezialist bin, sondern ein einfacher Schüler, der von nem schlechten Lehrer unterrichtet wurde, würde ich vor der Entscheidung noch die Meinung des einen oder anderen Facharztes abwarten ;)

[gsh]

Chimaira hat des nicht schlecht erklärt aber falls du noch fragen hast dann frag die wikipedia
http://de.wikipedia.org/wiki/Internetprotokollfamilie
http://de.wikipedia.org/wiki/Peer-to-Peer

[Phoenix]

Zitat:

Zitat von Chimaira

Wobei: bei einem Chat ist der Geschwindigkeitsfaktor nicht der allerwichtigste Faktor, zumindest denke ich nicht, dass man einen bemerkbaren Geschwindigkeitsgewinn bemerkt, wenn man UDP nimmt.
Also würde ich für einen P2P-Chat TCP nehmen, da der "große" Nachteil von TCP in einem Chat nicht eine sonderlich große Rolle spielt.

Der Begrenzende Faktor bei einem Chat ist der Mensch der tippt. Und schneller als jedes getippe (selbst von einer verdammt guten Sekretärin) ist TCP allemal ;-)

Für P2P-Filetransfers wird übrigens in der Regel UDP verwendet, um den overhead möglichst klein zu halten.

[LH_Freak]

eben deswegen: weil wir ja planen noch VoIP mit rein zu machen:
Was wäre da wohl besser?

[gsh]

UDP ganz eindeutig weil mit TCP mit dem ganzen handshake ist des VIEL zu langsam

[LH_Freak]

kennt da irgendjemand ein gutes Tut?

P.S.: Hier steht ICQ basiert auf TCP

[supermuckl]

Zitat:

UDP ganz eindeutig weil mit TCP mit dem ganzen handshake ist des VIEL zu langsam

also entweder hast du keine ahnung von größenverhältnissen, oder du weist wirklich nicht, das es auf die paar ms auch nicht ankommt :roll:

also TCP nehmen und gut is!

//edit
und voip übertragungen bitte mit UDP realisieren. da kommt es auf die zeit an! nicht aber auf die paket fehlerkorrektur

[LH_Freak]

also, heißt das ich soll den normalen Chat mit TCP und Datenübertragung und VoIP mit UDP machen?
Ist das net besser gleich alles mit UDP zu machen?

[supermuckl]

jo text übertragen mit TCP (und auch alle kontrollkommandos usw)
und die reine audioübertragung mit UDP

[gsh]

Ein Tut zwar nicht aber da ich mich in leztzer Zeit selber damit beschäftigt hab hab ich schon etwas gesammelt

@supermuckl: Es ist ja um VoIP gangen deshalb hab ich ja UDP vorgeschlagen weil bis TCP mit einem Packet fertig man schon 5000 andere gesendet

NAchtrag: @LH_Freak: Natürlich kannst du alles mit UDP machen aber es ist nicht empfehlenswert da bei UDP was man sendet auf der anderen seite nicht unbedingt ankommen muss, was bei VoIP eher egal ist aber wenn man daten hin und her schaufelt ...

[LH_Freak]

noch eine Frage:
Gibt es irgendwie Quelltexte von irgendwelchen Chatprotokollen wie OSCAR

[ripper8472]

P2P laeuft zu gleichen teilen ueber TCP und UDP.
die eigentlichen transfers gehen ueber tcp. verwaltungsdaten (quellenaustausch, suchen) geht gerne ueber UDP, obwohl das auch ueber TCP gehen kann.

mach dir klar, dass udp durch einen router von aussen gerne nicht durchgeht. da viele privatpersonen router haben, muessen sich die p2p netze darauf einstellen und benutzen tcp.

und im ernst, tcp hat kaum mehr overhead als udp.

@gsh: deine "5000 pakete" sind schwachsinn. lies die protokolle und mach benchmarks.

[supermuckl]

ja gibt es.
ICQ.PHP z.b. ist opensource und implementiert das ICQ protocol (OSCAR)

http://www.jallin.com/

ansonsten gibts noch die Tlibicq oder wie die heist, für windows als delphicode

für kylix aber nicht lauffähig, da nicht kompatibel (system aufrufe)

[LH_Freak]

okay, danke. Ich werd's mir mal anschauen.

[JasonDX]

So, weil ich mir in einigen Dingen nicht sicher war, hab ich jetzt tatsächlich nochmal meine Informatik-Unterlagen rausgesucht :D
Also: UDP ist wie schon gesagt Verbindungslos, und eigentlich nur darauf ausgelegt, kleine Datenmengen schnell zu übertragen. Gedacht für Anwendungszwecke, wo ein TCP-3WayHandshake 10mal so lang dauert wie die Schlussendliche Übertragung der 10Bytes, die ich machen muss ;)
Wenns dann zu größereren Daten geht, zu Konsequenten Datenübertragungen, wo Pakete nicht einfach mal so fehlen oder vertauscht sein dürfen, kommt TCP ins Spiel. Mit dem Three-Way-Handshake wird eine Session zwischen 2 Sockets eröffnet. Danach geht das Senden der Daten fast so schnell wie bei UDP. Bloß der TCP-Header ist etwas größer als der UDP-Header, wenn man aber ins 7Schichtenmodell guckt, kommt da dann noch so viel Zeug dazu, dass man am Ende 15% Nutzdaten in einem Paket hat und UDP nur mehr geringfügig schneller als TCP ist.
UDP ist IMO die falsche Wahl. Auch für VoIP. Grund: Es werden konsequent Daten geschickt, und konsequent Daten benötigt. UDP kann das nicht garantieren. Zumindest nicht ohne Nachhelfen.

[ripper8472]

vergiss das 7schichtmodell.
overhead berechnet sich aus IP header + TCP/UDP header.
und wenn du vergleichen willst, zaehlt ohnehin nur der laengenunterschied TCP/UDP header.

ein tcp handshake braucht 2*ping mehr zeit als einfach daten senden.
http://de.wikipedia.org/wiki/Transmi...fbau_und_Abbau

[JasonDX]

Zitat:

Zitat von ripper8472

vergiss das 7schichtmodell.

Ungern, ungern. Ich hab so lange davor gesessen, bis ichs endlich gekonnt hab :stupid: :zwinker:

Zitat:

Zitat von ripper8472

overhead berechnet sich aus IP header + TCP/UDP header.
und wenn du vergleichen willst, zaehlt ohnehin nur der laengenunterschied TCP/UDP header.

Na ja, nicht ganz. Je mehr zu den Headern dazukommt (siehe Schicht 1-3), desto weniger macht der Unterschied zwischen den 2 Headern aus

Zitat:

Zitat von ripper8472

ein tcp handshake braucht 2*ping mehr zeit als einfach daten senden.
http://de.wikipedia.org/wiki/Transmi...fbau_und_Abbau

Korrekt. Aber der Handshake geschieht nur einmal, was die Dauer des Handshakes relativ irrelevant macht. Es sei denn logisch, es wird für jedes Paket, das gesendet wird, die Session neu eröffnet und anschließend wieder geschlossen, was aber den Sinn von TCP mit Füßen treten würde.

[ripper8472]

tcp ist einfach die bessere loesung fuer datenstromuebertragungen.
nur mach das mal einem zocker klar, der auf sein gigabit netz auf lanparties besteht und denkt, udp ist so schnell, weils irgendwer mal gesagt hat. genau die kategorie von mensch will naemlich typischerweise ein eigenes "chat programm" oder ein "onlinegame" schreiben, ohne plan von irgendwas zu haben *rant*

nicht zu vergessen, mit delphi-methoden ist networking eine qual.
ich schwoere auf socket() und konsorten. die haben klare verhaltensmuster und funktionieren nicht nur auf windows.

[Luckie]

Was sind denn Delphi-Methoden? Letzendlich wird jede Komponente auf den Winsockets von Windows basieren. Und ob du nun eine Komponte benutzt oder dir die Arbeit machst und ohne Komponenten mit der Windows API arbeitest, diese Entscheidung steht noch gar nicht an.

Und was meinst du mit

Zitat:

ich schwoere auf socket() und konsorten. die haben klare verhaltensmuster und funktionieren nicht nur auf windows.

Unter Windows wirst du da auch nur wieder auf die Windows API zurückgreifen und unter Linux auf die Linux API und ob es eine so gute Idee ist eine universelle Bibliothek zu nehmen ist die Frage, denn die kann ja nur eine Schnittmenge von beiden Systemen darstellen.

[ripper8472]

wenn ich ne simple tcp verbindung will, dann quael ich mich nicht mit tclientsocket ("delphi-methoden") oder INDY.
wenn ich mehr will, dann guck ich mir die doku der plattform an.

klar ist socket() eine schnittmenge, aber eine vernuenftige.

klar baut socket() auf apifunktionen auf.
das halte ich aber fuer eine sinnvolle kapselung.
tclientsocket oder indy fuer simple tcp verbindungen halte ich im grunde fuer sinnlose kapselung (kann natuerlich seine berechtigung haben).

wenn ich dich richtig verstanden habe, dann sollte ich das darauf antworten:
an schnittmengen ist nichts boeses.
irgendwo muessen sich unterschiedliche konzepte ja treffen, wenn beide miteinander auskommen sollen.

[LH_Freak]

Jetzt habt ihr mich voll rausgebracht. Was soll ich jetzt nehmen?

[JasonDX]

Zitat:

Zitat von LH_Freak

Jetzt habt ihr mich voll rausgebracht. Was soll ich jetzt nehmen?

Für kontinuierliche Datenübertragungen wie bei VoIP ist IMO TCP die bessere Wahl.
Ansonsten, wenn einmalig nur kurz Daten gesendet werden müssen, kann man auch UDP nehmen, weil man sich den Teil mit der Session spart.

[imp]

Hallo,

vielleicht helfen dir ein paar Grundregeln an die ich mich immer halte
1) Ist Multicast oder ähnliches im Spiel -> UDP
2) Sollen Daten schnell hintereinander gesendet werden bei denen es nicht darauf an kommt wenn ab und an ein Paket fehlt oder die Reihenfolge vertauscht ist (z.B. VOIP, Videostream) -> UDP
3) Alles andere -> TCP

Falls du nur unter Windows programmieren willst kannst du mal einen Blick auf DirectPlay werfen (falls es das noch gibt). Fand ich ganz angenehm zu verwenden und nimmt einem jede Menge arbeit ab wenn es um das Sessionmanagement geht.

Schönen Gruß,
Frank

[mschaefer]

Moin,

• VoIP -> UDP
  Broadcast -> UDP
  
  Chat -> UDP oder TCP/IP
  Filesharing -> TCP/IP

Wenn bei Radio-Broadcast oder bei VoIP mal ein Byte verlorengeht, dann rauscht es vielleicht etwas oder die Tonlage ist leicht verschoben, aber die Info kommt meist durch. Beim normalen Chat ist es auch nicht tragisch wenn mal ein Buchstabe falsch übertragen wird, der Sinn kommt durch. Allerdings ist TCP/IP hier auch kein Problem, da es ehedem Zeitunkritisch ist. Bei Filesharing / Download kommt es auf Bytegenauigkeit an, sonst laufen die Programme nicht, also gehr nur TCP/IP.

VoIP mit TCPIP zu machen ist ab DSL zwar möglich bringt aber kaum Sinn, da Sprache schon nicht Bytegenau vom Micro eingelesen wird. Das ist damit mehr Spielerei und belastet das Netz unötig. Denke das ist damit geklärt. Die praktische Umsetzung wird erst interessant.

Grüße // Martin

[Tubos]

Zitat:

UDP oder TCP/IP

Kleine Korrektur am Rande: IP brauchst du immer (zumindest im Internet), eine Schicht höher kannst du dich zwischen TCP und UDP entscheiden. Möglich dass es noch andere gibt.