Doch ist es. Ich habe ja auch vom Grundaufbau gesprochen, und der ist das IP Protokoll.webspider hat geschrieben:Nein, ist es nicht. Aber das hätte dir nach Lektüre von Wikipedia-Artikeln oder ähnlichem schon klar sein müssen.Gremlin hat geschrieben:Und letztlich ist TCP und UDP doch alles dasselbe, vom Grundaufbau her, oder nicht?
Siehe Zitat #2. Ich möchte wissen *warum* meine Korrektur- und Absicherungsmechanismen nicht funktionieren!webspider hat geschrieben:Anscheinend sind deine Korrektur- und Absicherungsmechanismen nicht so ausgeklügelt wie die von TCP. Weswegen es dir ja auch immer und immer wieder empfohlen wird.Gremlin hat geschrieben:Also warum sollte ich nicht das was TCP schafft auch mit UDP schaffen?Erläutere doch mal was an Refactoring verkehrt sein soll wenn es den Code erheblich verbessert.Gremlin hat geschrieben:Zumal ich nicht umsonst ~2 Monate Konzeption in den Wind schieße weil ich das System nun auf TCP umbaue.
Bis jetzt habe ich nur eines gelernt. Und zwar dass mich keiner versteht oder verstehen möchte.BlackJack hat geschrieben:@Gremlin: Also bei einer „jetzt habe ich schon so viel unnütze Zeit verschwendet, da will ich dann noch mehr verschwenden”-Einstellung kann man Dir echt nicht mehr helfen. Was Du daraus gelernt haben solltest, ist dass man für so etwas TCP verwendet und das nicht selber, aber in schlechter — da nicht funktionierend – nachbaut.
Dann schauen wir mal...BlackJack hat geschrieben:TCP ist mit UDP nachbaubar, aber was ist der Sinn davon? Das TCP den Strom garantiert liegt daran, dass es über Sequenznummern und Zeitüberschreitungen erkennen kann wenn Pakete verloren gegangen sind, welche das sind, über Steuerpakete signalisiert das bestimmte Datenpakete noch einmal neu gesendet werden müssen, und Schlangen für die Auslieferung an die Anwendung verwaltet, wo Datenpakete zwischengelagert werden wenn in der Sequenz welche Fehlen. Das müsstest Du alles nachbauen.
- Sequenznummern um zu erkennen das was fehlt habe ich bereits, Zeitüberschreitungen vermutlich auch, siehe nächster Punkt...
- Welche Pakete verloren gingen registriere ich auch, denn der Client verarbeitet Pakete, im Unterschied zum Server, sequentiell und bricht die Verbindung ab wenn er keine Antwort erhält, der Server verhält sich genauso. Beide brechen die Verbindung erst nach 11 (momentan) erfolglosen Versuchen ab.
- Steuerpakete brauche ich nicht, da keine der Informationen die ich übertrage auf mehrere Pakete verteilt wird.
- Pakete die zu früh ankommen werden ebenfalls zwischengespeichert und erst verarbeitet wenn die Lücke geschlossen wurde.
Genau das habe ich nach bestem Gewissen getan. Siehe oben.BlackJack hat geschrieben:Sollte es nur ums Lernen gehen, dann schau Dir halt wie das bei TCP gelöst ist, und implementiere dass dann nach.
*ICH* bin nicht beratungsresistent. Ich weiß nur ganz genau was ich möchte. Und das was ich möchte, und auch in meiner Frage recht genau erwähnt habe, waren Erfahrungswerte. Keine Hinweise auf andere Umsetzungen. Der Post von BlackJack geht schon eher in die richtige Richtung. Ich weiß was TCP für Techniken hat um solche Probleme, wie ich sie nun habe, zu korrigieren. Auch habe ich (noch) nicht alle diese Techniken in meine (ach so sinnlose) Umsetzung implementiert, aber genau das ist es. Ich verstehe/weiß nicht genau welche dieser Techniken von TCP nun für mich relevant sein könnte oder was mir fehlt.deets hat geschrieben:Du hast das falsche Tool gewaehlt - nun steh dazu, und korrigier deine Entscheidung. Das gehoert zum programmieren nunmal dazu. Wenn du alles selbst programmieren willst (warum benutzt du dann Python und nicht assembler, btw?) - dann mache es um Himmels willen, aber dann hol dir Literatur zu dem Thema und implementier TCP halt nach. Nur frag hier nicht nach Hilfe, denn Beratungsresistente zu unterstuetzen hat hier niemand Zeit & Lust zu.
Ich dachte, vielleicht gibt es hier jemanden der meiner Beschreibung des Problems eine dieser Techniken zuordnen und mir einen Hinweis darauf geben kann. Wenn das zu viel verlangt ist, dann tut es mir aufrichtig Leid.
Für diejenigen die vllt doch noch "Zeit & Lust" haben mir zu helfen:
der server (Mit jeder Menge Kommentare, PEP8 konform, strukturiert, aufgeräumt und sogar lauffähig!)
der client (Auch mit Kommentaren, PEP8, Struktur... allerdings nicht lauffähig, zumindest nicht so ohne weiteres.)