Ein Client<->Server System.. Wie?

[Gremlin]

Also jetzt mal ganz langsam ... diesmal gibts auch Code, am Ende.

Und letztlich ist TCP und UDP doch alles dasselbe, vom Grundaufbau her, oder nicht?

Nein, ist es nicht. Aber das hätte dir nach Lektüre von Wikipedia-Artikeln oder ähnlichem schon klar sein müssen.

Doch ist es. Ich habe ja auch vom Grundaufbau gesprochen, und der ist das IP Protokoll.

Also warum sollte ich nicht das was TCP schafft auch mit UDP schaffen?

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.

Zumal ich nicht umsonst ~2 Monate Konzeption in den Wind schieße weil ich das System nun auf TCP umbaue.

Erläutere doch mal was an Refactoring verkehrt sein soll wenn es den Code erheblich verbessert.

Siehe Zitat #2. Ich möchte wissen *warum* meine Korrektur- und Absicherungsmechanismen nicht funktionieren!

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

Bis jetzt habe ich nur eines gelernt. Und zwar dass mich keiner versteht oder verstehen möchte.

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.

Dann schauen wir mal...

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

Also so wie ich das sehe, sieht das doch schonmal ganz gut aus, oder?

Sollte es nur ums Lernen gehen, dann schau Dir halt wie das bei TCP gelöst ist, und implementiere dass dann nach.

Genau das habe ich nach bestem Gewissen getan. Siehe oben.

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

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

[deets]

Du fragst nicht nach Erfahrungswerten. Denn die sind in der wiederholt und gleich von Beginn an gegebenen Antwort "benutze TCP" enthalten. Du willst eine Bestaetigung, dass dein falscher Ansatz doch richtig ist. Das deckt sich aber offensichtlich nicht mit den Erfahrungen von all denen, die dir hier geantwortet haben.

[deets]

Noch eine Anmerkung zum Client:

- SynchronizedQueue ist komplett ueberfluessig, denn Queue.Queue *ist* bereits thread-sicher - das ist ihr einziger Daseinszweck.
- die gigantische switch-anweisung in _process_response waere besser mittels eines mappings von Code auf Parameter an callback geloest, und sollte die Konstanten auch benennen - am besten in einem eigenen Modul, das von client & server gemeinsam benutzt wird.
- es gibt viel boilerplate wie das ganze is_valid-Gefummel und die vielen methoden auf CLClient die nur einen Code uebermitteln - da liesse sich sicherlich einiges durch den Einsatz von Dekoratoren vereinfachen

[Gremlin]

Eigentlich hatte ich diesen Thread bereits aufgegeben. Aber nachdem ich jetzt weiß *warum* ich dieses Problem habe, kann ich einfach nicht anders als es irgendjemandem unter die Nase zu reiben:

http://en.wikipedia.org/wiki/Network_ad ... #Drawbacks (Siehe Absatz #2)
bzw.
http://stackoverflow.com/questions/4106 ... connection

Genau das ist der Grund warum ich nicht auf die TCP Vorschläge eingegangen bin. Ich hätte genauso gut die Zeit damit verbringen können meinen Server und Client auf TCP umzumodeln, nur um dann wieder vor dem selben Problem zu stehen und wieder nicht zu wissen woran es liegt. Jetzt weiß ich woran es liegt und kann nach Lösungswegen suchen und habe nebenbei selber eine dieser gewissen *Erfahrungen* gemacht.

PS: SynchronizedQueue ist nicht überflüssig. Die Verwendung der reset Methode und wie ich mit dem Lock in der empty Methode sowie der task_done Methode verfahre sollte das klären. Zum Rest: Danke für den Hinweis.

[deets]

Wo steht da was davon, das dieses Problem mit TCP auftritt? Sehe ich da nicht. Aber selbst wenn es das taete - dann muss man halt keep-alives verschicken, so what.

Nur du hast *IMMER* noch nicht begriffen, warum UDP eine schlechte Idee ist - denn es gibt nunmal keine Garantie dafuer, dass UDP Pakete ankommen. Gratulation dazu, dass du jetzt einen der Gruende dafuer gefunden hast. Fehlen noch ein paar 1000 andere.

Also musst du Sequenznummern einfuehren, und SYN/ACKs und so weiter und so fort.. wie ein beliebtes Protokoll basierend auf IP dessen Name hier schon ein bis zweimal genannt wurde.

Zu SynchronizedQueue: wenn sie nicht ueberfluessig ist (die ganz exakte Semantik habe ich nicht durchschauen koennen aus Zeitgruenden), dann ist sie zumindest mit Queue.Queue doppelt gemoppelt implementiert, denn wenn du schon ein Lock holst fuer alles was du machst, dann wuerde eine simple Liste reichen.