tcp protokoll? oder doch nicht?!

[TroaX]

Also ich habe für unsere Bestellsynchro zwischen root und Lokalserver TCP im Einsatz wegen den besagten Unterschieden. Ich denke für den Zweck ist es am sinnvollsten, es per TCP zu erledigen.

[auser]

also packt man die daten die man zu schicken hat auch direkt nach den header sodass das erste paket aus header+daten besteht, das 2. paket aus daten usw...? Oder ist es vorteilhafter erst ein paket zu schicken das nur aus diesem header besteht und danach dann anfängt die datenpakete zu schicken?

Ob du nur einen Header schickst und auf ein OK vom Client wartest und erst dann die Daten oder gleich Header+Daten das entscheidest du. Darf dein Client busy sein? Machst du ein Office-Program wo das Festhalten beim Verschieben eines Fensters deinen Mainthread blockiert? Darf ein User auch vor'm bestätigen eines Requesters den PC verlassen? Oder ist's eher ein Shooter wo du in wichtige und weniger wichtige Daten trennst und die wichtigen einfach so oft an den Client gefeuert werden bis der bestätigt daß er's verstanden hat? Hast du einen eigenen Thread für's Netzwerk vorgesehen oder nicht? Nach diesen Kriterien solltest du entscheiden ob du auf ein OK warten solltest ob das OK davor oder danach kommen sollte oder ob es überhaupt erforderlich ist. Sprich - du baust dir dein eigenes Protokoll.

Und wenn man nur ein paket zu schicken hat, müsste es ja eine garantie geben das dieses paket auch vollständig ankommt oder? da es ja mittels tcp protokoll verschickt wird? seidenn natürlich der empfangspuffer ist voll vom empfänger aber das is ja was anderes

SendNetworkData sagt dir mit TCP wieviel von dem was du schicken wolltest bestätigt rausgegangen ist. Bei UDP sagt es dir lediglich wieviele Bytes von dir rausgefeuert wurden (vielleicht erfolgreich irgendwo angekommen, vielleicht auch nicht). Du musst aber (bei größeren Datenmengen) in beiden Fällen mitzählen wieviel schon rausgegangen ist und so lange vom verbliebenen Rest nachreichen bis das alles raus ist (üblicherweise in einer Schleife). Also willst du ein größeres File verschicken musst du SendNetworkData viele male ausführen.

Baust du bei TCP eine Verbindung auf dann wär das bildlich gesprochen so wie wenn du einen Boten zum Händeschütteln los schickst und dann über die selbe Route geordnet die LKWs folgen die manchmal sogar (ohne dein Wissen) zusammenwarten müssen und gestaffelt werden (Nagle-Algorithmus). Dein Empfänger weiß aber schon daß es dich gibt noch ehe du deine Daten auf Reise schickst.

Bei UDP gibt's diesen Verbindungsaufbau nicht. Man kann aber sowohl in PB (da ist es Standard) als auch über normale Socket-Programmierung dennoch eine "Pseudo-Verbindung" machen. Das ist dann aber keine geprüfte Route sondern eher wie wenn man auf deinem PC ein Katapult fix in eine Richtung dreht. Dein Empfänger weiß zu dem Zeitpunkt noch nichts von deiner Existenz... weil es ja keinen echten Verbindungsaufbau gab. Erst wenn zum ersten mal Daten fließen kriegt er davon was mit. Davon abgesehen wird bei UDP über normale Socket-Programmierung (abseits der PB-Funktionen) oft nicht mal dieses "Pseudo-Connect" gemacht (das heißt man legt nicht mal eine fixe Zieladresse fest) sondern es wird wirklich bei jedem Packet die Ziel-Adresse auf's neue als Argument der Funktion zum Senden mitgegeben (verbindungsloses Protokoll). Und wenn die Daten fließen dann kann es sein daß Packete doppelt oder gar nicht ankommen oder daß die welche ankommen in der falschen Reihenfolge eingehen. Dafür werden die Packete aber auch prompt abgeschickt.


Mfg,
auser