Logik hinter Winsockets



  • @CUser1
    Vielleicht hilft ein konkretes Beispiel.
    Wenn ich dir folgende Nachrichten gebe...

    Nachricht 1:
    Die Bytes an Positionen 3 bis 5 sind: 7, 2, 4

    Nachricht 2:
    Die Bytes an Positionen 1 bis 2 sind: 5, 1

    Nachricht 3:
    Die Bytes an Positionen 6 bis 9 sind: 2, 6, 3, 1

    Hast du jetzt genug Informationen alle 9 Bytes in der richtigen Reihenfolge zu nennen? Ja. Und genau so funktioniert das mit TCP/IP.

    In dem Beispiel weiss das OS im Empfänger PC ja dass es dem Programm noch keine Daten gegeben hat. D.h. wenn das Programm recv aufruft, dann weiss das OS dass es erstmal auf das Byte an Position 1 warten muss. Wenn es jetzt die erste Nachricht bekommt (=das erste Paket), dann sieht es dass darin die Bytes an Positionen 3 bis 5 enthalten sind. So steht es ja schliesslich in der Nachricht. D.h. das OS kann dem Programm noch nix geben, weil Position 1 ja immer noch fehlt. Es merkt sich die 3 Bytes also und gibt dem Programm erstmal noch nichts. Dann kommt das 2. Paket mit den Bytes an Position 1 bis 2. Das OS sieht jetzt dass es ohne Lücken Positionen 1 bis 5 beinander hat. Es gibt dem Programm also diese 5 Bytes, und merkt sich dass das nächste Byte auf das gewartet wird das mit Position 6 ist. Und da die ersten 5 Bytes dem Programm ja bereits gegeben wurden, löscht das OS diese natürlich aus seinem Puffer.



  • @hustbaer Ok Danke jetzt verstehe ich es, dass heißt das OS sammelt die Fragmente bis ein ganzes Packet da ist, und dann erst scheint es bei recv() auf.

    Das andere mit Reihenfolge funktioniert wohl über die ACK wie DirkB geschrieben hat? Wenn ich im Spiel eine Truhe öffne, dann sendet es zuerst: Gehe zur Truhe, warte auf ACK, öffne Truhe, warte auf ACK, Nimm Goldschatz, warte auf ACK. Oder es sendet alles auf einen Schlag damit die Reihenfolge gewährleistet ist und ein Packet als ganzes bearbeitet wird? Weil wenn Gold nehmen vor Truhe öffnen ankommt wäre es blöd?



  • @CUser1 sagte in Logik hinter Winsockets:

    @hustbaer Ok Danke jetzt verstehe ich es, dass heißt das OS sammelt die Fragmente bis ein ganzes Packet da ist, und dann erst scheint es bei recv() auf.

    Fast. Das was du als Fragmente bezeichnest nennt man normalerweise Pakete. Und das was du als Paket bezeichnest gibt es nicht.

    Das andere mit Reihenfolge funktioniert wohl über die ACK wie DirkB geschrieben hat?

    Welches andere mit Reihenfolge? ACK spielt dabei auch erstmal überhaupt keine Rolle. ACK wird erst interessant wenn man berücksichtigen muss dass auch mal Pakete verloren gehen.

    Wenn ich im Spiel eine Truhe öffne, dann sendet es zuerst: Gehe zur Truhe, warte auf ACK, öffne Truhe, warte auf ACK, Nimm Goldschatz, warte auf ACK.

    Ich bin mir nicht sicher ob ich verstehe was du meinst. Ein Programm wartet auf jeden Fall nicht auf irgend welche ACK, denn das Programm bekommt davon überhaupt nichts mit.

    Oder es sendet alles auf einen Schlag damit die Reihenfolge gewährleistet ist und ein Packet als ganzes bearbeitet wird?

    Nochmal: Das was du unter Paketen verstehst gibt es in TCP/IP nicht. Genau so wenig wie ein File etwas von Zeilen weiss. Eine Zeile in z.B. einem Textfile ist eine Interpretation des Programms das das File liest (z.B. alles vom letzten "new line" Byte bis zum nächsten ist eine Zeile).



  • @hustbaer sagte in Logik hinter Winsockets:

    Nochmal: Das was du unter Paketen verstehst gibt es in TCP/IP nicht. Genau so wenig wie ein File etwas von Zeilen weiss. Eine Zeile in z.B. einem Textfile ist eine Interpretation des Programms das das File liest (z.B. alles vom letzten "new line" Bytes bis zum nächsten ist eine Zeile).

    Die Zeilen bekommt das Programm ja schon mit (es kann ja das '\n' sehen), aber nichts davon, wie es auf der Platte (oder sonstwo) gespeichert ist.

    Bei TCP bekommt man die Daten in der richtigen Reihenfolge - oder gar nicht.
    Wie das gemacht wird ist für den Anwender erstmal magisch. Darum braucht er sich auch nicht kümmern.



  • @DirkB sagte in Logik hinter Winsockets:

    Die Zeilen bekommt das Programm ja schon mit (es kann ja das '\n' sehen), aber nichts davon, wie es auf der Platte (oder sonstwo) gespeichert ist.

    Das Programm bekommt die Bytes die im File stehen. Dass es die \n Bytes als Zeilenwechsel interpretiert ist Entscheidung des Programms. Dem OS oder dem File ist das alles egal.



  • @CUser1
    Ich denke du versuchst zu viele Dinge auf einmal zu verstehen. Du kennst Spiele aus Sicht des Spielers ("Truhe aufmachen") und schaust dir jetzt mit Wireshark Pakete an die über's Netzwerk wandern. Und versuchst jetzt alles was dazwischen passiert zu verstehen. Das ist denke ich zu viel.

    Wieso fängst du nicht mal mit einem Sockets Tutorial an? Und nicht bloss lesen. Wenn du sicher sein willst dass du es wirklich verstanden hast musst du selbst mindestens 1-2 kleine Programme schreiben die mit Sockets arbeiten.



  • @hustbaer Das was ich als Packet bezeichne ist was das Spiel macht "Packet 0x5 ID HANDLUNG" oder so => mach Truhe auf.

    Mir ist mittlerweile klar, dass seitens des TCP Layers das ganze dann vlt. in 3 Teilen verschickt wird mir ist nur wichtig zu verstehen, dass die Reihenfolge stimmt, vermutlich wird dann nummeriert, damit der Client weiß was der Server zuerst schicken wollte und vice versa. Darum haben die Packets ja vermutlich einen "FF" drinnen oder so, damit man sie später parsen kann, wenn mit recv() zwei aufeinmal einlangen.



  • TCP/IP garantiert das. Entweder es das Zeug kommt in der richtigen Reihenfolge und ohne Lücken an, oder es kommt nicht an.

    vermutlich wird dann nummeriert, damit der Client weiß was der Server zuerst schicken wollte und vice versa.

    Ja. Das passiert aber für die Programme völlig transparent. Darum kümmert sich ein Teil des Betriebssystems. (Der Teil der als "TCP/IP Stack" bezeichnet wird, was wie gesagt nichts mit der Datenstruktur namens Stack zu tun hat.)

    Darum haben die Packets ja vermutlich einen "FF" drinnen oder so, damit man sie später parsen kann, wenn mit recv() zwei aufeinmal einlangen.

    Jetzt versuchst du wieder das ganze auf Protokollebene zu verstehen ohne dich mit den Details des Protokolls auseinanderzusetzen. Das wird nicht funktionieren. Das macht keinen Sinn. Zwei sinnvolle Varianten:

    1. Akzeptiere einfach dass Daten bei TCP/IP irgendwie magisch in der richtigen Reihenfolge und ohne Lücken ankommen und hinterfrage nicht wie.
    2. Nimm dir die Zeit und befasse dich ausgiebig mit den Details wie TCP/IP auf Protokollebene funktioniert.

    Irgendwo dazwischen rumraten was bestimmte Bytes in den Netzwerkpaketen bedeuten können macht wenig Sinn. Das fürht bloss zu Verwirrung und falschen Ideen darüber wie das alles funktioniert.

    Wenn du Wireshark verwenden willst: guck dir einfach nur den rekonstruierten Datenstrom an. Nicht die einzelnen Pakete. Vergiss die. Weil dir die Grundlagen fehlen die du bräuchtest um die Bedeutung zu verstehen. Oder wie gesagt lern die Grundlagen.



  • @CUser1

    @hustbaer sagte in Logik hinter Winsockets:

    Irgendwo dazwischen rumraten was bestimmte Bytes in den Netzwerkpaketen bedeuten können macht wenig Sinn.

    Deine Daten werden in mehrere Frames verpackt. Fast jede Ebene vom TCP/IP Stack packt eigene Informationen dazu. Sender-/Empfangsadresse, Checksummen, ...
    Das da die IP-Adresse-und Port ist klar, aber im LAN kommt noch die Ethernet-Adresse dazu - im WAN sind das wieder andere Adressen.
    Da bleibt dann "verstehen wollen" oder "nur anwenden". Wieviel Zeit hast du, ohne von deinem eigentlichen Problem abzukommen?



  • @hustbaer Irgendwie verstehe ich auch nicht ganz wovon du redest ich arbeite an einem Clientless Bot und was soll ich sonst anschauen als die einzelnen Pakete und den Begriff Packet verwendet quasi jede Hacking community obwohl es den nicht gibt.

    Im Prinzip genügt es mir zu wissen, dass die Reihenfolge stimmt das mit Puffern bis alles da ist ergibt eh Sinn.

    Und ob wenn recv 200 Bytes aus dem Buffer nimmt und da 5 Packets drinn sind, muss man die parsen, wie soll es sonst sein.



  • @CUser1
    Ich hab nie geschrieben dass es den Begriff Paket nicht gibt. Ich hab geschrieben dass du ihn für etwas verwendest was auf der Ebene von TCP/IP nicht exisitert. Was du denke ich immer noch tust.

    Wenn ich einen Nachricht habe die aus sagen wir 2000 Bytes besteht. Dann kann ich diese mit einem Aufruf an send übergeben.
    TCP/IP kann diese dann als 1 Stück verschicken oder auch in 2, 3, 4... Stücken. Es kann sogar sein dass das 1. Stück der Nachricht mit anderen Daten zusammengefasst wird und so ein Stück rausgeht das den letzten Teil einer vorherigen Nachricht enthält plus den ersten Teil der neuen Nachricht.

    Auf der Gegenseite ist es dann so, dass du von recv ein Stück Daten bekommst sobald das in der korrekten Reihenfolge nächste Stück Daten da ist. (Es wird nicht gewartet bis alle Stücke einer Nachricht da sind, denn TCP/IP kümmert sich nicht um Nachrichten.)

    Und diese Stücke bezeichnet man als Pakete.

    Auf dem Weg können die dann u.U. nochmal in kleinere Stückchen zerlegt werden - diese kleineren Stücke nennt man dann Fragmente.

    Du scheinst aber den Begriff "Paket" für das zu verwenden was ich als Nachricht bezeichne - also in diesem Fall den ganzen Block mit den 2000 Bytes. Und das ist sehr verwirrend.

    Im Prinzip genügt es mir zu wissen, dass die Reihenfolge stimmt das mit Puffern bis alles da ist ergibt eh Sinn.

    Vielleicht meinst du das richtig, aber falls nicht: Es wird nicht gepuffert bis "alles da" ist. Es wird gepuffert bis zumindest das erste Stück da ist -- egal wie klein dieses Stück ist, egal wie gross die ursprüngliche Nachricht war.

    Und ob wenn recv 200 Bytes aus dem Buffer nimmt und da 5 Packets drinn sind, muss man die parsen, wie soll es sonst sein.

    Der Begriff Paket macht hier wieder keinen Sinn. Der Satz macht für mich nur Sinn wenn du das meinst was ich als Nachrichten bezeichnet habe. Und in dem Fall: es können auch 0.2 oder 5.5 Nachrichten drinnen sein.



  • @hustbaer Ok ich gehe davon aus, dass ich es verstanden habe seit der 1/2 des Themas obwohl das mit "nicht warten bis eine ganze Nachricht da ist" auch wieder neu ist. Meine ausdrucksweise ist sehr oberflächlich, weil mich das TCP technische - was auch sehr spannend ist - nur "nebenbei" interessiert momentan. Ich bezeichne die Nachrichten als Packets, und das wenn das "Packet" fragmentiert versendet wird auch als Packets. Danke vorerst, der Thread war sehr hilfreich!



  • @CUser1 sagte in Logik hinter Winsockets:

    @hustbaer Ok ich gehe davon aus, dass ich es verstanden habe seit der 1/2 des Themas

    Es macht nicht den Eindruck als ob du es verstanden hättest.

    obwohl das mit "nicht warten bis eine ganze Nachricht da ist" auch wieder neu ist.

    Nein, ist es nicht. Du passt bloss nicht auf und verwendest die falschen Begriffe - sowohl beim Schreiben als auch beim Versuch zu verstehen was wir dir schreiben. Das kann natürlich nicht funktionieren. Ich hätte mehrfach versucht dich darauf hinzuweisen, aber das ignorierst du einfach.

    Meine ausdrucksweise ist sehr oberflächlich, weil mich das TCP technische - was auch sehr spannend ist - nur "nebenbei" interessiert momentan.

    Wieso fragst du dann immer wieder und wieder nach diesen Details, wenn eh kein Wille da ist sich wirklich mit der Antwort zu befassen?

    Ich bezeichne die Nachrichten als Packets, und das wenn das "Packet" fragmentiert versendet wird auch als Packets.

    Ja. Und du meinst so kann man sinnvoll was lernen?

    Danke vorerst, der Thread war sehr hilfreich!

    Bitte. Das war übrigens der letzte Beitrag von dir auf den ich antworten werde, denn meine Zeit ist mir zu schade um zu versuchen dir noch weitere Dinge zu erklären. Ich hoffe du verstehst wieso und lernst was daraus.



  • Für mich ist es neu Herr je und ich habe momentan ganz einfach mit dem Reversen zu tun und es ist jetzt nicht wirklich relevant wie TCP funktioniert. Ich frage nach den Details, weil ich das als Chat betrachte und es sonst langweilig ist als Pausenfüller hier kommt ja sowieso nur ein sinnvoller Thread die Woche also sei froh, dass es mich gibt. Ich mache mir keinen Stress, bin froh etwas aufzuschnappen, ich kann das jetzt lesen oder in einem Jahr, weil das ein reines Hobby ist.



  • Ich fasse zusammen: "Och, eigentlich interessiert mich das gar nicht so richtig, mir ist nur langweilig. Also quassel´ du mal ruhig weiter und unterhalte mich, ist ja deine Zeit."
    Grobes Foul.



  • @DocShoe Mich interessiert das ganze schon, aber es ist meinem Problem gerade nicht zu dinglich und ich komme später darauf zurück, wenn ich mich damit auseinander setze, hier verschwindet ja nichts. Von Fairness halte ich sowieso schon lange nichts mehr. Und mit Hustbär unterhalte ich mich so gerne, weil der so lieb ausschaut, obwohl ich auch nicht verstehe, was es ihm bringt hier anderen einfach so zu helfen. Vielleicht will er seine Bücher vermarkten.



  • @CUser1
    Zweites grobes Foul, Rote Karte.



  • @DocShoe Auf welches Spiel beziehst du denn die rote Karte bitte? Ich hoffe doch nicht auf Fußball, denn dann wünsche ich dir nicht als ein Käfer wiedergeboren zu werden, wo jemand zu seiner Belustigung drauf steigt. Außerdem wenn Hustbär nicht mehr auf meine Threads antwortet brauche ich eh nicht mehr hier reinschauen, weil Hustbär die wichtigste Wissenquelle ist.


  • Mod

    Das Spiel ist, ob Leute bereit sind, dir freiwillig zu helfen. Denkst du, hustbaer wird dir nochmal antworten, nach solchen Kommentaren?



  • @SeppJ Ich weiß es nicht, das liegt nun einzig und alleine in den Bärentatzen von Hustbär, denn darauf habe ich jetzt keinen Einfluss mehr.


Anmelden zum Antworten