Polling beim Empfangen von UDP-Protokollen

Heiko Schmidt schrieb:
> Meine Frage dazu - muss der Rechner, der
> die Pakete empfängt, ständig pollen, ob Daten über den UDP-Port
> ankommen, damit keine verloren gehen?

Nein. Das empfangende Programm wird vom Betriebssystem über einkommende 
Daten unterrichtet und schläft ggf bis dahin.

Heiko Schmidt schrieb:
> Wie mache ich das denn dann genau?

Im allereinfachsten Fall ist das ähnlich wie bei Files. Du forderst das 
Betriebssystem auf, dir Daten zu liefern, und der Aufruf kehrt erst 
zurück, wenn es welche gibt.

Tiefergreifende Erkenntnisse über Networking in Anwendungsprogrammen 
liefern dir Einführungen in Socket-Programmierung.

Die Vorgänge im Betriebssystem wiederum sprengen den Rahmen einfacher 
Forenfragen.

Heiko Schmidt schrieb:
> sowas hab ich mir vorgestellt. Und ggf. kann ich ein Timeout noch
> definieren, was dann ggf. den Prozess abbricht.

Nicht den Prozess, sondern den wartenden Betriebssystemaufruf.

Heiko Schmidt schrieb:
> Muss man bei UDP auch etwas wie Server-Client beachten?

Ob Peer-to-Peer oder Client-Server, das ist Sache der Anwendung. Anders 
als bei TCP wird auf Socket-Ebene keine Verbindung aufgebaut. Weshalb 
die Rollen von Client und Server auch nicht Teil des Betriebssystems 
sind.

> Muss ich z.B.
> meinen Windows-Rechner als Server betrachten, also dort einen Dienst
> drauf laufen lassen, der auf den Port horcht bzw. dann Daten sendet und
> am anderen Ende dann die Daten empfängt?

Wenn ein Prozess auf nichts lauscht, kriegt er auch nichts.

> Gibt es vlt. auch Netzwerkkarten, die Daten in eiem Puffer
> zwischenspeichern können und ein Bit haben, das man abfragen kann, ob
> dort was steht?

Sind wir noch beim RasPi, oder mittlerweile beim AVR? Solche Feinheiten 
darfst du getrost dem Betriebssystem überlassen. An der Netzwerkkarte 
hast du nichts verloren.

Aber ja, Netzwerkkarten haben Puffer, Betriebssysteme auch. Und aufs 
Netzwerk horchen und puffern tut das Betriebssystem, nicht dein 
Programm.

A. K. schrieb:
> Aber ja, Netzwerkkarten haben Puffer, Betriebssysteme auch. Und aufs
> Netzwerk horchen und puffern tut das Betriebssystem, nicht dein
> Programm.

Nur schmeißen die die Daten gleich wieder weg wenn keine Prozess zuvor 
angemeldet hat das es die Daten von dem Port haben will.

Daher muss natürlich ein entsprechendes Programm oder Daemon/Service auf 
dem PC laufen der den Port "Abhört"

bind & recv/recvfrom sind hier deine Freunde
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-bind
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recvfrom
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-recv

Das ganze entsprechend in eine eigenen thread gepackt und das Programm 
kann nebenbei auch noch was anderes machen...

Irgend W. schrieb:
> Das ganze entsprechend in eine eigenen thread gepackt

Dafür muss man allerdings die Eigenschaften und Besonderheiten von 
Threads kennen und ganz genau darauf achten alles threadsafe zu 
programmieren.

Ich kenne natürlich den Wissenstand des TO nicht genau, aber ich 
schließe aus den Fragen zu den Konzepten der Netzwerkprogrammierung daß 
sein Wissen im Bereich Systemprogrammierung nicht sehr ins Detail 
reicht.

Von daher bin ich mir nicht sicher ob ich da gleich Threads empfehlen 
würde. Vielleicht lieber erst mal mit Timeout warten.

Nezwerk-Kommunikation erfolgt über sog. "Sockets", also virtuelle 
Software-Schnittstellen, die die verwendete Programmiersprache vom OS 
anfordert.

