alle 20 sec ein 2 sekunden Lag im Java-Spiel

[Guest]

Hallo.

Bitte um ein kleines Brainstorming.
Ich schreibe gerad ein kleines java-spiel.

Randdaten:
Client - Server kommunikation:
- der client sendet Steuerbefehle
- der server sendet Positionen ...
Kommunikation:
server sendet UDP-Pakete über ein MulticastSocket
bei dem client hab ich sowohl eine TCP verbindung versucht, als auch ebenfalls eine udp verbindung über ein MulticastSocket. Das Problem tritt in beiden Fällen auf.

Problembeschreibung:
Zunächst läuft alles Bone. Aber in etwa in 20sec Intervallen gibt es ein lag (für etwa 2 sec bekomme ich <50% der UDP-Paket (sonst sind 40/sec a 128byte, in den 2sec sind <20/sec) .

Ja, ich hab auch erst an den GC gedacht, aber:

Das Spiel kann auch im Single-Player gespielt werden, wobei die KI auch als client implementiert worden ist, der analog zu einem menschlichen Gegner seine Steuerbefehle über den Socket sendet. Der einzige Unterschied ist, dass bei der KI jeweils die Pakete den Rechner nicht verlassen müssen...
Daher halte ich es eher unwahrscheinlich dass der GC der böskerl ist.

Randinformationen:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"DisableUserTOSSetting"=dword:00000000

(check)

public static final int IPTOS_LOWCOST			= 0x02;
public static final int IPTOS_RELIABILITY			= 0x04;
public static final int IPTOS_THROUGHPUT			= 0x08;
public static final int IPTOS_LOWDELAY			= 0x10;
	
public static final int TRAFFIC_CLASS			= IPTOS_LOWDELAY | IPTOS_RELIABILITY;

mcSocket.setTimeToLive(1);
mcSocket.setTrafficClass(Globals.TRAFFIC_CLASS);

...

Bin für jeden Ansatz dankbar....

MFG Nils

 

[HoaX]

im lokalen internet oder im netzwerk?
wie hast du gemessen wann welche pakete ankommen?

 

[suelman]

Netzwerk:
Das problem tritt sowohl im lokalen Netzwerk (100Mbit), lokales Netzwerk (1000Mbit) als auch über die DSL Leitung (himachi-VPN) auf.

Messen:
Also ich hab mir noch nicht die Mühe gemacht die Wireshark - log auszuwerten.

Ansonsten messe ich über die FPS. Ich muss die Scene mit dem Netzwerkstrom Synchronisieren, da ich sonst böse - ruckeleffekte bekomme. Sprich nach jedem Datensatz zeichne ich ein Bild, und wenn die Daten nicht kontinuierlich kommen wird das Frame entsprechen nicht zur richtigen zeit gemalt. Aber ist n guter Punkt, muss ich mir doch wohl die Wireshark log anschauen, denn kann ichs schon mal auf Server / Client eingrenzen .
Danke HoaX

 

[suelman]

Also:
Wireshark auf Client gestartet
Wireshark auf Server gestartet

Ich hab die Daten ausgewertet, indem ich die Zeitstempel jeweils in 250ms intervallen accumuliert habe und in einem Matlab - Plot gegenübergestellt habe.

Herausgekommen ist, dass die Pakete den Server ohne Lags verlassen, beim Client die Lags auftreten.



Bei einer Paketgröße von 128Byte; 40 Paketen die Sekunde bekommt der Client genau alle 60 Sekunden für 4 Sekunden die Pakete nicht mehr gleichmäßig. Die Intervalllängen sind absolut gleichmäßig.
Das problem tritt auch auf anderen Rechnern mit anderen Routern/Switches auf.

Kennt jemand das Problem ?


Source:

///////////Server in etwa so :
MulticastSocket mcSocket = new MulticastSocket(5000);
mcSocket.setInterface((InetAddress.getLocalHost()));
mcSocket.setTimeToLive(1);
InetSocketAddress msaddr = new InetSocketAddress(InetAddress.getByName("230.0.0.1"),5000);
byte[] networkBytesUDP = new byte [128];
DatagramPacket dPacket = new DatagramPacket(networkBytesUDP, networkBytesUDP.length);
dPacket.setSocketAddress(msaddr);
mcSocket.setTrafficClass(TRAFFIC_CLASS);
while (running){
	dPacket.setData(networkBytesUDP);
	mcSocket.send(dPacket);
	Thread.sleep(25);
}
///////////////////////////////Client in etwa so:

MulticastSocket mcSocket  = new MulticastSocket(5000);
mcSocket.setTrafficClass(TRAFFIC_CLASS);
mcSocket.setInterface((InetAddress.getLocalHost()));
InetAddress maddr = InetAddress.getByName("230.0.0.1");
mcSocket.joinGroup(maddr);
byte[] data = new byte[128];
DatagramPacket dp = new DatagramPacket(data, data.length);
while (running){
    mcSocket.receive(dp);
}

 

[HoaX]

ich denke mal nicht dass es direkt mit dem netzwerk zu tun hat.

a) mach dir logausgaben von Syste.currentTimeMillis vor und hinter das mcSocket.receive, dann siehst du wie lange er dort hängt
b) erstelle einen kompletten stacktrace wenn das lag auftritt, so solltest du schnell herausfinden können was den betrieb aufhält

 

