Re: [4diac-dev] Confusion regarding communication architecture

[Alois Zoitl <alois.zoitl@xxxxxx>]

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