|
| Re: Server sessions [message #1758849 is a reply to message #1758831] |
Mon, 03 April 2017 18:49   |
|
AFAIK the main reason is that it is defined like that in Annex F of IEC 61499-1. However it is rather limiting and we see the need for improvements here. There is an paper from around 2005 from Valeriy Vyatkin where a potential solution for 2 clients per server is shown. But I think this is still to limiting.
Therefore I've started a proposal for the upcoming IEC 61499-5 to solve this issue. I would be happy to talk with you on this. Maybe better in a skype call.
|
|
|
| Re: Server sessions [message #1758878 is a reply to message #1758849] |
Tue, 04 April 2017 06:22 |
 Adrian Orive
Messages: 38
Registered: March 2017 |
Member |
|
|
I will try to get a better understanding of how it works first, as this knowledge could be neccesary to make the conversation more agile, but would be pleased to have a talk about it afterwards.
Edit: I haven't been able to found V. Vyatkin's article using "server" and his name as search terms in an specialized scholar index. Any other info about the article could help me finding it.
[Updated on: Tue, 04 April 2017 06:35] Report message to a moderator |
|
|
|
| Re: Server sessions [message #1758925 is a reply to message #1758911] |
Tue, 04 April 2017 16:13 |
|
I would say the standard text ist stil the best starting point. I searched a bit and I think this artikle [1] is the one where this concept is described. I would also be happy to exchange with you on the proposed extensions for part 5 how this could be handled better. I had some ideas where maybe a map is not needed. But for testing purposes I think it is perfektly fine to start a new layer which uses a map or hash table and when the final implmentation is set we can still think how to replace STL.
[1] http://ieeexplore.ieee.org/document/1417412/
|
|
|
|
| Re: Server sessions [message #1759011 is a reply to message #1758996] |
Wed, 05 April 2017 09:04 |
|
|
I'm also not a big fan of the proposed solution. However as you asked this is the only publiication on this topic sofar. In the other side I'm also not so sure how much effort in improving the server FB's behavior on plain TCP makes sense. Espcially as now new protocols for industrial automation are emerging where the protocol or the stack would handle als this transaction behavior and the server or client does not need to know about it. For example, we achieved first good results with OPC UA. We are currently working on writing up some article on our concepts and results. But this will take some time.
|
|
|
|
| Re: Server sessions [message #1759068 is a reply to message #1759032] |
Wed, 05 April 2017 19:39 |
|
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.
|
|
|
| Re: Server sessions [message #1759085 is a reply to message #1759068] |
Thu, 06 April 2017 06:58 |
Adrian Orive
Messages: 38
Registered: March 2017 |
Member |
|
|
Alois Zoitl wrote on Wed, 05 April 2017 19:39I 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.
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.
Alois Zoitl wrote on Wed, 05 April 2017 19:39In 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.
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?
Alois Zoitl wrote on Wed, 05 April 2017 19:39In 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.
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.
|
|
|
| Re: Server sessions [message #1759140 is a reply to message #1759085] |
Thu, 06 April 2017 12:18 |
|
Adrian Orive wrote on Thu, 06 April 2017 06:58
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.
Youe are right and that is the reason for my proposal. But it would require some significant rework of all the layers.
Adrian Orive wrote on Thu, 06 April 2017 06:58
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?
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.
Adrian Orive wrote on Thu, 06 April 2017 06:58By 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 I meant the information model accessible via the address space. OPC Foundation has just recently finally published the first version of the PUB/SUB spec. Currently we don't have an OPC UA stack already implementing this spec available. But when we definitly would also like to support this in 4diac. From a first guess I would say that either it will be a special layer or that the OPC UA layer will get new parameters.
|
|
|
| Re: Server sessions [message #1759157 is a reply to message #1759140] |
Thu, 06 April 2017 22:59 |
Adrian Orive
Messages: 38
Registered: March 2017 |
Member |
|
|
Alois Zoitl wrote on Thu, 06 April 2017 12:18Yes 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.
To obtain the maximum throughput, the optimal design would be to reduce as much as posible the tasks of the bottle neck part. In this case, as a single thread would be handling every incoming communication as the TCP/UDP layer does right now, the quickest this thread can store the item in a queue and get ready to process another one the more messages that the application would be able to handle.
The processing of each message then could be slower than the speed at which they can get queued, specially if they are input/output bounded such as storing the value in a DB or executing a ramp up start for an actuator:
Imagine we have a device logging into a DB every alarm that occurs in a machine in order to be able to have a historic record of what went wrong. A single SERVER FB should be able to handle it easily as alarms should happen in sporadic situations (hopefully) and if there is a time interval when alarms are happening faster than what we can store them, a backlog will be stored in the queue, as after this rare multiple alarm interval happens there will be time for the single SERVER FB to handle all the enqueued messages.
Now lets say we want to store sensors data at a high frequency instead of alarms. If we start getting a backlog it will never get cleaned up as items will keep getting in until the queue is full and we start loosing data. Lets assume the bottle neck is never the DB, as this would be another problem out of 4diac scope. This is quite common in high throughput distributed DBs where the latency of a single operation is higher than the time required, so a single synchronous worker will not get to maximum thoughput. A monitoring application could be watching the queue size, and in case it gets to certain threshold, duplicate the storing application (SERVER FB and all the others FB required to store data) in order to get rid of the backlog, and maybe keep this duplicated application or just deleting it after a lower threshold is reached again.
With this example I try to demostrate how processing could be increased while the first thread that enqueues the messages can't, so it is the bottle neck, and thus should need the lowest time per operation.
Obviously this will depend on the HW characteristics but this is unavoidable. Bigger devices would be able to serve orders of magnitude more messages than constrained devices, the point is optimizing this bottle neck so that in any case it is working as close to its maximum performance.
Also worth note that my example would require a way for the runtime to monitorize itself, in this case the communication queue size. This is a feature that I think is needed, but it is a whole new topic as if I'm not mistaken, this can't be done right now.
[Updated on: Thu, 06 April 2017 23:04] Report message to a moderator |
|
|
| Re: Server sessions [message #1759347 is a reply to message #1759157] |
Mon, 10 April 2017 17:22 |
|
|
In principle we are already doing this. The only problem is that our queue size is one. But the inbound thread is just used for taking the mesage and putining it into memory from the layer using the recv method from the bottom layer. The processing of the data is then hand on to the worker thread of the resource. You can even implement different layers which will handle the incoming data differently (e.g., longer message queues, more processing on incoming thread, or more processing in worker thread). So yes it is needed and if you have many subscribers, servers, and clients the current implmentation is already according to your suggestions. If you have one of these FBs receiving a lot of messages then our implementation needs some furhter tuning.
|
|
|
|
| Re: Server sessions [message #1759383 is a reply to message #1759376] |
Mon, 10 April 2017 23:22 |
|
|
You can have several SUBSCRIBE FBs subscribing to the same address. This is not possible for SERVE FBs. At least not for the TCP. However I don't see the bottleneck in this use-case in the communication FBs but in the application. In such cases, I think it would be more appropriate to implement the load balancing on IEC 61499 application level. For example, you could use an E_CTU to count the IND events and based on the count value switch the execution flow with a MUX FB. The data outputs of the SUBSCRIBE or SERVER FB can then be wired in a fan out fashion directly to the processing FBS. FORTE has been designed to make fan outs of data connections very efficient. So that only one connection object is held in memory for all faned out connections.
|
|
|
Powered by
FUDForum. Page generated in 0.04005 seconds
] 
Search
Help
Register
Login
Home