[Kr0e]

Hmm, da es periodisch auftritt, würde ich mal ganz klar darauf schliessen, dass es was mit dem Code zu tun hat, da ja andere Router/Pcs/Switches/Netzwerke das selbe Problem auftun!

Du solltest bedenken, dass UDP sowieso nicht so ganz das wahre ist, was die Reihenfolge von DAten angeht.

Denn da UDP verbindunglos arbeitet, wird ja bei send auch meines Wissens garnicht gewartet, bis der Recvbuffer des Gegenüber frei ist !

Anders ist dies bei TCP!!
Bei TCP werden die ACK Flags benutzt, um der Gegenseite zu zeigen, "Hey, bin ready, mach mal weiter hier!"!

Also ich könnte mir gut vorstellen, dass das Timing (damit meine ich das Senden der Daten) schlecht gewählt ist, im Verhältnis zur Empfangsgeschwindigkeit und dadurch PERIODISCH das Spiel iwann mal etwas mehr rechnen muss...

Mein erster Ansatz wäre, vlt über einen zweiten Socket auf beiden Seiten Kontrolldaten auszutauschen! Wieviele Bytes sind wann und wielang eingegangen usw.. Muss vlt iwas nochmalgeschickt werden ?! usw..

Gruß Chris

 

[suelman]

@Kr0e da das spiel mehrspieler & 0-n visitors unterstützen soll ist ein multicast schon die richtige wahl glaube ich.

Ansonsten hab ich das Problem nun identifiziert.

Ich war mir zwar sicher, aber scheinbar hab ich gelogen als ich geschrieben hab:

>> Netzwerk:
>> Das problem tritt sowohl im lokalen Netzwerk (100Mbit), lokales Netzwerk (1000Mbit) als auch über die DSL Leitung >> (himachi-VPN) auf.

Die letzten male wo ich getestet habe hatte ich entweder client oder server immer über eine WLAN mit WPA2 Verschüsselung verbunden. Sobald ich nun auf eine verdrahtete Verbindung wechsle läuft alle flüssig (selbst übers Himachi VPN @ DSL Leitung).
Der Fehler scheint reproduzierbar auf WLAN Verbindungen mit WPA2 (Gut, ich hab nur in 2 LANs mit 4 verschiedenen Rechnern getestet, aber da ist er reproduzierbar aufs WLAN mit WPA2).

Obs nun an der WPA2 Verschlüsselung liegt, oder obs generell am WLAN liegt muss ich nochmal testen (nu wird aber erst schnell das spiel fertig gestellt... )

Ferner ich die Ursache noch weiter einschränken kann werd ichs denn posten..

Trozdem erstmal danke soweit für die Antworten.

MFG

 

[Kr0e]

Hi,
wegen dem MulticastSocket....

ICh bin mir nicht sicher, aber war es nicht so, dass MulticastSocket noch garnicht von jedem Router/SWitch unterstützt wird... ? Naja, egal... Ansich haste recht... Aber ich glaube, dass bei deiner Anwendung, auch tcp reichen sollte

 

[HoaX]

viele switches, auch billige, machen das mittlerweile, ganz sicher werden die aber nicht übers internet gesendet. d.h. will man übers internet spielen braucht man zwangsläufig ein vpn mit seinem gegenüber

 

