The UPnP control point:
CP Running Communication System
Since the CP has an HTTP Server running during the UPnP operations, the simplest way to pass messages is a socket mechanism on a multi-thread process. The remote control handler, in fact, chooses a port number (9999) and the CP IPv4 in order to use a server address structure and binds a socket. Once binding is complete, the CP listens to the incoming connections on that socket and, each time a new connection is estabilished, creates a new thread for performing the requested "action". The object of class MyLauncher pass to pthread_create call is essentially made by a couple of references: one for the MyCtrlPoint object and the other for the received data. The method passed to the new thread is the only one defined in this new "empty" class; the launch() call return the call of the echo function in MyCtrlPoint. With this indirect mechanism, one method of the CP class can put in a new thread another (internal) method of the same class, and so pass the arguments to the new thread successfully. The echo function indirectly called "detached" the current thread and perform an action based only on the incoming message. The requested operation is performed when the command string matches the received string (or at least one substring).
On the other side, each time a new GET request is performed by the UI, the HTTP server (separated from the CP) launch a .cgi script that create a new instance of class usrCPHandler. This object, before sending back the response to the user side, perform the required instructions by opening the socket on the CP side and transmit a single message on the queue. Then, it waits until CP have done the elaboration and (in case of needs) provide some results/errors. Once the "acknowledge" is arrived from the control point remote handler, the user handler is free to output the webpage content (or the JSON object to "send back") before is destroyed by the end of the CGI script execution.