[P2P] Was nimmt man da besser: TCP oder 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.