Determining the latency (using Ping)

[not!an!exit]

Greetings everyone.

I'm trying to implement an ingame display of player latencies.

Now, there is a class Ping and a PingTest example that uses MessageClient. I'm having trouble looking through the JGN-implementation here, so I hope you can help me out. I hope I haven't overlooked similar threads in this forums...

But back to the topic: I built my connection between server and clinet according to the FlagRushTest-example in the jme-networking project. On the client side I habe a JGNClient thread, on the server side a JGNServer thread. How do I get the MessageClients that are needed to create remote Ping objects? Can I somehow use the JGNServer and JGNClient connection to get one or do I have to create more threads?

And some other questions directly concerning ping calculations:
Is it appropriate for the server to ping the client and for the client to ping the server? Or does the server ping everybody and propagate the values to all clients?
Does the method in TestPing determine the real ping or rather a round-trip-time?

[darkfrog]

JGNServer and JGNClient contain MessageClients and MessageServers.  However, it would be trivial to write a ping test another way as well.  The current ping test just uses shared objects.  Although really easy and simple, it probably isn't practical if dealing with several servers (like a server list).  If you created a Ping message and Pong message that simply have an associated "long" for the time it was sent.  You could add a listener on all systems for a Ping message and immediately respond with a Pong message and apply the "long" from Ping to it.  Upon receipt of a Pong message you could determine the Ping time by System.currentTimeInMillis() (or you could use System.nanoTime() for better accuracy) - pong.getTimeSent() and it would give you the delay.  Does that make sense?

Either way is perfectly acceptable when you're already connected to a server though.

[not!an!exit]

Does that make sense?

Yeah, it does.
Just one thing about the MessageClient and MessageServer thing.

Suppose I am the client. JGNClient and JGNServer both return MessageServers. What about the MessageClients?
I have a getReliableServer().gerMessageClient(SocketAddress) method. Is this the way to go? Do I just insert the SocketAddress I use for the regular connection?

[darkfrog]

On the client you can call client.getServerConnection().getFastClient() and/or client.getServerConnection().getReliableClient()

[not!an!exit]

Okay, I've been fooling around with messages and pings a bit and after reading this thread about TimeSynchronizationMessage I've tried to do the  follwing:

We have a two player game where one player is the server at the same time. Another player connects and synchronizes his time:

Code:

client.connectAndWait(serverReliable, serverFast, 5000);
client.getServerConnection().getFastClient().synchronizeTimeAndWait(5000);

I have implemented a simle ping system where a timestamped ping (with System.nanoTime()) is sent to another peer, who basically sends it back. The ping im milliseconds is then determined by

Code:

(System.nanoTime() - pong.getTime()) / MILLI2NANO / 2;
 \_____________________________/       \_________/ \_/
  round trip time (rtt) in nanos        to millis   to ping

Now, what I do is (after adding "implements TimestampedMessage" to Pong):

Code:

public void messageReceived(Pong message) {
LOG.debug("PONG: " + (System.currentTimeMillis() - message.getTimestamp()));
}

That should - according to my understanding of the use of time synchronization - give me approximately the same result: the ping in milliseconds.
But the difference between my ping calculations and the TimestampedMessage-method ranges between 30 and 100 milliseconds. Unfortunately I am testing running server and client on one machine. My local ping is usually about 3 ms (which appears to be realistic). The TimestampedMessage-method results in local pings of 35 to about 100 ms.

Am I doing something generally wrong? Or any ideas what may be causing this effect?

[darkfrog]

I just added a new utility to JGN to help better handle this kind of thing.

Now, because of the asynchronous nature, the ping times may be further off than really is the case, but it at least gives a pretty fair and easy way to determine ping times.

Now you only have to call Ping.pingAndWait(messageClient, TimeUnit.MILLISECONDS) and you'll get a long back representing the amount of time in milliseconds it took to respond.  That should make pinging a little faster and easier.

[not!an!exit]

Does pingAndWait block the application while waiting for reply? I'm not sure that does make much sense.
I used to ping "in the background" to always have a current ping handy while the game is running.

And another thing is that I'd really love using synchronized time beween server and client to be able to calculate the real message delay from it's timestamp. Is this properly working? The thread about it that I linked earlier tells no results.

I was surprised to get that different results from my own ping calculation and the synchronized timestamps, and I did not quite got any wiser till now...

[darkfrog]

pingAndWait will block the current thread until it returns, yes.  However, there is also just a ping method that returns a Future<Long> as well.

TimeSynchronization should work just fine.  Let me know if you run into any problems with it.

The different results may be due to the asynchronous nature of JGN. Depending how your update threads work it can cause lag moving from queue to queue before it gets to the final resting place. This is also problematic in a game as CPU hungry threads can cause delays as well.

[not!an!exit]

Just for the record: If I synchronizeAndWait after I connected and then receive messages that implement the TimestampedMessage interface, (System.currentTimeInMillis() - message.getTimeStamp()) sould be the ping. Right?

[darkfrog]

No, since that represents the time the message was enqueued from the other machine and a ping is a full cycle ping/pong.

[not!an!exit]

So, are you saying that it should give me half the time of a full-cycle ping/pong?

I'm sorry, I don't get it. If I send custom ping/pong messages, I calculate a (one way) delay of about 5 ms. Making my SynchronizeMessages implement TimestampedMessage and calculating the (one way) delay by System.currentTimeMillis() - message.getTimestamp() results in values beyond 25 ms.

[darkfrog]

Like I said previously, the way that JGN does things asynchronously can cause additional delays if other communication is happening.  In addition, you're using System.currentTimeInMillis() which does not provide good granularity on most operating systems.  This is why I typically use System.nanoTime() these days.

http://java.sun.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis()

In addition, the timestamp may be off by by several milliseconds.  It was not intended for such precision, it was more designed for scenarios when you want to see if a message is more than a few seconds old so it's not really surprising that it doesn't fit the bill for determining ping time.  I also fear it's something that cannot easily be resolved since you cannot use nanoTime to determine time offset.

[not!an!exit]

I still have the impression that something's fishy here... But may be it is my understanding. Help me out.

I have read through the synchronizeTimeAndWait() implementation and I think it does the following:


Now note that on both client and server timeConversion is set to the round trip time (rtt) of the message. It appears to me that it has nothing to do with time synchronization but rather a rtt calculation for both parties, a ping.

[darkfrog]

I'll leave this open and come back to it later, I've been driving all day and my brain is too tired to look at diagrams. 

[not!an!exit]

Okay, take your time. I'll check back later...