Asynchrone UDP Sockets senden falsche Prüfsumme?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

Hallo, ich mal wieder, mit erneuter Hoffnung auf Hilfe :|

Wie bei meinem Ping-Problem, habe ich auch jetzt immer noch eine variierende Anzahl Server die ich aber diesmal mit einem UDP-Socket kontaktiere.
Das funktioniert auch größtenteils. Aber leider nicht immer und das ist das Problem. Ich kann mir keinen Reim, und wirklich überhaupt keinen, darauf machen warum.
Ich starte mein Programm, lasse die Abfrage starten und erhalte meine ersten Ergebnisse. Diese Ergebnisse befinden sich immer so im Schnitt bei 60-80%, womit ich auch zufrieden wäre. Allerdings sind es dann im nächsten Moment plötzlich nur noch 5% oder weniger. Im wiederum nächsten Moment sind es dann wieder 60-80%... Dieses Spielchen wiederholt sich immer wieder. Auch nach einem Neustart des Programms.

Nachdem ich mich jetzt schon ein paar Tage mit Socket Programmierung beschäftige hab ich schon einiges ausprobiert und somit ist der Code den ich benutze, meiner Meinung nach, ähm, ja, durchdacht genug. :roll: Also hab ich mal nicht nur in meinem Code nach dem Fehler bzw. der "Einschränkung" gesucht. Mit wireshark habe ich dann folgendes entdeckt: Wenn es mal wieder nur 5% der Server waren die antworteten, kam bei den restlichen folgender Fehler: Header checksum: 0x0000 [incorrect, should be ...] ("..." wäre in dem Fall die pro Paket erwartete)

Aber, warum? Das Paket ist immer das selbe, nur der Header natürlich nicht und das Paket wird jedes Mal in einem Rutsch gesendet. Und da ich über den Header keine Kontrolle habe, weiß ich jetzt nicht wo ich noch nach Fehlern oder Erklärungen suchen soll. Um ehrlich zu sein, bin ich mir gar nicht so sicher dass das der richtige "Fehler" ist...

Hab euch mal ein kleines Beispielskript geschrieben, das unter Python 2.7 und Windows (7, 64bit) wie bei mir laufen sollte. (Bei mir läuft das über einen separaten Thread in einem wxPython Programm.)
Dazu noch zwei Screenshots wie die Ausgabe auf dem Bildschirm aussah. (Da ist auch noch eine Exception zu sehen, falls auch hier jemand einen Hinweis hat?)

Skript
Screenshots
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

Hm, weiß keiner zu helfen? Hat denn jemand einen Tipp wo ich auf mehr Leute treffe die sich in dieser Richtung auskennen, die evtl. auch Zeit haben ( :roll: ) sich mit meinem Problem zu beschäftigen?
Benutzeravatar
DaMutz
User
Beiträge: 202
Registriert: Freitag 31. Oktober 2008, 17:25

bei mir lief das Skript 20mal durch ohne jemals 0 Server zu finden:
871 Server sinds
...
703 waren erfolgreich
...
703 waren erfolgreich
...
698 waren erfolgreich
...
704 waren erfolgreich
...
705 waren erfolgreich
...
702 waren erfolgreich
...
704 waren erfolgreich
...
700 waren erfolgreich
...
705 waren erfolgreich
...
706 waren erfolgreich
...
706 waren erfolgreich
...
703 waren erfolgreich
...
704 waren erfolgreich
...
704 waren erfolgreich
...
703 waren erfolgreich
...
702 waren erfolgreich
...
704 waren erfolgreich
...
703 waren erfolgreich
...
700 waren erfolgreich
...
704 waren erfolgreich
wenn du diesen Test machst, ist dann deine Internetleitung schon stark belastet? Ich vermute deine ISP oder so begrenzt die Anfragen. Ich habe es übrigens mit Windows 7 (64bit) / Python 2.6.5 (32bit) getestet.
BlackJack

Wenn's nicht der ISP ist, käme eventuell ein überforderter Router auch in Frage.
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

DaMutz hat geschrieben:bei mir lief das Skript 20mal durch ohne jemals 0 Server zu finden:
Danke für den Test. Dass das tatsächlich an mir liegt hätt ich nun echt nicht gedacht. :lol:
DaMutz hat geschrieben:Ich vermute deine ISP oder so begrenzt die Anfragen.
Kann ich das irgendwie rausfinden? Ob und auf wieviel?
BlackJack hat geschrieben:Wenn's nicht der ISP ist, käme eventuell ein überforderter Router auch in Frage.
Gut, er hat schon ~4,5 Jahre auf dem Buckel, aber das sind doch nur ein paar KB die da rausgehen. Klar, rein kommt mehr als nur ein "paar" KB aber wenns das mit der Prüfsumme ist, dann kommt ja nix zurück.
Benutzeravatar
DaMutz
User
Beiträge: 202
Registriert: Freitag 31. Oktober 2008, 17:25

wahrscheinlich liegt es am Router und zwar nicht wegen den KB sondern an der Anzahl Verbindungen die gleichzeitig offen gehalten werden müssen. Denn für jede Anfrage muss der Router den "Rückweg" ermöglichen.
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

Aber gleichzeitig sind doch nur 50 Verbindungen offen. Was mich halt davon abhält zu glauben dass es so ein "Limit" bei meiner Hardware (oder ähnlichem) ist, ist der Verlauf. Zuerst bekomme ich 3x-4x genug Ergebnisse und im nächsten Moment gar keine bzw. viel weniger. Danach steigt es wieder an. Verhält sich im Prinzip wellenartig, immer auf und ab... Und ein Limit wäre doch wohl konstant, oder nicht?
BlackJack

@Gremlin: Nicht unbedingt. Wenn sich der Router die "Rückwege" merkt, kann es durchaus sein, dass der Tabelleneintrag nicht sofort wiederverwendet werden kann, sondern dass es einen Timeout gibt, oder einen regelmässigen "garbage collector", der die Tabelle von alten, blockierenden Einträgen befreit.

Oder vielleicht werden die eingehenden Pakete in einem Ringpuffer gespeichert und wenn es zu viele sind läuft der über und es gibt Datensalat.

Wenn Du kannst, versuch's doch mal ohne den Router oder mit einem anderen Modell.
Gremlin
User
Beiträge: 166
Registriert: Freitag 28. Mai 2010, 23:49

Lag tatsächlich am Router. Wär ich im Leben nich drauf gekommen... Danke für den Tipp :)
Dann setz ich mich mal dran, das irgendwie zu kompensieren... wenn möglich.
Antworten