Delphi UDP Kommunikation Indy über Internet

[AJ_Oldendorf]

Hallo zusammen,
folgende Frage welche ein wenig zu dem Thema gehört:
https://www.delphipraxis.net/214724-...t-android.html

Ich habe eine Windows Anwendung auf einem PC mit einer statischen IP im LAN und einem TIdUDPServer und einem Port yyy.
Dieser Rechner ist im Internet über einen Router, wo ich eine Portweiterleitung eingerichtet habe auf der WAN Seite.
Wenn auf die feste Internet-IP Adresse mit dem Port xxx zugegriffen wird, wird diese auf die statische IP umgelenkt und der TIdUDPServer reagiert auf entsprechende UDP Telegramme.
Das funktioniert auch schon.

Das Senden übernimmt in diesem Fall eine Anwendung mit einem TIdUDPClient welche mit dem Internet verbunden ist.
Bis hier hin, alles gut.

Wenn der Server jetzt aber dem Client antworten will, gibt es für mich ein Problem.
Wie kann ich im UDPRead Event, dem Absender direkt antworten, sodass dieser das auch empfängt?
Das Problem dabei ist auch, dass der Client (Windows Anwendung) sich im Internet hinter einem Router mit statischer IP befinden kann als auch hinter einem Hot-Spot mit dynamischer IP. Ich habe auf dem Server versucht mit ABinding.Send zu reagieren im OnUDPRead Event, allerdings kommt im Client nichts an. Der hat auch kein OnUDPRead Event, dass hat ja nur der Server.

Lokal alles im LAN zwischen Server und Client ist kein Problem mit statischer IP aber sobald das Internet dazwischen ist, ist mir das noch ein Rätsel.
Könnt ihr da helfen?

[jaenicke]

UDP ist ein verbindungsloses Protokoll. Deshalb kannst du nicht einfach auf dem Absendeport antworten (womit man durch eine Firewall durchkommt), weil gar keine Verbindung besteht. Wenn du das möchtest, musst du TCP verwenden. Ansonsten brauchst du auf der anderen Seite auch eine Portweiterleitung.

[gubbe]

Das klingt schwierig, da UDP ja eben keine dauerhafte Verbindung aufrechterhält. Ein Client in einem privaten Netz hinter einem NAT-Router wird Pakete vom Server sowieso nur empfangen können, wenn er kurz zuvor etwas angefragt hat. Da müsstest Du unter dem Stichwort "UDP Hole Punching" recherchieren.

Was konkret in Deinem Beispiel nicht funktioniert, kann ich Dir allerdings nicht sagen. Vermutlich brauchst Du auf beiden Seiten sowohl Client als auch Server zum Senden und Empfangen der Pakete.

Ich würde aber überlegen, ein anderes Protokoll zu verwenden, wenn Du in beide Richtungen kommunizieren willst. Da würden sich Websockets anbieten.

[AJ_Oldendorf]

@jaenicke: Danke, damit habe ich gerechnet. War mir nur nicht sicher.
Ich schaue mir mal Websockets an.

[himitsu]

Zitat von jaenicke:

Deshalb kannst du nicht einfach auf dem Absendeport antworten (womit man durch eine Firewall durchkommt), weil gar keine Verbindung besteht. Wenn du das möchtest, musst du TCP verwenden. Ansonsten brauchst du auf der anderen Seite auch eine Portweiterleitung.

Im Prinzip will man ja seit Jahren HTTP auf UDP umstellen (erste Webseiten/Server und auch die großen Browser können es angeblich schon)
um die Lazenzen zu verringern, weil TCP ja ständig nochmal rückfragt und auf Rückantwort der Antwort wartet, durch Verbindungsstellen/Proxy/Sonstwas hindurch. (fehlende Daten sollen dann auf Softwareebene beandelt werden und nicht mehr im Übertragungsprotokoll selbst)

Im Grunde muß da aber ja irgendwie der Server dann doch die Antwort zurück zum Browser schicken können ... weiß nur grade nicht wie.




Aber ja, im Delphi wirst du da wohl auf beiden Seiten erstmal Server und Client haben müssen, um Daten in beide Richtungen schicken zu können.

[Kas Ob.]

[QUOTE=himitsu;1534562]

Zitat von jaenicke:

weiß nur grade nicht wie.

Fair question, and right on point, and yes if UDP as we know it from popular resources can't pass the packets inward from the Internet to specific NAT devices then how on earth QUICK and HTTP3 is working !??

and How my android with 4G connection with no real/Static IP is connected to my router using WireGuard ?

And the answer is Stateful Packet Inspection, there is many pages explain it better than me with better language, but to be consistent with myself i will explain it in few words.

It is a technology that implemented in everywhere and no one specifically being notified, but not for the bad reasons on contrary it will give the routers and switches nice features, like in case with UDP if a packet went from specific local (NAT) address and port X:p to Y:r then anything UDP from Y:r to the router will be forwarded to that specific local X:p, without explicitly using UPNP or manually configure the router for port forwarding.

So in your case you can do it but remember there is no standard for this forwarding, this means there is no specific Time-To-Live (TTL) for such unspoken and hidden port forwarding rule, meaning your client should keep pinging the server at some T intervals, thus you server can send UDP packet to it as answers, find T on your own, i know T=30 is absolutely working everywhere, but 5 minutes should be fine too, again it is not standardized.

[Kas Ob.]

By the way, the one most perplexed me is not UDP, is this :

How on earth ICMP from google.com being answered on my PC while i have two routers to reach my ISP ?

[Michael II]

Wenn dein Server wirklich von aussen via UDP erreichbar ist, dann ist es normalerweise problemlos dem Sender zu antworten.
(Wenn dem nicht so wäre, dann würden viele Mediastreams etc nicht funktionieren.)

