Ich programmiere hier an einer Lösung, um eine LED-RGB-Matrix 192 x 96 per UDP mit Daten zu befeuern. Dazu werden einfach "Rohdaten" mit der Bytefolge R-G-B-R-G-B... in der erforderlichen Menge an den Empfänger (Raspi) gesendet. Während das unter MacOS mit Xojo problemlos beliebig lange funktioniert (ca. 1 Bild pro Sekunde), habe ich unter Windows den Effekt, dass zunächst nach dem Start der Applikation 3..4 Bilder übertragen werden und dann die Verbindung abreisst. Lässt man das Programm weiterlaufen, erscheinen in unreglmäßigen Abständen von um die 10..20s immer mal wieder sporadisch einige Bilder auf der Anzeige. Das fertige Projekt muss aber unter Windows laufen. Bisher hatte ich noch nie ernste Probleme damit, ein RealBasic- bzw. Xojo-Projekte von Mac auf den PC zu übertragen. Shit ... Tips? Danke.
Welche "Verbindung"? UDP ist verbindungslos.
Rufus Τ. F. schrieb: > Welche "Verbindung"? UDP ist verbindungslos. Jaaaa ... krümelkack. Du hast recht, es sollte heissen: Beim Empfänger kommt nix mehr an bzw. nur noch sporadisch. Achja: Firewall ist komplett aus.
:
Bearbeitet durch User
Frank E. schrieb: > Du hast recht, es sollte heissen: Beim Empfänger kommt nix mehr an bzw. > nur noch sporadisch. Achja: Firewall ist komplett aus. dann lies doch mal mit, ob wirklich Daten gesendet werden. Windows macht zwar einiges anders aber beim UDP senden werden auch wirklich Daten gesendet.
Ist die Windows-Firewall bzw. eine vorhandene "Security-Software" (Kaspersky, Avira, etc...) deaktiviert? Was sagt Wireshark, was an Daten mit welchem Timing am RasPi ankommt? @Rufus: UDP ist schon "verbindungslos", aber "gedanklich" arbeitet man immer mit einer Verbindung auf der Applikationsebene (virtuelles Kabel). Wenn keine Daten mehr ankommen, oder verhackstückt, dann geht man gedanklich von einem "Verbinsungsabbruch" bzw. einem "virtuellen Kabelbruch" aus. Bei TCP sagt einem der Socket (theoretisch) wenn was mit der Verbindung nicht stimmt (z.B. keine ACKs mehr kommen). Bei UDP muss das halt die Applikation selber erledigen. Laut OSI gilt auf APP-Ebene aber immer das "virtuelle Kabel".
Matthias schrieb: > UDP ist schon "verbindungslos", aber "gedanklich" arbeitet man immer mit > einer Verbindung auf der Applikationsebene (virtuelles Kabel). wer macht so etwas?
Peter II schrieb: > dann lies doch mal mit, ob wirklich Daten gesendet werden. Wireshark. Frank E. schrieb: > Dazu werden einfach "Rohdaten" mit der Bytefolge R-G-B-R-G-B... in der > erforderlichen Menge an den Empfänger (Raspi) gesendet. Wird wirklich für jedes einzelne Zeichen ein eigenes UDP-Paket versendet? Oder sind die Pakete "in der erforderlichen Menge" vielleicht grenzwertig groß? 192x96x3 = 55296 ... hmm.
Rufus Τ. F. schrieb: > Peter II schrieb: >> dann lies doch mal mit, ob wirklich Daten gesendet werden. > > Wireshark. > > Frank E. schrieb: >> Dazu werden einfach "Rohdaten" mit der Bytefolge R-G-B-R-G-B... in der >> erforderlichen Menge an den Empfänger (Raspi) gesendet. > > Wird wirklich für jedes einzelne Zeichen ein eigenes UDP-Paket > versendet? > > Oder sind die Pakete "in der erforderlichen Menge" vielleicht > grenzwertig groß? > > 192x96x3 = 55296 ... hmm. Natürlich wird nicht für jedes einzelne Zeichen eine Message gesendet, sondern eine Message mit der Gesamtgröße von 55296. Diese wird vom sendenden IP-Stack fragmentiert und am anderen Ende wieder zusammengesetzt. Auf Raspi-Seite gibts ja damit auch kein Problem und beim Senden unter MacOSX ebenfalls nicht. Nur das sch... Windows nervt mal wieder rum. Allerdings kann es auch kein grundsätzliches Problem sein, denn hin und wieder funktioniert es ja, nur eben nicht verlässlich :-((
:
Bearbeitet durch User
Frank E. schrieb: > Natürlich wird nicht für jedes einzelne Zeichen eine Message gesendet, > sondern eine Message mit der Gesamtgröße von 55296. Da ist bei UDP der Erwartungswert eher "kommt nicht an". Insbesondere bei WLAN können bei der Übertragung einzelne Fragmente verloren gehen - der Empfänger kann dann das Paket nicht mehr zusammen setzen und verwirft es. Bei TCP kein Problem - wird halt nochmal gesendet - aber bei UDP sind die Daten dann wech. Bei Kabel-LAN würde ich mal nach den Kabeln schauen - ein Switch sollte die 64KB eigentlich locker puffern können, selbst wenn der PC Gigabit und der RPi nur 100Mbit hat. Ansonsten gibts Wireshark oder tcpdump auch auf RPi. Damit müssten sich kaputte UDP Pakete erkennen lassen.
:
Bearbeitet durch User
Frank E. schrieb: > Natürlich wird nicht für jedes einzelne Zeichen eine Message gesendet, > sondern eine Message mit der Gesamtgröße von 55296. Diese wird vom > sendenden IP-Stack fragmentiert und am anderen Ende wieder > zusammengesetzt. sicher das das so funktioniert? Wo sollen denn die Infos herkommen, das ein UDP Paket fragmentiert ist? Dafür gibt es gar keine Infos im Header. UDP wird 1:1 übertragen, wenn es ein Teilnehmer nicht übertragen kann, dann wird es einfach entsorgt.
IP Fragmemntiert. Der IP-Layer liegt unter UDP (und TCP). Damit werden auf dem IP-Layer auch UDP-Pakete fragmentiert, nur bekommt, wenn alles funktioniert, der UDP-Layer davon nichts mit.
Jim M. schrieb: > Bei TCP kein Problem - wird halt nochmal gesendet Selbst da hat sich die IP-Fragmentierung als so schlechte Idee herausgestellt, dass man sie bei IPv6 nicht mehr im Programm hat. Dort muss ein Router in dem Moment, da er ein Paket fragmentieren würde, dem Absender eine ICMP-Nachricht senden in der er mitteilt, dass das Paket verworfen worden ist. Bei IPv4 tut man gut daran, die Paketgrößen so klein zu halten, dass man ebenfalls keine Fragmentierung braucht. TCP setzt daher typisch auch die Option "don't fragment", woraufhin sich die Implementierung danach ähnlich wie bei IPv6 benimmt und statt der Fragmentierung eine ICMP-Nachricht schickt; der TCP-Stack passt sich daraufhin dann an. Wenn man UDP benutzen will, sollte man sich einen ähnlichen Mechanismus ausdenken.
Jungs, die Diskussion läuft ins Abseits. Wie ich bereits schrieb, funktioniert es mit dem oft so verteufelten MacOSX als Sender vollkommen einwandfrei. Und auch bei Windows klappt es ja hin und wieder. Also steht die Frage, ob fragmentiert wird oder nicht oder ob das erkannt wird nicht wirklich. TCP ist auch dehalb keine Option, weil ich zwar heute nur mit einer LED-Anzeige herummache, es in Zukunft aber mehrere parallel sein müssen (Muticast). Die Frage ist, ob es unter Windows 7 bekannte Schwächen von UDP-Sockets gibt, die ich nicht kenne und aber irgendwie "workarounden" muss. Danke.
In Zeile 42 wird die Variable "tuf" nicht inkrementiert.
R42 schrieb: > In Zeile 42 wird die Variable "tuf" nicht inkrementiert. Das, und die offensichtliche Weigerung mal mit Wireshark (an der richtigen Stelle) nachzusehen was los ist.
Frank E. schrieb: > Also steht die Frage, ob fragmentiert wird oder nicht oder ob das > erkannt wird nicht wirklich. Doch, schon. Es ist durchaus nicht unwahrscheinlich, dass verlustig gegangene Fragmente die Ursache deines Problems sein könnten. Damit ist deine Weigerung, überhaupt über einen alternativen Ansatz nachzudenken, durchaus hinderlich. Muss ja nicht TCP sein, aber einfach die Erkenntnis aus 40 Jahren IP zu ignorieren, dass man eine Fragmentierung möglichst vermeidet (und dann entsprechend kleinere Nachrichten sendet) zeugt nicht gerade von klugem Handeln. Wie schon genannt, spätestens bei IPv6 (was ja nun immer mehr präsent wird) wärst du mit deiner Methode sowieso am Ende des Lateins.
Wenn ich Probleme mit TCP habe, dann nehme ich Wireshark. Dann kann man auf der Quell-Maschine sehen, was abgeschickt wird, und auf der Zielmaschine sehen was ankommt. Jese weitere Diskussion hier lohnt sich nicht, ohne dass wir Wireshark Mitschnitte haben. Denn bei UDP kann es ein Vielzahl von Problemen geben.
Habe das Problem zwar nicht gelöst, aber umgangen. Ich sende die UDP-Message einfach zweimal (schönes Wortspiel). Warum auch immer - unter Windows bringt mich das erstmal weiter, der Zeitplan drückt nämlich arg ...
Ein beliebter Fehler (auch in etlichen Tutorials) ist auf jedenfall den Rückgabewert von send() nicht zu prüfen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.