Iotellect Protocol Communications

This section provides detailed information on how server-side and client-side implementations of Iotellect protocol work. Please note that server and client are logical roles in the connection that may match different scenarios:

  • In Iotellect Client or Iotellect Server API connection to Iotellect Server, Iotellect Server holds server role and Iotellect Client / API hold client role
  • In Agent to Iotellect Server connection, Agent holds server role while Iotellect Server holds client role
  • In a distributed architecture connection provider holds server role while consumer holds client role

Server-Side Implementation

The key class of Iotellect protocol connection server is some class inherited from DefaultClientController, such as an AgentImplementationController. This class is normally created from a controlling thread that was started upon accepting a new TCP connection, so this thread has access to a connection socket (encapsulated into BlockingChannel object).

Once the client controller is created, the controlling thread should start calling controller's run() method periodically. This method performs essential data handling logic:

  • First, it calls AggreGateCommandParser.readCommand() to read a fully defined Iotellect protocol unit from the socket. The parser's call may block until enough data is received or in case the system has not enough memory to handle any data injection.
  • If the parser has returned a complete IncomingAggreGateCommand, controller queues this command to the CommandQueueManager and submits a commands processing task to its ExecutorService. The task will be processed in a separate thread pool that was provided as an argument to client controller's constructor.

Every command processing task does the following:

  • Performs the requested operation (get/set variable, call function or subscribe/unsubscribe to events) and forms the OutgoingAggreGateCommand reply
  • Processes the pending events queue (if any events to that the current client subscribed were queued since the last command processing) and sends every event to the client side as a separate OutgoingAggreGateCommand
  • Sends the reply to the original command

Client-Side Implementation

The key class of Iotellect protocol client is a specific implementation of AbstractAggreGateDeviceController, such as RemoteServerController. The controller takes care about:

  • establishing TCP connection to the server, parsing incoming commands via a CommandParser and sending replies
  • implementing authorization (login) logic
  • maintaining a proxy context tree of remote server's contexts (represented by ProxyContext instances)
  • operating an AsyncCommandProcessor thread that performs reading and processing of incoming data

The async command processor is running until the server connection is alive. This thread performs the following cycle:

  • Using AggreGateCommandParser.readCommand() to read a fully defined Iotellect protocol unit from the socket
  • If the command is asynchronous (i.e. an event instance is received), it's processing task is immediately added to a separate event preprocessing thread pool (that is normally a single-thread pool)
  • If the command is synchronous, the command processor screens through its sent commands queue to find a previously sent command matching received server reply by command ID
  • Once the command is found, its ReplyMonitor is notified, which causes de-blocking of a thread that has initiated some synchronous server operation (get/set variable, call function or subscribe/unsubscribe events)

Proxy contexts of server controller's context tree ensure that all essential calls are forwarded to the server and block until a reply is received using the above mechanism.

Was this page helpful?