Finite State Machine based Flow Analysis for

WebRTC Applications
Sergej Alekseev

Christian von Harscher

Marco Schindler

Fachhochschule Frankfurt am Main

University of Applied Sciences
Nibelungenplatz 1
60318 Frankfurt am Main, Germany
email: alekseev@fb2.fh-frankfurt.de

Fachhochschule Frankfurt am Main

University of Applied Sciences
Nibelungenplatz 1
60318 Frankfurt am Main, Germany
email: harscher@stud.fh-frankfurt.de

Fachhochschule Frankfurt am Main

University of Applied Sciences
Nibelungenplatz 1
60318 Frankfurt am Main, Germany
email: mschindl@stud.fh-frankfurt.de

open source project. We present some experimental results and

statistics based on this implementation at the end of the paper.

AbstractThis paper presents an approach for analysing the

behaviour of WebRTC - based applications, typically being used
for direct audio or video browser-to-browser communication.
The approach is based on finite-state machines derived from
the WebRTC specification. A state change of a WebRTC peer
involved in the communication process generates an event which
is collected and analysed. We present algorithms for analysing
the collected events and generating various statistics about a
WebRTC session. Finally we present some experimental results
based on the library named WebRTCStateAnalyser. This self-made
library is an open source project which is available under the
Apache License.
Index TermsWebRTC, Finite State Machine, Pattern Matching

II. R ELATED W ORKS

The idea to use finite-state machines for modelling the
network protocols and distributed systems is known for a
long time. Communication protocols are often modelled as
a network of two finite-state machines that communicate by
exchanging over unbounded channels [3], [4], [5]. There are
a lot of publications dealing with finite-state model based
tests [6], [7] which are partially related to our approach. Very
close to our approach are publications for diagnostics and
fault localisation problems based on finite-state machines [8],
[9]. Some recent publications are [10] and [11]. However, our
approach has its focus on collecting and examining statistics
for WebRTC based applications.
The second algorithm (Event Sequence Pattern Matching)
in this paper uses the structural comparison to recognize an
event sequence. There are a lot of known algorithms for text
pattern matching. The Boyer-Moore [18], Quick-search [19] or
Horspool [20] algorithms and their variants are widely used in
the software industry. They are in general close to our algorithms, but not suitable to perform the structural comparison.
For our approach, we adapted the path profiling algorithm
published by Ball and Larus [17], originally developed for
program profiling. The essential idea behind the algorithm is
to identify sets of potential event sequences which are encoded
as integer values. The comparison costs are thereby reduced
to a minimum. The costs are limited to the calculating of an
integer value for an event sequence to be analysed.

I. I NTRODUCTION
WebRTC (Web Real Time Communication) is a communication standard developed by the W3C [1] in close cooperation with the RTCWeb standard developed by the IETF
[2]. WebRTC offers developers the ability to create web
multimedia applications for real time communication without
plugins, downloads or installations. In this paper we present
an approach which allows to represent the state of a WebRTC
based application by collecting and analysing the state events.
The field of application could be e.g. error handling, collecting
statistics, detection of fraud attempts or analysis of user
behaviour.
The main idea of the proposed approach is to collect events
generated by WebRTC peers when a change of a state occurs.
For modelling the possible WebRTC states and flows we derive
the finite-state machines from the WebRTC specification [1].
The state change events are generated asynchronously by
WebRTC peers and this process does not have any influence on
the overlaying application. The collected events are validated
by the proposed algorithm to detect illegal state changes
according to the WebRTC specification [1]. The second algorithm recognizes the predefined sequences of event state
changes to create various statistics.
To evaluate our approach, the open source library WebRTCStateAnalyserhas been implemented and tested with various
WebRTC applications. The implemented library may be easily
integrated into any WebRTC application and is available as an

978-1-4799-4233-6/14/$31.00 2014 IEEE

III. W EB RTC F INITE S TATE M ACHINES

Finite-state machine (also called a finite-state automaton)
provides a simple computational model for modelling software
systems. A finite-state machine (FSM) is defined formally as
a 3-Tuple, (V, , E) consisting of a finite set of states V , a
finite set of input symbols and a transition function E :
V V . A FSM is usually represented as a directed
graph G = (V, E), where V is a set of nodes and E is a
set of edges. The finite set of input symbols (corresponding
actions) is assigned to the edges of the Graph.

