Documentation of live usage and protocol
authorJulien Desfossez <>
Fri, 27 Sep 2013 20:28:40 +0000 (16:28 -0400)
committerDavid Goulet <>
Fri, 27 Sep 2013 22:28:47 +0000 (18:28 -0400)
Signed-off-by: Julien Desfossez <>
doc/live-reading-howto.txt [new file with mode: 0644]
doc/live-reading-protocol.txt [new file with mode: 0644]

index f57abf42a66f102aa506e94a046d89ad8d751769..6f05d7a78de86977d8bcf845910060d6612e764c 100644 (file)
@@ -1,6 +1,8 @@
 SUBDIRS = man
 EXTRA_DIST = quickstart.txt streaming-howto.txt python-howto.txt \
-       snapshot-howto.txt calibrate.txt kernel-CodingStyle.txt
+       snapshot-howto.txt calibrate.txt kernel-CodingStyle.txt \
+       live-reading-howto.txt live-reading-protocol.txt
 dist_doc_DATA = quickstart.txt streaming-howto.txt python-howto.txt \
-       snapshot-howto.txt calibrate.txt
+       snapshot-howto.txt calibrate.txt live-reading-howto.txt \
+       live-reading-protocol.txt
diff --git a/doc/live-reading-howto.txt b/doc/live-reading-howto.txt
new file mode 100644 (file)
index 0000000..4a54f1c
--- /dev/null
@@ -0,0 +1,53 @@
+LTTng Live trace reading how-to
+Julien Desfossez
+September 27th, 2013
+This document presents a summary on how to use the live trace reading feature
+introduced in LTTng 2.4. For the details about the protocol, please refer to
+the live-reading-protocol.txt document.
+Live trace reading refers to the feature of reading the trace while it is being
+recorded. In order to do that, the trace must be streamed a relay even if the
+viewer is running on the same machine as the tracer.
+So, the first thing to do is to start a lttng-relayd process. It can be
+anywhere on the network (including localhost) as long as the sessiond/consumerd
+and the viewer can communicate with it over TCP/IP.
+$ lttng-relayd -d
+Then, we can create a session configured for streaming with the new --live
+$ lttng create --live 1000000 -U net://localhost
+The --live parameter activates a session-wide timer (usec) that is responsible
+for checking at a user-defined rate if new data is available. If there is new
+data, it is flushed automatically, otherwise a beacon is sent to the relayd to
+inform it that the stream is currently empty and the viewer can ignore this
+stream up to a certain point in time.
+Once the session is created, the user can activate events as usual.
+In order to view the live trace, the viewer must implement the live-reading
+For now, a basic client is available in the branch index2013 of the git
+repository :
+This client is still in heavy development and the branch will be rebased, it is
+only provided as a proof-of-concept and an exemple on how to use the protocol.
+Once compiled and installed, just run :
+$ test-live hostname 2>/dev/null
+If you want to see all the debug, just get rid of "2>/dev/null".
+Once again, it is a client in development, the name is purposely bad and the
+debug output is relatively heavy.
+Known viewer issues :
+- adding metadata on the fly (enabling events when a viewer is connected)
+- destroy not clean
+- aggressive polling when all the streams are inactive (after a lttng stop)
+- restart reading from the beginning (SEEK_LAST not implemented yet)
diff --git a/doc/live-reading-protocol.txt b/doc/live-reading-protocol.txt
new file mode 100644 (file)
index 0000000..fcc75b3
--- /dev/null
@@ -0,0 +1,117 @@
+LTTng Live trace reading protocol
+Julien Desfossez
+September 18th, 2013
+This document describes the protocol of live trace reading. It is mainly
+intended for trace-viewer developers.
+Live trace reading allows a viewer to read safely a LTTng trace while it is
+being recorded. The protocol ensures that the viewer is never in a position
+where it can read for which it does not have the metadata, and also allows to
+viewer to know about inactive streams and skip those up to a certain point in
+This feature is implemented starting at lttng-tools 2.4
+* General informations
+All the data structures required to implement this protocole are provided in
+the lttng-viewer.h header. All integer are encoded in big endian during the
+Just like the streaming protocol, this protocol works always in only one
+direction : from the viewer to the relay. After each command, the relay sends a
+reply to the viewer (or closes the connection on fatal error).
+When the viewer sends a command to the relay, it sends a struct
+lttng_viewer_cmd which contains the command (enum lttcomm_relayd_command) and
+the size of the actual command if the command requires a payload.
+For example, if the viewer wants to list the sessions, it sends a struct
+lttng_viewer_cmd with :
+cmd = htobe32(VIEWER_CONNECT);
+data_size = htobe64(sizeof(struct lttng_viewer_connect));
+The cmd_version is currently unused, but might get useful when we extend the
+protocol later.
+* Protocol sequence
+In this section, we describe the normal sequence of event during a live-reading
+session. The viewer is abbreviated V and the relay R for conciseness.
+Establishing a connection :
+- V connects to R on port TCP/5344
+- V establishes a session by sending a VIEWER_CONNECT command, payload in
+  struct lttng_viewer_connect. In this struct, it sets its major and minor
+  version of the protocol it implements, and the type of connection it wants,
+  for now only VIEWER_CLIENT_COMMAND is supported.
+- If the protocol implemented by V and R are compatible, R sends back the same
+  struct with its own version and the newly assigned viewer_session_id.
+  Protocols are compatible if they have the same major number. At this point,
+  if the communication continues and the minor are not the same, it is implied
+  that the two processes will use the min(minor) of the protocol during this
+  connection. Protocol versions follow lttng-tools version, so if R implements
+  the 2.5 protocol and V implements the 2.4 protocol, R will use the 2.4
+  protocol for this connection.
+List the sessions :
+Once V and R agree on a protocol, V can start interacting with R. The first
+thing to do is list the sessions currently active on R.
+- V sends the command VIEWER_LIST_SESSIONS with no payload (data_size ignored)
+- R sends back a struct lttng_viewer_list_sessions which contains the number of
+  sessions to receive, and then for each session (sessions_count), it sends a
+  struct lttng_viewer_session
+- V must first receive the struct lttng_viewer_list_sessions and then receive
+  all the lttng_viewer_session structs. The live_timer corresponds to the value
+  set by the user who created the tracing session, if it is 0, the session
+  cannot be read in live. This timer in microseconds is the minimum rate at
+  which R receives information about the running session. The "clients" field
+  contains the number of connected clients to this session, for now only one
+  client at a time can attach to session.
+Attach to a session :
+Now V can select a session and attach to it. In order to do so, it sends the
+command VIEWER_ATTACH_SESSION with the session_id it wants. The "seek"
+parameter allows the viewer to attach to a session from its beginning (it will
+receive all trace data still on the relayd) or from now (data will be available
+to read starting at the next packet received on the relay). Only one session
+can be established by connection. Lots of clock synchronisation issues can
+happen when connecting to multiple sessions from multiple hosts at the same
+time, we let the viewers have fun with it ;-)
+R replies with a struct lttng_viewer_attach_session_response with a status and
+the number of streams currently active in this session. Then, for each stream,
+it sends a struct lttng_viewer_stream. Just like with the session list, V must
+receive the first header and then all the stream structs. The ctf_trace_id
+parameter in the struct lttng_viewer_stream is particularly important since it
+allows the viewer to match all the streams belonging to the same CTF trace (so
+one metadata file and multiple stream files). If the stream is a metadata
+stream, metadata_flag will be set to 1.
+#### below needs to be well written, but the essential is here ###
+Get metadata :
+A CTF trace cannot be read without the complete metadata.
+Send the command VIEWER_GET_METADATA and the struct lttng_viewer_get_metadata.
+Once we have all the metadata, we can start processing the trace. In order to
+do that, we work with the indexes. Whenever we need to read a new packet from a
+stream, we first ask for the next index for this stream and then ask for a
+trace packet at a certain offset and length.
+Get the next index :
+struct lttng_viewer_get_next_index
+Receive back a struct lttng_viewer_index 
+Get data packet :
+struct lttng_viewer_get_packet
+Receive back a struct lttng_viewer_trace_packet
+For the VIEWER_GET_NEXT_INDEX and VIEWER_GET_PACKET, the viewer must check the
+"flags" element of the struct it receives, because it contains important
+information such as the information that new metadata must be received before
+being able to receive and read the next packet.
+When new metadata is added during a session, the GET_NEXT_INDEX will succeed
+but it will have the flag LTTNG_VIEWER_FLAG_NEW_METADATA, but the
+GET_DATA_PACKET will fail with the same flag as long as the metadata is not
This page took 0.040904 seconds and 4 git commands to generate.