anchor.diff:  <3> get_streams function is mandatory 
   <4> Each Traffic profile module should have a `register` function
   
  -
  -*Start TRex as a server*::   
  -
   [NOTE] 
   =====================================================================
  -There is no need to install any python packages (including scapy). just download the TRex package
  +The SRC/DST MAC addrees are taken from /etc/trex_cfg.yaml. if you want to change them to be different just add Ether(dst="00:00:dd:dd:00:01") with your destination
  +=====================================================================
  +
  +
  +*Start TRex as a server*::   
  +
  +[NOTE] 
  +=====================================================================
  +There is no need to install any python packages (including scapy). The TRex package includes all the packages it requires 
   =====================================================================
   
   
  
positive.code:  dashboard:  'p' - pause, 'c' - clear, '-' - low 5%, '+' - up 5%, 
  ----
  
  [NOTE] 
  =====================================================================
  The SRC/DST MAC addrees are taken from /etc/trex_cfg.yaml. if you want to change them to be different just add Ether(dst="00:00:dd:dd:00:01") with your destination
  =====================================================================
  
  ==== Tutorial: Connect from a remote server 
  
  *Goal*:: Console connect from a remote machine to TRex server 
  
  *Check that TRex server is up*::
  
  Make sure TRex server is running, if not run trex in interactive mode
  
  [source,bash]
  ----
  
negative.code: 
  * 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 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
  * 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.
  * 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"]
  
  