Wenn der Sender sich hinter NAT Router "versteckt", dann merkt sich dieser Router die Verbindung Sender -> Server trotzdem, lässt umgekehrt Server -> Sender Kommunikation aber nur zeitlich beschränkt zu.

Was also funktioniert ist: Sender sendet Paket an Server, Server antwortet sofort/zeitnah.

Was oft nicht funktioniert ist: Server sendet Paket an Server, Server antwortet irgendwann später. Grund: Der Router auf Sender Seite hat den Kommunikationsweg gelöscht.
In solchen Fällen musst du wie KasOb schreibt sicherstellen, dass sich der Router des Senders die Verbindung Sender -> Server weiterhin merkt und so Pakete Server -> Sender zulässt (Schau dir die Socketoption SO_KEEPALIVE an, oder wie KasOb schreibt: Regelmässig Pakete hin- und her senden.)

Hier wurden noch STUN und hole punching erwähnt. Solche Technologien werden erst dann notwendig wenn sowohl Sender wie Server hinter NAT sind und auf keiner Seite eine Portweiterleitung eingerichtet ist. Ein Dritter vermittelt dann den direkten Aufbau zwischen den zwei Beteiligten, wenn's direkt nicht klappt erfolgt die Kommunikation über einen Dritten (TURN).

Wenn du einen Server betreibst, welcher über längere Zeit ab und zu Pakete mit dem Sender austauscht, dann würde ich TCP verwenden. Eine einmal aufgebaute Verbindung steht dann, bis du sie wieder abgebaut hast.

Nebenbei: Mit IPv6 lassen sich mittlerweile in meinem Netzwerk (Spiel) ca. 2/3 aller UserInnen direkt via tcp miteinander verbinden. Ein "harter Kern" verwendet IPv4/tcp und Portweiterleitung. Dieser Kern vermittelt bei Bedarf die IPv6 Verbindungen. UDP hole punching hatte ich auch eingebaut; aber dies führte bei einigen Wächtern zu Warnungen.

[AJ_Oldendorf]

Moin,
ok, ihr sagt, es müsste also gehen, wenn man vom Server direkt/zeitnah antwortet.

UDPRead (AThread: TIdUDPListenerThread; const AData: TIdBytes; ABinding: TIdSocketHandle); Das ist das Event beim Server, welches auch ausgelöst wird, wenn vom Client etwas empfangen wird.
Da auf der Server Anwendung nur ein TIdUDPServer vorhanden ist, kann ich dem Client nur über "ABinding" antworten oder?
ABinding hat zumindest ein ".Send"
Beim Client habe ich außer dem dem TIdUDPClient (mit welchem ich auch die Daten geschickt habe), zusätzlich ein TIdUDPServer welcher aktiv ist und den gleichen Port nutzt wird der Client (um die Antworten zu empfangen).
Leider wird an der Client-Anwendung beim TIdUDPServer kein Event OnUDPRead ausgelöst wenn ich in der Server Anwendung mit "ABinding.Send" antworte. Wie muss das antworten entsprechend erfolgen?

[Michael II]

Zitat von AJ_Oldendorf:

Moin,
ok, ihr sagt, es müsste also gehen,

Ja natürlich muss es gehen. Viele Video/Audio Streams werden via UDP übertragen. Und wir sehen Bilder und wir hören Musik .

Indy nutze ich nicht. Ich nutze Overbyte ICS. Hab's soeben damit getestet. Server erreichbar - Client hinter NAT:

Du hast leider keinen Code gepostet.
Entweder blockiert bei dir eine Firewall oder du hast zu wenig auf (Adressen.Ports) geachtet, welche du verwenden musst, wenn du nicht "nur" lokal UDP verwendest.

Ablauf:
0. Server ist unter (SA,SP) erreichbar.
1. Der Client mit Quelladresse (CA,CP) sendet die Daten mit Zieladresse (SA,SP) an seinen Router; der Client Router sendet die Daten weiter an den Server. Dabei verwendet der Router als Absenderadresse (RA,RP).
Router abhängig: RP muss nicht CP sein (!).
Der Clientrouter merkt sich (CA,CP)->(RA,RP)->(SA,SP).

2. Der Server empfängt das Paket. Serverseitig musst du (RA,RP) ermitteln. ICS im OnDataAvailable zum Beispiel so (siehe auch Beispiele ICS):

Delphi-Quellcode:

  SrcLen := SizeOf(Src);
  Len    := (Sender as TWSocket).ReceiveFrom(@Buffer, SizeOf(Buffer), Src, SrcLen);
  senderaddr :=  StrPas(inet_ntoa(Src.sin_addr));
  senderport :=  IntToStr(ntohs(Src.sin_port));

3. Die Serverantwort sendest du mit Quelladresse (SA,SP) an (RA,RP). Also unbedingt SP als Quellport wählen. Wenn du nur lokal mit UDP spielst, spielt der Quellport keine Rolle.
4. Die Daten kommen beim Clientrouter an. Der Router sieht das Paket (SA,SP)->(RA,RP) und findet in seiner Tabelle die ausgehende Verbindung (CA,CP)->(RA,RP)->(SA,SP). => Der Router leitet das Paket an (CA,CP) weiter.

Wie erwähnt: Irgendwann vergisst der Router die Verbindung (CA,CP)->(RA,RP)->(SA,SP) wieder, weiss dann nicht mehr, wem er das Paket zustellen soll und lässt deshalb keine weiteren Pakete vom Server zum Client durch. Dies kannst du verhindern durch SO_KEEPALIVE oder durchs Senden von irgendwelchen Paketen.