have-remote-pranswer
have-local-offer

!
g
a
b !
b
g
!

stable
closed

! g
g
e
d
d
!

!
have-remote-offer have-local-pranswer

e
f

We derive from the WebRTC specification [1] following

finite-state machines:
Signaling state machine S = (Vs , Es ) (section III-A).
Gathering state machine G = (Vg , Eg ) (section III-B).
Connection state machine C = (Vc , Ec ) (section III-C).
The specification defines the set of states for each finite state
machine as an enum structure. The sets of transitions (edges)
are derived from the methods or event handlers.
Zs = (s, g, c)

(1)

The state of the entire system Zs is defined by the equation

1, where s Vs , g Vg and c Vc .
When the WebRTC peer within a browser has been created
[1], it has a signaling state, an ICE gathering state [14],
and an ICE connection state [14]. The WebRTC peer has
two associated stream sets: a local streams set, representing
streams that are currently sent, and a remote streams set,
representing streams that are currently received. Once the
WebRTC peer has been initialised the methods createOffer,
setLocalDescription, createAnswer and setRemoteDescription
are executed to initialise the connection. The following steps
are performed:
The WebRTC peer starts gathering ICE addresses and sets
the ICE gathering state to gathering.
If one or more candidate pairs have been found the ICE
connection state is changed to connected.
When the WebRTC peer finishes checking of all candidate
pairs the ICE connection state is changed to completed.
If the ICE connection state is connected or completed
and both the local and remote session descriptions have
received a valid SDP offer / answer pair, the ICE connection state is set to stable.
The next subsections describe the formalisation of the
signaling, gathering and connection state machines.

Fig. 2.

Signaling state machine.

the close method (fig. 2: transition g) the connection is closed

and the state is changed to closed. Further transitions are:
setRemoteDescription(pranswer) (fig. 2: transition c)
setLocalDescription(answer) (fig. 2: transition d)
setRemoteDescription(offer) (fig. 2: transition e)
setRemoteDescription(pranswer) (fig. 2: transition f)
The type pranswer indicates that a description should be
treated as a non final answer.
B. Gathering state machine
The gathering state definitions from [1] are represented in
fig. 3. The state new represents the state of the WebRTC
enum RTCIceGatheringState {
"new",
"gathering",
"complete"
};
Fig. 3.

A. Signaling state machine

Gathering states

peer before any networking actions have been executed. The

transition from the state new to the state gathering is executed
if the WebRTC peer starts the process of gathering candidates
to setup a connection. The WebRTC peer changes the state to

To model the signaling state machine the following state

definitions (fig. 1) from [1] are used. The corresponding
enum RTCSignalingState {
"stable",
"have-local-offer",
"have-remote-offer",
"have-local-pranswer",
"have-remote-pranswer",
"closed"
};
Fig. 1.

new

gathering

complete

Fig. 4.

Signaling states and transitions

Gathering state machine.

complete if it has completed gathering. Events such as adding

a new interface will cause the state to go back to gathering.
The corresponding gathering state machine G is shown in fig.
4.

signaling state machine S is represented in fig. 2.

The state stable is the initial state in which case the local
and remote descriptions are empty and there is no offer/answer
exchange in progress. The execution of methods createOffer
and setLocalDescription will cause the state change from
stable to have-local-offer (fig. 2: transition a ). The methods
createAnswer and setRemoteDescription will change the state
from have-local-offer to stable (fig. 2: transition b). By calling

C. Connection state machine

The state definitions of the connection state machine from
[1] are represented in fig. 5. The corresponding connection

enum RTCIceConnectionState {
"new",
"checking",
"connected",
"completed",
"failed",
"disconnected",
"closed"
};
Fig. 5.

Definition of connection states.

state machine C is presented in fig. 6. The state new represents the state in which a WebRTC peer waits until the
gathering process is completed and all connection candidates
are determined. The state new changes to state checking if the

Fig. 7.

a
c
d

new checking connected completed

b
!g

g
c
d

!
a a

WebRTC call state analyser

closed

g!
g
g

failed

Fig. 6.

An event is defined by a unique id, peer id pid, session

id sid, timestamp t and the state of the entire system Zs
according to the equation 1. In the tuple notation an event
can be formalised as:

