DataGramsocket Übertragungsproblem im Internet (IPs für Voip)

[athikka]

Hallo liebe Java-Forum Gemeinde!


Ich habe ein Problem was UDP (Datagramsockets) angeht.

Und zwar baue ich gerade einen VoiceOverIP chat mit UDP

Das ganze funktioniert schon ganz gut - solange es local läuft (Server: localhost, Client: localhost) - also alles auf einem rechner.

Nun habe ich aber einen Rechner der als Server fungiert und eine feste IP hat (im Internet), und zwei Clients die normal im Internet hängen (ohne statische IP), die sich aber zum Server verbinden können, der dann die Daten immer brav an den jeweils anderen Client weiterleitet.

Das Problem ist nun: Der Text-Chat geht über TCP (Sockets), aber wenn ich wen anrufen will, über UDP (Geschwindigkeitswegen)

Ich versende immer Klassen (Serialisiert) per UDP (Paketgröße ist fix mit 1201 Bytes).


Wie gesagt, Lokal geht es wunderbar, aber sobald ich diese Verbindung übers Internet mache (mit meinem Server) geht es ins nichts (ich sende und sende aber es kommt nichts an obwohl der Server erfolgreich weiterleitet.

Die Frage ist nun, wie ich die einzelnen Pakete an die richtige Client-Adresse weiterleiten kann (mit Socket.getInetAdress()) geht es auf alle Fälle ins nichts - ich denke mal das ist weil die IP der Clients nicht statisch ist.

Wie bekomme ich die "Ziel"-IPs an die ich die Daten weiterleiten soll? Wie gesagt die clients sind auch über TCP mit dem Server verbunden - also schriftlich chatten kann ich - mir fehlt einfach die IP der Clients damit ich die UDP-Pakete richtig versenden kann, damit sie eben auch bei den Clients ankommen.

Also wie komme ich an die IP, an die ein Socket per OutputStream sendet? Das wäre doch des Rätsels lösung...

Kann mir da wer helfen?

Vielen Dank schonmal im Voraus,
Niko

 

[FArt]

Also wie komme ich an die IP, an die ein Socket per OutputStream sendet? Das wäre doch des Rätsels lösung...

Nur in einer perfekten Welt. Im wahren Leben gibt es Router, Proxies usw. hinter denen sich einer (odere mehrere) Clients verbergen. (Siehe z.B. Network Address Translation ? Wikipedia)

 

[tuxedo]

mir fehlt einfach die IP der Clients damit ich die UDP-Pakete richtig versenden kann, damit sie eben auch bei den Clients ankommen.

Der Client könnte dem Server ja seine IP mitteilen. Dann wüsste der Server wohin er das Paket schicken muss. Allerdings ist das nicht ganz trivial da der Client ja selbst nicht unbedingt weiß wie er ans Internet über welchen Router angeschlossen ist.

Warum sendest du die VoIP Daten nicht per TCP? Wenn du den Nagle-Algo ausschaltest kommst du auf Latenzzeiten die UDP (fast) gleichkommen.

Hab ende 2007 im Rahmen meiner Diplomarbeit ebenfalls mit Audioübertragung experimentiert. Da hab ich der einfachheit wegen TCP benutzt. Mit einem passenden, kleinen Codec (Speex) konnte das Resultat trotz TCP durchaus mit Tools wie Teamspeak (damals noch Version 2) mithalten.

- Alex

 

[athikka]

Hallo

habe gerade den netzwerkverkehr mit Wireshark analysiert, und es sieht so aus, als ob der Server die UDP pakete zwar sendet, sie jedoch nur beim router ankommen (ip adresse vom router)... und es von dort nicht weiter in die tiefe geht.

Ein freund von mir hat mir geraten, mit UPnP anzuschauen - das würde angeblich dieses Problem beheben (Portweiterleitung)..

kennt sich da wer aus?

 

[Empire Phoenix]

Lass upnp, das würde gehen (so bei jedem 1 millionsten router der das unterstützt, aber glaub mir du willst das nciht.)

Dein Problem der Router weiß nicht wohin die eingehenden Packete sollen
Versuch es
a) einfach portweiterleitung einstellen,
b) UDP Portholing
c) nur verbindungen vom Client zum derver aufbauen(ist bei udp bisschen falsch formuliert, aber der client sendet das erste packet richtung server (zb beim anmelden), und danach solange leerlauf ab und zu ein keepalive senden.

 

[athikka]

kann es leicht sein dass der Fehler daran liegt (dass kein UDP paket durchkommt), dass ich die INetAdress der TCP verbindung benutze?

sollte ich also eine art "anmeldung" machen? habs noch nicht probiert da ich dachte dass ich mir die ip einfach aus der TCP verbindung raushole (die ja funktioniert)...