Microimpuls Smarty is a software for managing IPTV/OTT services. Smarty is a White Label platform using which an operator can create their own branded independent service with paid and free content.
Smarty consists of an application server (also known as Middleware), a portal for Set-Top Box, as well as applications for various Smart TV, mobile and media platforms.
In order to process and deliver content to customer devices, an operator can use additional solutions from Microimpuls (such as Microimpuls Spectr or MicroPVR) or third-party video servers (such as Flussonic or Astra and many others). Smarty is able to work with almost any third-party software and integrates well with various services.
Microimpuls Smarty Architecture
The diagram below shows the general architecture of the solution.
(1) Single Page Application. IPTV set-top box (also known as STB) and Smart TV users from various manufacturers interact with the IPTV/OTT service by installing an application or firmware through a visual interface implemented as a portal. Technically, this is a static one-page website that dynamically generates screen content and switches content depending on user actions (presses on the remote control buttons).
For Android set-top boxes and Android TVs we provide a separate application, which is a wrapper over the portal (it essentially contains a Webkit browser which loads the web portal just like the majority of Linux set-top boxes and Smart TVs).
(2) Web server (portal). The portal is hosted on a web server; we recommend using nginx to host it. Along with the portal installation package, an exa mple configuration for nginx is deployed on the server.
Nginx processes requests to static portal files (such as html, js, css and others) as simple reading of local files.
In large, highly loaded services, nginx also acts as an additional caching proxy (the main cache is stored in Redis), thereby reducing the load on the application server.
(3) The device browser downloads the portal via HTTP(S) from the web server. Keep in mind that some older devices might not be able to work with modern versions of SSL/TLS.
(4) The nginx server hosting the portal processes /api requests from applications and routes them to the application server through the uwsgi_path directive. If located on different hosts, interaction with the uWSGI server can be configured via tcp sockets instead of local sockets.
(5) Native. Regarding mobile devices and some other types, Microimpuls develops individually adapted native applications. Such applications have their own UI and do not use a web portal.
Just like the portal, these applications interact with the Smarty server through API requests, which are sent to the web server and then proxied to the uWSGI server.
(6) Web server (Smarty). We recommend using the nginx web server to proxy HTTP requests from applications to the application server as well and offer configuration examples.
In the diagram, entities (2) and (6) are depicted as separate blocks, since such separation is a convenient method of administration and separation of requests from applications. However, technically this can also be a common entry point, with a separately defined location in nginx.
(7) Application server. The application server is a uWSGI server with the Smarty service. This service ultimately processes all HTTP REST API requests that reach it, interacts with databases, carries out authentication and authorization, and performs calculations and information processing. The uWSGI server runs separate processes called uWSGI workers, each of which processes its own request per unit of time, calculates the result and returns the response to nginx, which in its turn returns the response to the application.
(8) In some distributed configurations, it is acceptable to specify an API address hosted on another host in the portal settings. In this case, only requests to load static portal resources will be made to the portal web server, and API requests will be made directly to the Smarty web server.
For example, this may be useful to host the portal on the device firmware (a so-called “fat client”), or on an external CDN resource.
With this configuration, it is crucial to correctly configure CORS policies so that the device browser does not block portal requests to a third-party domain.
(9) The web server interacts with the application server using the WSGI protocol and connects via a Unix socket if the uWSGI server and nginx are hosted on the same host (standard configuration). If hosted on a different host, TCP sockets are used to interact with uWSGI.
(10) Admin panel. After installation and basic setup, Smarty is configured via a web-based control panel. The logic of processing requests is similar to processing requests to the API. If necessary, using the location setting in nginx, access to the control panel can be limited or moved to a separate port and domain or to a separate host.
(11) Statistical data. Smarty uses MongoDB to store telemetry and other statistics. This is an additional service and can be configured if you need the functionality of saving TV viewing as well as various ratings and recommendations mechanisms.
(12) SQL database. Smarty uses a relational DBMS to store metadata. Interaction with the DBMS is carried out through the ORM mechanism. Supported DBMS: MySQL, Maria DB, Percona, PostgreSQL, Oracle. The DBMS is a necessary component of the system.
(13) Cache & Queue. The caching and cluster query execution system in Smarty is implemented on Redis. Redis is an essential component of the system.
(14) Smarty uWSGI workers interact with databases and cache servers via TCP sockets. The Redis server can be hosted locally together with the uWSGI server to save network bandwidth (standard configuration). We do not recommend hosting uWSGI and SQL/MongoDB servers locally on the same host; this option is only acceptable for start-up services with a customer base of up to 5,000 online users.