!
f disconnected !

e = (id, pid, sid, t, Zs ),

(2)

where the state Zs is an element of the combination of

signaling, gathering and connection states Zs V sV g V c
as described in the section III. The sequences of events are
programmatically derived from the collected raw events. A
sequence of events Q is defined as an ordered set of elements:

Connection state machine.

WebRTC peer received the remote candidates and is able to

check candidate pairs (fig. 6: transition b). The state connected
is reached after the gathering process is fully completed and a
connection for at least one component has been found (fig. 6
transition c). The state completed is reached after the WebRTC
peer has determined connections for all components (fig. 6:
transition d).
If the WebRTC peer is not able to determine any connections
then the state checking changes to the state failed (fig. 6:
transition e). The state disconnected is reached if the established connection is lost for one or more components (fig. 6:
transition f ).
The state closed is reached from any states when the
WebRTC peer is shut down (fig. 6: transition g). Restart of
the WebRTC peer causes that the model changes back to the
state new from any state (fig. 6: transition g).

Q = {. . . , en , en+1 , . . .}, en , en+1 Q :

sidn = sidn+1 tn < tn+1

(3)

All events in the sequence Q belong to the same session and

are sorted in topological order by the time stamp. The session
id is created at the start of the session. All peers involved into
the same communication process have the same session id. An
example of an event sequence is presented in fig. 8.
V. A NALYSING W EB RTC E VENTS
The analysis of the collected WebRTC events is realized in
two steps. In the first step the sequence of events is validated
for each particular peer that is involved in the communication
process (subsection V-A). In the second step application specific patterns are recognised by the pattern matching algorithm
(subsection V-B).

IV. C OLLECTING W EB RTC E VENTS

A. Validation Algorithm

During the communication process WebRTC peers generate

events asynchronously when the state of a peer has been
changed. The idea of the WebRTC event based state analyser
framework is to implement event handlers which log these
events, store them in a database and then analyse and validate
these events algorithmically. The fig. 7 shows the architecture
of the WebRTC event based state analyser framework. The
event handler interface [1] represents a callback method and
event types as defined in [15]. The integration of the event
handler interface is realised by including the javascript on the
HTML page of the WebRTC application. The code modification of the WebRTC application is not necessary.

The sequence of events Q is divided into subsets of events

P [ ] corresponding to each peer as follows:
Q=

n
[

Pi , pn , pn+1 P : pidn = pidn+1

(4)

i=1

The subset of events P includes events generated by a single

peer and sorted in topological order by the time stamp.
pn , pn+1 P : tn < tn+1

(5)

In fig. 8 we have the first subset P1 with the ids {23,

25, 28, 33, 35, 37, 44} and subset P2 = {24, 26, 27,

id
23
24
25
26
27
28
33
34
35
36
37
38
44
45

pid
0x01
0x02
0x01
0x02
0x02
0x01
0x01
0x02
0x01
0x02
0x01
0x02
0x01
0x02

sid
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d
0x421ff0d

time stamp
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014
03-19-2014

13:27:18.276
13:27:18.345
13:27:18.678
13:27:18.701
13:27:18.723
13:27:19.755
13:27:20.765
13:27:20.821
13:27:20.987
13:27:20.998
13:27:21.067
13:27:22.126
13:27:32.567
13:27:33.663
Fig. 8.

state = { Vs, Vg, Vc }

{ stable,
new,
{ stable,
new,
{ have-local-offer, new,
{ have-remote-offer, new,
{ have-remote-offer, gathering,
{ have-local-offer, gathering,
{ stable,
complete,
{ stable,
complete,
{ stable,
complete,
{ stable,
complete,
{ stable,
complete,
{ stable,
complete,
{ closed,
complete,
{ closed,
complete,

new
new
new
new
new
new
new
new
checking
checking
connected
connected
closed
closed

}
}
}
}
}
}
}
}
}
}
}
}
}
}

Raw Events example

34, 36, 38, 45}. The validation is executed for each subset 1) or invalid (value = 0). The valid combination of states is
P the procedure V ALIDAT E EV EN T SEQU EN CE to ...
validate the sequence of signaling, gathering and connection [stable],
[new],
[new]
=1
=1
states. Additionally the combination of states for each event [have-local-offer], [gathering], [new]
[have-local-offer], [new],
[closed] =0
is validated by the combination validation algorithm.
[gathering], [new]
=0
1) Validating states for a single peer : The following [closed],
...
algorithm demonstrates the validation of events generated by a
Fig. 10. An excerpt from the combination matrix.
particular peer. The method otherend() returns the other state
connected to the given transition and state.
derived from the [1]. I.e. all the events from fig. 8 are valid.

