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.