[suelman]

@Kr0e du kennst meine Anwendung doch garnicht

@TCP Verbindung:
Hab ich auch implementiert, läuft auch, beim WLAN tritt aber die gleiche Problematik auf

@UDP Braucht man übers Internet wirklich n vpn oder reicht es wenn man eine entsprechende Portweiterleitung im Router einstellt und beim Server die TTL entsprechend der Anzahl der Router/Switches bzw Netzwechsel hochsetzt ??

Ich mein, wie läuft das denn mit Video - Broadcasts ? Gehen die nicht auch über UDP oder wie realisiert man Broadcasts per TCP ??

 

[Kr0e]

@suelman: Naja, wie auch wenn du keinen Code zeigst.

Also wenn du sagst, dass es bei TCP auch nicht klappt, nun dann kann ich auch nicht helfen.
Außerdem, das Beispiel, dass du da gepostet hast, das funktioniert mit TCP ohne Probs.

Deshalb dachte ich nunmal, dass es an UDP liegt, wenn ich nämlich deinen Post via MulticastSocket
(Also UDP) etwas anders mache, nämlich nach z.b. x Packeten mal nachfragen "Na, alles bekommen ?"...,
dann klappt auch dieses Beispiel ohne Probleme. Wie schon gesagt, lliegt wohl an deinem Code...

Willst du das Spiel verkaufen bzw. den Code geheim halten, oder warum scheust du dich so davor, die Stellen
zu posten, die mit der Netzwerkübertragung zu tun haben ? (Dein Post klappt nämlich, wenn man ab und zu nach schaut ob alles angekommen ist...)

Gruß Chris

EDIT:

Du hast geschrieben:

Du kennst meine Anwendung doch garnicht

NAja, kennen tu ichs nicht aber du sagtest auch

Ich schreibe gerad ein kleines java-spiel.

Deshalb dürfte bei dir wohl auch TCP ausreichen.

 

[HoaX]

ich bezog mich auf das multicast das nicht geroutet wird im internet, p2p-"verbindungen" mit tcp/udp gehn ohne probleme

 

[suelman]

@HoaX ah, das mit dem Multicast wusst ich nicht, danke für die Info.

@Kr0e also wie gesagt, bei der TCP Übertragung übers WLAN treten die gleichen Probleme auf. Das Verrückte an der Sache ist ja auch, dass wenn die Datenmenge größer gemacht wird, sprich größere oder mehr Pakete verlängern sich die Intervalle in denen die kleinen Störungen auftreten...

@Kr0e Also das Spiel wirds wohl irgendwann frei geben (ich will den code auch wohl posten wenn er fertig ist)
Nur sind insgesammt nun mehr als 500KB reiner Quellcode ... daher nicht hier.
Zudem hab ich die relevanten Sachen mit den Netzwerk hier ja gepostet.
Also wenns bei dir geht sag mir bitte was du für ein WLAN hast , bzw. welche Verschlüsslung und was für eine Telefonanlage.
Also mit WPA2 und ner Friz.box gehts scheinbar nicht, dass hab ich bei zwei Verschiedenen Geräten getestet.
@Testen: Man muss schon sehr genau hinschauen um das Problem zu erkennen, weils recht Zeitkritisch ist. Also eine Aufsummierung der Pakete in Sekundenintervallen reicht da nicht. Man braucht schon mindestens eine Auflösung von 250 ms. Am besten auch im Matlab-Plot oder vergleichbares, sonst lässt sich das nicht identifizieren.

MFG Nils

 

[Kr0e]

Hi,
ich habe eine FritzBox 7170, WLAN (WPA 2)
Mit meinem Notebook (1,6 ghz XP - recht alt...) 54mbit Wlan PCMCIA-Karte,
dieser Code von oben (2x getestet - Einmal mit einem "Check-Socket", wo geprüft wird, wieviel ankam usw..., und einmal mit größeren Packeten, nicht 40 einzelne sondern ein großes jeweils + "Check-Socket") klappte ansich ohne Probleme oder lags. Ich habe das dann mit Hilfe der aktuellen Millisekunden die Differenz ermittelt und habe nirgends höhere Abweichungen als maximal 20 - 30 ms bekommen. ISt ja auch WLAN. Über LAN habe ich immer 0-1 ms abweihung.

Gruß Chris