The verification step is to find the appropriate combination and

VALIDATE EVENT SEQUENCE( Q, F SM )
to read the corresponding value from the matrix. The runtime
1 last = NULL;
complexity of this step is O(|Q|) and depends only on the
2 for ( each e Q in topological order ){
number of stored events, because the size of the matrix is
3
if ( last != NULL ){
constant.
4
if (! FIND STATE ( F SM , e.state, last ) ) {
B. Event Sequence Pattern Matching Algorithm
5
return false;
6
} }
Pattern-matching is routinely used in various computer
7
last = e.state
applications, for example, in editors, retrieval of information
8 }
(from text, image, or sound). The proposed matching algorithm
9 return true;
matches the sequence of events with a set of predefined
FIND STATE( F SM , state, last )
patterns. Each sequence pattern consists of three event state se1 for (each incoming edge of state F SM ) {
quences Qs , the sequence of signaling states, Qg , the sequence
2
if( otherend(edge, state) == last ){
of gathering states, and Qc , the sequence of connection states.
3
return true;
Some typical patterns of WebRTC events are presented in the
4 } }
following list:
5 return false;
Successful session:

Fig. 9.

Qs = { have-local-offer stable closed }

Qg = { new gathering complete }

Algorithm for validating states for a single peer

Qc = { new checking connected completed closed }

The
runtime
complexity
of
the
procedure
V ALIDAT E EV EN T SEQU EN CE is O(|Q||E|),
where |Q| is the number of processed events and |E| the
number of edges (transitions) of the relevant finite state
machine. Since the number of transition in all machines
is constant, the runtime complexity is O(|Q|). I.e. the two
sequences P1 and P2 from fig. 8 are valid.
2) Validating combination of states: To validate the combination of states for single events, we created a static three
dimensional matrix (fig. 10) representing all combinations of
signaling, gathering and connection states. The values of the
matrix defines if the combination of states is valid (value =

Session failed:
Qs = { have-local-offer closed }
Qg = { new gathering }
Qc = { new checking failed closed }

The direct way to match the pattern is to compare the sequence

of events and the pattern in the forward direction element by
element. This process is repeated for each predefined pattern
until a pattern is matched or not matched. This approach is
commonly known as a brute-force method.
The proposed algorithm is based on structured comparison
and allows to minimise the number of calculation steps. The

checking 6 connected 4 completed

new
essential idea behind the algorithm is to identify sets of

potential paths with states which are encoded as integers. For

2
1
1
2
2

this purpose the path profiling algorithm ASSIGN LABELS

2
disconnected
failed
from Ball and Larus [17], originally developed for program

1
profiling (fig. 11), is used. The path profiling algorithm works

1
1

efficiently for directed acyclic graphs (DAG). Therefore, the

1
closed

finite state machine has to be transformed into a DAG (fig.

0
12: line 1). The Ball-Larus algorithm labels edges in a DAG
0
0
0
0
with integer values, such that each path from the entry to the
EXIT
0
0

exit of the DAG produces a unique sum of the assigned edge

values along that path (fig. 12: line 2). Each sequence pattern Fig. 13. Transformed Connection FSM with values computed by the
algorithm ASSIGN LABELS in fig. 11.

ASSIGN LABELS( F SM )
V al(new EXIT )
=0
V al(new closed EXIT )
=1+0=1
1 for ( each vertex v V in reverse topological order ){
V al(new checking EXIT )
=2+0=2
2
if ( v is a leaf vertex ){
V al(new checking closed EXIT ) = 2 + 1 + 0 = 3
3
NumPaths(v) = 1;
V al(new checking f ailed EXIT ) = 2 + 2 + 0 = 4
...
4 } else {
V al(new checking connected . . .)
= 2 + 6 . . . = 15
5
NumPaths(v) = 0;
6
for( each edge e = v w) {
7
Val(e) = NumPaths(v);
number of possible paths (sequence patterns) is calculated as:
8
NumPaths(v) = NumPaths(v) + NumPaths(w);
16 3 17 = 816.
9 } } }
2) Calculating path value for an event sequence: The path

