anchor.diff:  
   * The Control transport protocol is ZMQ working in REQ/RES mode
   * JSON-RPC2 is the RPC protocol on top of the ZMQ REQ/RES 
  -* Async transport is ZMQ working SUB/PUB mode. It is for async event such as interface change mode, counters etc.
  +* Async transport is ZMQ working SUB/PUB mode. It is for async events such as interface change mode, counters etc.
   * Python is the first Client to implement the Python automation API 
   * Console utilizes the Python API to implement a user interface to TRex
  -* Number of users can control one TRex server in parallel as long as they control different Interfaces. TRex Interface can be acquired by a user. For example a TRex with four ports can be used by two users. User A can acquire Interface  0/ 1 and User B can acquire Interface 3/4
  -* There could be only *one* control Console/GUI (R/W) entity for a specific user. User A with two interfaces could have only one R/W Control session in specific time. By that we can cache the TRex Server interface  information in the Client.
  -* For one user there could be many read-only clients for getting statistics.
  -* Client should sync with the server to get the state in connection time and cache the server information locally once the state was changed 
  +* Multiple users can control one TRex server in parallel as long as they control different Interfaces. Individuqal TRex Interfaces can be acquired by a user. For example, a TRex with four ports can be used by two users. User A can acquire Interfaces  0 & 1 and User B can acquire Interfaces 2 & 3.
  +* There can be only *one* control Console/GUI (R/W) entity for a specific user. User A with two interfaces can have only one R/W Control session active at a specific time. By that we can cache the TRex Server interface  information in the Client.
  +* For one user there can be many read-only clients for getting statistics.
  +* Client should sync with the server to get the state at connection time and cache the server information locally once the state was changed 
   * In case of crash/exit of the Client it should sync again at connection time.
  -* Client has the ability to get a statistic in real time (with ASYNC ZMQ). It gives the option to have number of ways to look into the statistics (GUI and Console) at the same time.
  +* The Client has the ability to get a statistic in real time (with ASYNC ZMQ). This provides the option to have multiple ways to look into the statistics (GUI and Console) at the same time.
   
   image::images/trex_stateless_multi_user.png[title="Multi user-per interface",align="left",width={p_width}, link="images/trex_stateless_multi_user.png"]
   
  
positive.code: # run the tests
  simple_burst()
  ----
  <1> import the stl_path. you should *fix* the path to point to your stl_trex library path 
  <2> import trex Stateless library. path should be fixed 
  <3> create packet per direction using Scapy
  <4> This is something more advanced will be explained later
  <5> Connect to local TRex   username , server can be added 
  <6> Acquire the ports  
  <7> load the profile and start the traffic 
  <8> Wait for the traffic to, be finished. There is a polling function so you can test do something while waiting 
  <9> Get port statistics
  <10> Disconnect
  
negative.code: 
  Python API examples are located here: `automation/trex_control_plane/stl/examples`.
  
  The Python API library is located here: `automation/trex_control_plane/stl/trex_stl_lib`.
  
  The TRex Console uses the python API library to interact with the TRex server using the JSON-RPC2 protocol over ZMQ.
  
  *file*:: link:{github_stl_examples_path}/stl_bi_dir_flows.py[stl_bi_dir_flows.py]
  
  