I think there is a slight misunderstanding. with RSP the application would inform the communication layer that the last message recieved was processed by the application and if there are more messages pending the next message could be applied to the outputs and a new IND could be sent. Currently this is not forseen in the desing. In CComFB::receiveData all pending messages are handled at once and in principle the last message is applied to the outputs. Therefore a major redesign would be needed.

In principle we are handling already in a multi-threaded way. At least in a limited way. We have the thread with the select loop which is taking tha packet and will acitvate the FB in the thread of the resource the FB is loacted in. In this thread the messages is processed by the application and the answer is returned.

In OCP UA we are currently only supporting the UPC UA server side. Here we you are able to use PUBLSIH/SUSBRIBE to add write/read variables to the OPC UA information model and to use Server to over Methods which can be called by a client.

I understood it right, probably it was a poor explanation from my part. I was trying to say that the server would have to RSP either positive or negative every IND it receives so that a new IND from the queue could be processed. And then I tried to say what you just said, that right now every IND in the queue is being processed and the highest error code is being returned, which is actually a bit strange.

You are using 2 threads: one for feeding the queue and one for extracting from it. Right? I was talking about multi-threading extraction, so that a higher amount of events could be handed. This is a quite common approach when a single server has to serve multiple clients and the operation it does requires some computing time. This way there would be a single thread feeding the queue with every request it receives and a pool of workers handling them. This is probably not taken into account in IEC 61499, it just came to my mind when we talked about multi-client servers. This would require some not trivial things like: thread-safe queues, different FB bound to the same queue, etc.

And we could go even further, if we are able to monitor the size of this queue, we could make a FB application that deploys or deletes all the FBs required to handle each service, thus having a dynamic size of this worker pool. Was my explanation clear?

By information model you mean the Address Space? OPC-UA is planning to add or has recently added pub/sub paradigm support, so using the PUBLISH and SUBSCRIBE FBs to modify the Adress Space may require a different 4diac's layer to implement the pub/sub paradigm or modify the behaviour you mentioned.

Yes you made yourself clear. I'm not sure of the current modelling language means of IEC 61499 are apt to that task. But what is definitely a point is that we currently have only one thread which is handling all incoming tCP & UDP messages and forwards the data to x-threads for all resources (and if RT events FBs are involved even more). So the design question would in the end be how to move as much as processing from the receiving thread to the processing thread. But on the other side this requires not only threadsafe queues but also a lot of memory. Which may be a nissue on some devices.