Moderiert von Narses: Abgetrennt von hier.

So. Wenigstens habe ich die Ursache gefunden. Jetzt fehlt bloß noch die Lösung

Über das VPN kommt - wenn es gut läuft - nur jedes 2. bis 3. und - wenn es schlecht läuft - gar kein Paket an. Ich habe mit TUdpSockUtil mal 2 Programme zusammengebastelt; eines sendet unentwegt Pakete, das andere lauscht nur. Falls Bedarf besteht, habe ich das angehängt. Wenn es stört, kann es der Admin gern wieder löschen.

Ich stehe jetzt vor der Frage, wie ich weiter mache.
Ich könnte jetzt wieder mit TCP/IP arbeiten, was ich aber nicht will, weil ich dann wieder 2 Programme (Client und Server) dauerhaft warten muss.
Alternativ grüble ich gerade darüber nach, wie man sinnvoll vorgeht. Ich könnte jetzt die Pakete z.B. fortlaufen numerieren und dann so lange senden, bis ich vom Empfänger die Meldung bekomme, dass das Paket mit der spezifischen Nummer angekommen ist. Das wäre soweit mein Plan. Ich vermute aber, dass es evtl. einfacher gehen könnte. Immerhin habe ich Erinnerung, dass Filesharing Tools mit UDP arbeiteten. Irgendwie musste man da früher im Router irgend welche UDP-Ports freigeben. Wenn das so wahnisinnig aufwendig ist, hätten die es vielleicht anders gelöst.

Kann mir da bitte mal jemand Ideen spenden? Ich bin auch gern bereits, das Ergebnis hier zu teilen.

[EDIT]
Tausend Dank, Narses!
[/EDIT]

Moin!

Schwedenbitter hat folgendes geschrieben :

Über das VPN kommt - wenn es gut läuft - nur jedes 2. bis 3. und - wenn es schlecht läuft - gar kein Paket an.

Das hat mit dem VPN nix zu tun, sondern ist für UDP by-design (und von der Auslastung der WAN-Stecke abhängig: ist die "voll", werden UDP-Pakete einfach weggeworfen ).

Schwedenbitter hat folgendes geschrieben :

wieder mit TCP/IP arbeiten [...] die Pakete z.B. fortlaufen numerieren und dann so lange senden, bis ich vom Empfänger die Meldung bekomme

Du hast deine Frage bereits selbst beantwortet.

cu
Narses

Schwedenbitter hat folgendes geschrieben :

Ich könnte jetzt wieder mit TCP/IP arbeiten, was ich aber nicht will, weil ich dann wieder 2 Programme (Client und Server) dauerhaft warten muss.

Wir benutzen auch Clients, die sich per UDP Broadcast nur finden, aber per TCP beidseitig kommunizieren. Du kannst ja nicht nur einen TCP-Client aufmachen, sondern kannst auch gleichzeitig einen Server anbieten. Dann hast du auch bei TCP nur ein Programm, das gleichzeitig als Client und als Server fungieren kann.

Schwedenbitter hat folgendes geschrieben :

Ich könnte jetzt die Pakete z.B. fortlaufen numerieren und dann so lange senden, bis ich vom Empfänger die Meldung bekomme, dass das Paket mit der spezifischen Nummer angekommen ist.

Du beschreibst genau die Funktionsweise beim Senden von TCP Paketen. Der Unterschied ist nur, dass das bei TCP automatisch auf Ebene der Netzwerkkarte passiert.