For more information, see:
The latest version of this (http://www.jpaulmorrison.com/fbp/CsharpFBP-2.3.zip) is available on my web site, and also on SourceForge. Its features are shown below:
The following is definitely the major change in Version 2.x, and means that every "verb" (component) must be enhanced with metadata. However, this can generally be done using cut and paste, and need only be done once.
- Input and output port names will be coded on components using C# "attribute" notation. This is metadata that can be used to do analysis of networks without having to actually execute the components involved. Here is an example of the attributes for the "Collate" component:
[InPort("CTLFIELDS")]
[InPort("IN", arrayPort = true)]
[OutPort("OUT")]
public class Collate : Component {
- I think it is important to note that it may be possible to handle all of the port definitions by setting this up in a centralized place (via Inversion of Control and Dependency Injection). This would allow for decreased coupling and increase the ease of use. Hopefully, I'll have time to try this out. -JustinBozonier
- I took a look through the implmentation and I can see that this is what is happening (essentially), very nice.
- Input ports do not necessarily have to be connected, even though attributes are specified for them; output ports, however, must be.
- MustRun is also specified as metadata, e.g.
[MustRun]
Other changes:
- Dropping a packet is now done by a method of class Component (as opposed to a method of class Packet), e.g.:
Drop(p);
where "p" is the packet.
- We are adding a "long wait" state to components, specifying a timeout value in seconds. This is coded as follows:
double _timeout = 2; // 2 secs
....
LongWaitStart(_timeout);
// activity taking time goes here
LongWaitEnd();
- Typically, the timeout value is given a default value in the code, and overridden (if desired) by an IIP.
- While the component in question is executing the activity taking time, its state will be set to "long wait". If one or more components are in "long wait" state while all other components are suspended or not started, this situation is not treated as a deadlock. However, if one of the components exceeds its timeout value, an error will be reported (Complain).
- I have become persuaded that a components' responsibility for an IP is discharged once it issues a Send - see UndeliveredMail. This suggests that Send should not return a "success/fail" indicator, but should simply crash the program (FlowError.Complain) if a data packet cannot be delivered - either because the receiving input port is closed, or no connection was specified. This means that the network designer should connect any output ports sending unneeded data to a Discard or Log component.
Connect("componentA.portname", "componentB.portname");
- This assumes that the component names have been associated with a type in an earlier statement of the form
Component("xxxxx", typeof(yyyyy));
- If one of the ports involved is an array port, the port array name and index can be entered as
"portname[index]"
where "index" is an absolute number - either in a "Connect" or an "Initialize" statement.
- The input ports to which IIPs are connected should be closed by the component code after the receive has been done - this ensures that, if fed by an upstream component rather than an IIP, only one IP can be sent successfully. Once the port is closed, an additional send will cause the sending component to abort. When making a component available for general use, all IIP ports should be tested using a data stream connection, as well as an IIP.
- Unlike the 1.x.x versions of JavaFBP, an IIP will only be received once per invocation, rather than once per activation - additional receives just return null.