Chromoting to report roundtrip latency

Doing so by sending a sequence number, essentially the timestamp in every
envet message. Capturer at the host will pick up the latest sequence number
and pass it through the pipeline. Client will then receive it and determine
the latency.

This roundtrip latency number however doesn't include time in decoding and
rendering.

BUG=None
TEST=None

Review URL: http://codereview.chromium.org/6792038

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@84504 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 5 insertions, 1 deletions

diff --git a/remoting/protocol/host_message_dispatcher.h b/remoting/protocol/host_message_dispatcher.h
index 5752f95..67df286 100644
--- a/remoting/protocol/host_message_dispatcher.h
+++ b/remoting/protocol/host_message_dispatcher.h
@@ -13,6 +13,7 @@
 namespace remoting {
 namespace protocol {
 
+class ConnectionToClient;
 class ControlMessage;
 class EventMessage;
 class HostStub;
@@ -37,7 +38,7 @@ class HostMessageDispatcher {
 
   // Initialize the message dispatcher with the given connection and
   // message handlers.
-  void Initialize(protocol::Session* session,
+  void Initialize(ConnectionToClient* connection,
                   HostStub* host_stub, InputStub* input_stub);
 
  private:
@@ -57,6 +58,9 @@ class HostMessageDispatcher {
   // MessageReader that runs on the event channel.
   scoped_ptr<ProtobufMessageReader<EventMessage> > event_message_reader_;
 
+  // Connection that this object belongs to.
+  ConnectionToClient* connection_;
+
   // Stubs for host and input. These objects are not owned.
   // They are called on the thread there data is received, i.e. jingle thread.
   HostStub* host_stub_;