Beim Nachrichtenaustausch wird auf Senderseite in das Socket 
"hineingeschrieben" und dann könnte es (z.B. als lokales Objekt in einer 
Methode) duchaus "sterben". Für die nächste Sendung wird halt ein neues 
Socket erzeugt. Abhängig vom Konzept des Programmierers kann man aber 
auch auf Senderseite so ein Socket durchaus auch mehrfach benuzen (als 
globales Objekt am Leben erhalten).

Nebenbei müssen die Sockets an beiden Enden der Nachrichtenverbindung 
noch kompatibel konfiguriert sein (passende IP, Portnummer, passende 
Message-Größe usw.)

Auf der Empfängerseite muss das Socket dagegen die ganze Zeit über 
existieren und "am Leben" sein, um keine Sendung zu verpassen. 
Einkommende Messages landen zunächst in eimem Puffer und können von dort 
gelesen werden.

Wie nun das benutzende Programm davon erfährt, ob denn nun inzwischen 
Daten angekommen sind - das geht je nach Programmiersprache auf 
unterschideliche Weise, die Wahl trifft wiederum der Programmierer. 
Tatsächlich besteht die Möglichkeit, die Größe des Message-Puffers zu 
pollen, die sich ja im Falle einer eintreffenden Message von Null auf 
irgendwas ändert.

Eine andere Möglichkeit ist es, das Socket mit einem sog. 
"Event-Listener" zu verbinden, der beim Eintreffen von Daten "feuert" 
und eine Routine aufruft, die die Daten dort ausliest und irgendwas 
damit macht ...

Vielleicht fängst Du erstmal mit ner abstrakteren Hochsprache an Dich an 
die Socketprogrammierung und die erforderliche Strukturierung des 
Programms und der notwendigen Abläufe (Threads oder nicht, Polling oder 
blockierend) vorsichtig heranzutasten.

Ich würde zum Beispiel Python vorschlagen, dessen Socket API lässt noch 
deutlich das darunterliegende C API durchschimmern (bind, listen, 
connect, accept, select, send, recv, etc...) so daß Du alles was Du da 
lernst später fast 1:1 auf C übertragen kannst aber da es eine sehr 
dynamische Scriptsprache ist lässt sich die Struktur Deines Programms 
viel leichtfüßiger mal eben schnell umkrempeln ohne zusätzlich noch die 
schwere Ankerkette der ganzen Low-Level-Befindlichkeiten und 
Erschwernisse einer Sprache wie C ans Bein gebunden zu haben.

In Python kannst Du Socket-Programmierung (und auch vieles andere auch) 
auf fast spielerisch einfache Weise erkunden und lernen und absolut 
ALLES was Du da lernst kannst Du später bei C (und auch bei anderen 
Sprachen) sehr nutzbringend einsetzen.

Viele Sachen die nicht CPU-lastig sondern eher IO-lastig sind kannst Du 
auch direkt in Python lassen, vor allem auf einem PC oder einem 
Raspberry wo man nicht die Kilobytes und die Taktzyklen zweimal umdrehen 
muss damit sie ausreichen. Für einen Programmieranfänger ist das IMHO 
allemal der bessere Einstieg, Du willst nicht an zu vielen Fronten 
gleichzeitig kämpfen.

Zu den Low-Level Abgründen systemnaher oder hardwarenaher Sprachen wie C 
bei denen man schon das blanke Silizium drunter durchschimmern sehen 
kann und den damit verbundenen peniblen Fleißarbeiten und 
Sicherheitsmaßnahmen kannst Du später immer noch promovieren sobald Du 
glaubst daß Du soweit bist das Wesentliche zu überblicken.

Und selbst dann in dieser zweiten und fortgeschrittenen Phase Deiner 
Programmierer-Karriere wirst Du immer noch jederzeit eine dynamische 
Hochsprache als nützlichen Helfer und auch als liebgewonnenen Freund 
stets hilfsbereit an Deiner Seite haben wollen mit der man jederzeit mal 
eben zum Ausprobieren oder Erkunden aus dem Handgelenk heraus monströse 
Datenstrukturen und Algorithmen so leicht herum wuchten kann als hätte 
jemand die Erdanziehung abgeschaltet.