value of an event sequence is calculated by following the

Fig. 11. Ball-Larus-Algorithm for assigning values to edges in a DAG [17].
corresponding transition and adding the assigned values to the
path value.
is represented by an integer value as a sum of three paths:
Because the FSMs have been transformed to a DAG, the
V al(Qs ) + V al(Qg ) << 2 + V al(Qc ) << 4
(6)
cycles have to be removed from the sequence. This limitation
The calculated values are stored in an index table.
may cause the situation that two different sequence patterns are

reduced to the same template. This limitation is nevertheless

/* T is an index table of event sequence patterns */
acceptable, because there are only a few use cases where this
SEQ PATTERN MATCH(Q, F SM , T )
situation may occur.
1 val = calculateP athV alue(D, Q);
2 p = getP atternF romIndexT able(val, T );
VI. E XPERIMENTAL E VALUATIONS AND A NALYSIS
3 return p;

To evaluate the proposed algorithm we compared the runtime of the brute-force method (BFM) against the runtime
Fig. 12. Sequence Pattern Matching Algorithm
of the Event Sequence Pattern Matching (ESPM) algorithm.
The event sequence to be recognised is interpreted by the The input is an event sequence as defined in the equation
finite state machine. The path value is calculated as a sum 2 and a set of templates. A template is an event sequence
of the transition values (fig. 12: line 3) and the correspond- which is identified as a specific scenario for an use case (e.g.
ing pattern is determined from an index table by using the successful, failed or canceled session). The maximum possible
number of templates is 816 as calculated in section V-B. The
calculated integer value (fig. 12: line 4).
1) Representing event sequences with sums: The connec- realistic number of templates in a real application will be
tion finite state machine C (subsection III-C) is transformed approximately between 10 to 20. The algorithms have been
R and the tests have been executed on
into a DAG as presented in fig. 13. The transformation is done implemented in Java
R 3.4 GHz processor and 8GB of
by removing the back edges and adding the dummy edge EXIT a computer with an Intel
to derive correct paths for sequences that terminate before RAM.
We implemented two tests to evaluate the runtime. In the
reaching the end state.
The algorithm ASSIGN LABELS (fig. 11) calculates first test we executed the BFM and ESPM algorithms with
and assigns values, so each sequence path of 16 possible paths an event sequence including five events and various number
of templates as input. The table I reports the runtime results
is represented by an integer value as follows:
For the gathering finite state machine the algorithm and the diagram (fig. 14) represents the results graphically.
ASSIGN LABELS (fig. 11) calculates and assigns values To generate more representative results 1000 iterations per test
of three possible paths and for the signaling finite-state ma- have been executed. It is not surprisingly, that the runtime of
chine S the values of 17 possible paths. So the maximum the ESPM algorithms stays constant, because it depends on

TABLE I
RUNTIMES IN s DEPENDING ON THE NUMBER OF TEMPLATES .
# templates

BFM
s

ESPM
s

# templates

BFM
s

ESPM
s

5
20
50

620
1210
1815

364
391
368

150
400
816

2456
2896
4032

359
365
361

VII. C ONCLUSION
This paper describes a new approach for analysing the
behaviour of WebRTC-based applications. We presented an
algorithm for validating the collected events which may be
used e.g. to identify implementation errors in a WebRTC-based
application. We also presented an algorithm for recognition
the event sequences which can be used for generating various
monitoring records about a WebRTC session. Finally we presented some experimental results including the comparison of
the runtime of the new algorithm and the brute-force method.
The results show that the proposed approach and presented
algorithms are suitable to be implemented in all applications
related to the event based analysis.
Our further interests are focused for collecting statistics
from the real WebRTC-based applications, developing new
algorithms for identifying the event sequences containing
loops and creating a concept of a self learning system for
event sequence recognition.

time in s

4,000
3,000
2,000
1,000
0
5

20

50

150

400

816

# templates
BFM
ESPM
Fig. 14.

Visualization of the results the table I.

