[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [4diac-dev] Confusion regarding communication architecture
|
Hi,
happy that I could help.
You found the week spot of our current implementation. This is also in the current version of the standard not very well defined. I developed an improvement
suggestion for the upcoming IEC 61499 revisions. You can have a look on it here [1] (please not that this link may not work anymore when the improvement is
finally added to the standard). Feedback to it is warmly welcome.
But in short what is the real problem: if you would do several event chain calls it can happen that the Comm FB allready overwrites the outputs even before the
application has read it. Therefore in IEC 61499 resource initiated SIFBs (e.g., server, subsribe) in addition to the IND output event we also have the RSP
event. With the RSP event the application can inform the FB that the data is processed. That means a new IND event should only be sent when the previous IND was
acknowledged by the application with an RSP. This is also the core of my standard text to clearly explain how resource initated SIFBs should be implemented.
The current 4diac FORTE implementation of CommFBs is older then this text and we sofar never had time update our implementation. Also it has a bit a problem
that it would mean that application behavior has to change (i.e., users need to trigger RSP after each IND).
In order to fix this I see the following steps:
- startNewEventChain may only be called when the first message is received
- on event processing (external event, RSP) only one element is taken from the interrupt queue
- if there is no element in the interrupt queue no output event is sent
- the comlayer need to buffer each message untill the right processInterrupt is called
I hope this helps.
BR,
Alois
[1] https://docs.google.com/document/d/1dnaqw-54umRLs3Yw8Rt8bPr5wpaSi8IgaHSq0ufSY_o/edit?usp=sharing
On Thu, 2022-04-21 at 00:39 +0200, Davor Cihlar wrote:
> Thank you very much for the detailed explanation!
> The thing that confused me the most was that I assumend interruptCommFB automatically interrupted the executor and started the event handling. That's
> obviously not the case.
> Today I dug deeper into Forte core (CCommFB and CCommLayer) which further explained how things work. And I also realized there is a plenty of Doxygen
> documentation hidden in the code so I generated it. :)
> But I didn't yet get very deep into startNewEventChain. The explanation that you gave me, along with the coding pattern will be extremely helpful in the
> upcoming parts of my project.
>
> I'm still very curious about the scenario when Handler/CommLayer need to generate multiple events at once. I.e. there were two requests, and server sent both
> responses in one frame. Or in more generic terms, a second response arrives even before the executor called the first processInterrupt. From what I've seen
> most (if not all) protocol implementations won't handle that properly.
> From what I gathered interruptCommFB can be called during processInterrupt, and by doing that it will be registered immediately for the next cycle. In theory
> that could be used to pop one by one response from an incoming queue. But I would need to be careful to prevent an asynchronous thread (the data source) from
> calling interruptCommFB until it is stopped from being called from processInterrupt. But what about startNewEventChain? Does it need to be called along with
> each next interruptCommFB (while the output queue is not empty)?
> Am I even going in the right direction? Should I ditch that idea and implement some other two way handshake with the handler (which has its own thread)?
>
>
> On 4/20/22 21:53, Alois Zoitl wrote:
>
> > Hi Davor,
> >
> > the part with the startNewEventChain (yes the name changed) is one of the more complicated and also most dangerous parts of 4diac FORTE. The reason for that
> > is
> > that it is used to inform a resource/FB that some external event occurred that this specific FB needs to handle.
> >
> > External events are from the 4diac FORTE perspective anything that is coming from the outside (e.g., network message received, interrupt of an IO) that
> > needs in
> > the end some attention in an FB or where later an output event of an FB (typically IND) needs to be triggered.
> >
> > As you may have seen such external event sources are in 4diac FORTE managed by classes inheriting from the CExternalEventManager class. Typically there is
> > only
> > one instance of this class and each instance is managing one external event source. Typically an external event manager has some kind of list or table with
> > all
> > FBs expecting to receive some trigger from this external event source. If you are following our communication architecture this could also be a list of
> > communication layers.
> >
> > So the normal operation for communication layers is such that the external event handler would be notified by the reception of a message. It would search
> > for
> > the right layer and forward the data to it. The layer can do what is needed to process it, and if needed invoke the interruptCommFB. Which you say is nicely
> > explained.
> >
> > Now we come to the part that most probably interests you most:
> > When the commlayer is returning to the handler it should tell the handler if all data has arrived and the FB should be notified about it. Currently most
> > layers
> > are doing this by returning a value that is != e_Nothing. If that is the case the external event handler needs to inform the associated FB. This is done by
> > invoking the startNewEventChain method provided by the base class of the external event manager: CExternalEventManager. This will trigger a rather
> > complicated
> > process of inserting events int queues, activating threads, and in the end activating the CCommFB with an external event. Per default the commFB should now
> > do
> > everything that is necessary to call your layer and that you can apply the data received to the outputs of the commfb. It will also send the appropriate
> > output
> > events.
> >
> > To make the whole thing short. In the end you need in your external event handler a piece of code that is invoking the recv method of your layer and if the
> > return is not e_Nothing invoke start new event chain:
> >
> > if(forte::com_infra::e_Nothing != layer->recvData(pPayLoad, payLoadSize)){
> > startNewEventChain(layer->getCommFB());
> > }
> >
> > The rest should be handled by the infrastructure of 4diac FORTE.
> >
> > I hope this clarifies a bit and helps you.
> >
> > Cheers,
> > Alois
> >
> >
> >
> > On Wed, 2022-04-20 at 12:24 +0200, Davor Cihlar wrote:
> >
> > > Hi!
> > >
> > > I'm implementing PostgreSQL support for Forte and I'm confused about
> > > some parts of the architecture. If someone have some time to help me
> > > understand it I would very much appreciate it.
> > >
> > > On the web interruptCommFB is perfectly explained. But startEventChain
> > > (or is it startNewEventChain now?) isn't, so I'm not sure what its
> > > purpose is.
> > >
> > > Also from the existing sources (xquery, OPC, and some others) it looks
> > > like there is always some kind of queue (and always implemented from
> > > scratch which is not ideal) for commands sent to a handler. I.e. "go and
> > > fetch me some data". But there is no queue of any kind for data that is
> > > going towards outputs of FBs.
> > > This doesn't look good if some process makes multiple data requests and
> > > Handler tries to send all responses to FB ouputs immediately. Or am I
> > > missing something big?
> > >
> > >
> > > P.S.: I wanted to post this on the forum, but unfortunately I managed to
> > > lock my account and I don't know when the lock will time out.
> > >
> > > _______________________________________________
> > > 4diac-dev mailing list
> > > 4diac-dev@xxxxxxxxxxx
> > > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> > _______________________________________________
> > 4diac-dev mailing list
> > 4diac-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev
