Logik hinter Winsockets

[hustbaer]

@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.

[hustbaer]

@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.

[CUser1]

@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.

[hustbaer]

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.

[DirkB]

@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?

[CUser1]

@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.

[hustbaer]

@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.

[CUser1]

@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!

[hustbaer]

@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.

[CUser1]

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.

[DocShoe]

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.

[CUser1]

@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.

[DocShoe]

@CUser1
Zweites grobes Foul, Rote Karte.

[CUser1]

@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.

[SeppJ]

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

[CUser1]

@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.

[hustbaer]

@SeppJ
Nein, werd ich nicht, weil ich die Beiträge gar nicht mehr sehe - Ignore-Liste und so

[CUser1]

Ich könnte mir auch einen Fakeaccount machen um dann doch irgendwie an das unerschöpfliche Wissen von Hustbär heranzukommen, aber leider sehe ich die Beiträge nicht mehr wegen Ignoreliste usw. Kann mir jemand erklären, wie die Ignoreliste im Detail funktioniert? Z. b. Hustbär