R EFERENCES
[1] Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan,
WebRTC 1.0: Real-time Communication Between Browsers, Draft 30,
August 2013 http://dev.w3.org/2011/webrtc/editor/webrtc.html
[2] H. Alvestrand, Real Time Protocols for Brower-based Applications, IETF,
Draft 09, Feb. 2014 http://tools.ietf.org/html/draft-ietf-rtcweb-overview-09
[3] A. Danthine, Protocol Representation with Finite State Machines, IEEE
Transactions on Communications, Vol. 28, No. 4, 1980, pp. 632-643
[4] D. Brand, P. Zafiropulo, On Communicating Finite-State Machines, J.
ACM, Vol. 30, No. 2, April 1983, pp. 323-342
[5] Sunshine, C., Formal Modeling of Communication Protocols, in Proc.
Conference on Communication in Distributed Data Processing Systems,
Technical University Berlin, January 1981.
[6] T. S. Chow, Testing Design Modelled by Finite-State Machines, IEEE
Trans. S.E. 4, 3, 1978.
[7] S. Fujiwara, G.v. Bochmann, F. Khendek, M. Amalou, A. Ghedamsi,
Test selection based on finite state models, IEEE Trans. on Software
Engineering, Vol. 17, No. 6, June 1991, pp. 591-603.
[8] A. Ghedamsi, G.v. Bochmann, Test result analysis and diagnostics for
finite state machines, The 12-th international conference on distributed
systems, Yokohama, Japan, June 9-12, 1992
[9] B. Korel, PELAS-Program error-locating assistant system, IEEE Trans.
on Software Engineering, Vol. 14, No. 9, September 1988
[10] W. Grieskamp, Y. Gurevich, W. Schulte, M. Veanes, Generating finite
state machines from abstract state machines, Proceedings of the ACM
SIGSOFT Symposium on Software Testing and Analysis, 2002, pp. 112ff
[11] R. M. Hierons, Canonical finite state machines for distributed systems,
Theoretical Computer Science, 2010, pp. 566-580.
[12] H. Alvestrand, Google release of WebRTC source code, publicwebrtc@w3.org, 1. Juni 2011
[13] F. A. Scherschel, Google proposes VP8 and Opus for WebRTC standard,
The H Open, 31. Juli 2012
[14] J. Rosenberg, Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer
Protocols, RFC5245, April 2010 http://www.ietf.org/rfc/rfc5245.txt
[15] R. Berjon, S. Faulkner, T. Leithead, E. D. Navara, E. OConnor; S.
Pfeiffer, HTML5 - A vocabulary and associated APIs for HTML and
XHTML, W3C , 04 February 2014 http://www.w3.org/TR/html5
[16] M. Handley, V. Jacobson, SDP: Session Description Protocol, RFC2327,
April 1998 http://www.ietf.org/rfc/rfc2327.txt
[17] T. Ball, J. R. Larus, Efficient Path Profiling, Proceedings of the 29th
annual ACM/IEEE international symposium on Microarchitecture, 1996
[18] R. S. Boyer, J. S. Moore, A fast string searching algorithm, Communications of the ACM 20, 1977, pp. 762- 772
[19] D. Knuth, J. Morris, V. Pratt, Fast pattern matching in strings, SIAM
Journal on Computing, Vol 6(1), 1977, pp. 323-350
[20] R. N. Horspool, Practical fast searching in strings, Software-Practice
Experience , Vol 10(6), 1980, pp. 501-506.

the length of the sequence to be analysed. The runtime of the

BFM grows with the increasing number of templates.
In the second test the input includes the constant number of
templates and event sequences with various number of events.
The test results and graphical visualization are presented in the
table II and the diagram (fig. 15).
The result is consistent

time in s

TABLE II
RUNTIMES IN s DEPENDING ON THE LENGTH OF THE SEQUENCE .
# events

ESPM
s

PMA
s

# events

BFM
s

ESPM
s

1
3
5

998
1412
1834

181
356
611

7
9
11

2019
2102
2184

829
856
888

11

2,000
1,000
1

# events
BMF
ESPM
Fig. 15.

Visualization of the results from the tabable II.

with the theoretical expectation that the runtime grows by

increasing the length of the sequence. It is interesting to note
that the total time taken by the proposed ESPM algorithm
is always less than the time of the BFM. The reason for
that is the different overhead of comparison and calculation
operations used in the implementation. The runtime increase
curve of both algorithms shows the linear character and stays
absolutely in limit.