.. index:: pair: class; NrpCoreServer
.. _doxid-class_nrp_core_server:

class NrpCoreServer
===================

.. toctree::
	:hidden:

	enum_NrpCoreServer_RequestType.rst

Overview
~~~~~~~~

NRP Server class, responsible for handling simulation control requests coming from the client application or script. :ref:`More...<details-class_nrp_core_server>`


.. ref-code-block:: cpp
	:class: doxyrest-overview-code-block

	#include <nrp_core_server.h>
	
	class NrpCoreServer: public Service {
	public:
		// enums
	
		enum :ref:`RequestType<doxid-class_nrp_core_server_1a5c39bb778ee26f83e26b2fb6a5d9794b>`;

		// construction
	
		:ref:`NrpCoreServer<doxid-class_nrp_core_server_1af8e387ff7924efbf98379c510622b5db>`(
			const std::string& address,
			std::shared_ptr<:ref:`SimulationManager<doxid-class_simulation_manager>`>&& manager
		);

		// methods
	
		void :ref:`runServerLoop<doxid-class_nrp_core_server_1a2b5b0efe31ea66c56c429051b6669ab0>`();
		void :ref:`stopServerLoop<doxid-class_nrp_core_server_1a1c8bfc65f087a21d5feecc2dd13f4d0f>`();
	};
.. _details-class_nrp_core_server:

Detailed Documentation
~~~~~~~~~~~~~~~~~~~~~~

NRP Server class, responsible for handling simulation control requests coming from the client application or script.

The class has two roles:

* receive simulation control requests from the client application

* relay received requests to the main thread of NRP Core and wait for response

The class is an instance of gRPC Service, which means that it will have a pool of worker threads. Every request coming from the client will be handled by a separate thread from the pool. The natural approach to request handling would be to call proper methods of the :ref:`SimulationManager <doxid-class_simulation_manager>` directly from the callbacks (for example, SimulationManager::initFTILoop() from NrpCoreServer::init()). This proved to cause problems with certain python libraries, like OpenCV, that may be used in the transceiver functions. The problem seems to arise from the fact, that the python code was executed in a worker thread, and not in the thread that spawned the python interpreter (the main thread of NRP Core). The solution is to create a producer-consumer relation between the NRP Server threads and the main thread. The NRP Server relays (produces) the requests to the main thread, which consumes them and returns a status back to the NRP Server.

Construction
------------

.. index:: pair: function; NrpCoreServer
.. _doxid-class_nrp_core_server_1af8e387ff7924efbf98379c510622b5db:

.. ref-code-block:: cpp
	:class: doxyrest-title-code-block

	NrpCoreServer(
		const std::string& address,
		std::shared_ptr<:ref:`SimulationManager<doxid-class_simulation_manager>`>&& manager
	)

Constructor. Spawns an instance of gRPC server with given address.



.. rubric:: Parameters:

.. list-table::
	:widths: 20 80

	*
		- address

		- Address of the gRPC server

	*
		- manager

		- :ref:`SimulationManager <doxid-class_simulation_manager>` which actually perform actions from requests

Methods
-------

.. index:: pair: function; runServerLoop
.. _doxid-class_nrp_core_server_1a2b5b0efe31ea66c56c429051b6669ab0:

.. ref-code-block:: cpp
	:class: doxyrest-title-code-block

	void runServerLoop()

Enters server loop in which requests are processed sequentially.

.. index:: pair: function; stopServerLoop
.. _doxid-class_nrp_core_server_1a1c8bfc65f087a21d5feecc2dd13f4d0f:

.. ref-code-block:: cpp
	:class: doxyrest-title-code-block

	void stopServerLoop()

Stops server loop.