Delphi UDP Kommunikation Indy über Internet

[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.