Data Data Packets, Trigger, Data Filtering, Data Monitoring, File Transmission Queue
SuperCom includes intelligent functions that solve lengthly or complex operations easily (Smart Path).
Those intelligent functions not only enable to solve complex tasks fast but also eliminate delaying or blocking of your application. The result is a rock-solid solution, working quickly, softly and smoothly and developed much faster than with regular tools.
This concept will now be demonstrated in the following using some samples. And, as it is common practise in SuperCom software, the following samples can be used without changes over the supported communication links (e.g. Serial, TCP/IP or ISDN).
Additionally RS_GetDataPacketEx can execute the above completely in background and deliver the collected data by events (OnDataPacket).
The parameter cStart, cStop define the rules a data packet must comply with (the lookup strings). When called the function receives a data packet according to the rules set or the requested amount of data received or the specified timeout occured. The parameter cStart and cStop are defining the expected start and stop sequence that makes a complete data packet or cannot be defined at all.
The parameter for Start and Stop can be a single data byte (character) or a sequence of data bytes also binary data and can even include wildcards.
It's not uncommon that an expected data packet (string, byte array, etc.) is not completely defined e.g. a checksum in a specific position, a "LEN" byte etc. A Wildcard can here present the solution in order to define variable Start and/or Stop sequences.
A Wildcard is a character that substitutes for other character. For our purpose the Wildcard "\?" was defined. It uses two characters to define but substitutes one single character. Whenever a data byte in a specific position within the data packet is unknown it can be marked with the wildcard "\?". In the above sample the buffer of the parameter (cStart or cStop) "H\?llo" physically uses 6 bytes but it defines a start or stop sequence of 5 bytes. It will match for any combination of the second character e.g. "Hello", "Hallo".
Set a range of characters
In some cases the expected characters are known but consist of a set of values or a range of values. Such a condition can be described with the "\" sequence, where the allowed set of values are entered within the brackets separated by a ',' and a range of values is separated by '..'.
The trigger "\[1,2,3,a..z]" defines a single character wildcard that allows the trigger to report when any of the characters '1', '2' or '3' or any character in the range from 'a' to 'z' is received.
The trigger "User\[1,2,3]" will report on "User1", "User2" or "User3".
The trigger "User\[a..z]" will report on "Usera", "Userb", "Userc", .., and "Userz".
The trigger "User\[1,2,3,a..c]" will report on "User1", "User2" or "User3" or "Usera", "Userb" oder "Userc" .
The trigger "User\[1,2]\[a..b]" will report on "User1a", "User2a" or "User1b" or "User2b".
The combination of wildcards and value ranges makes it possible to filter complex data packets.
This Data packet collector function is so flexible and reliable that even complete protocols can be realized using it. Once configured it works reliable and returns the expected data packets. If required also via event and background operation (RS_GetDataPacketEx).
The special functions such as RS_GetDataPacket, RS_GetDataPacketEx, TriggerAdd, TriggerDel, TriggerSignaled, ... have been developed around RS_WaitString. Alternatives to solve any problem flexibly and with excellent execution speed.
It's just as easy with the ActiveX API or using the class libraries:
The properties DPStart, DPEnd, DPLimitLen and DPTimeout define the rules for the Data Packet and DPCollect activates the Data Packet Collector. From that point on the Data Packet Collector collects and reports data packets according to the rules (Start="at"CRLF, End=CRLF, where CR=Carriage Return, LF=Line Feed). The Data Packet Collector is reporting the event through the event function OnDataPacket which also delivers the data packet.
The Data Packet Collector runs completely in the background. This allows the application to perform other tasks until the appropriate events arrive and deliver the data. An automated package collecting machine simply activated!
The properties DPStart, DPEnd can be defined as needed or not. DPStart, DPEnd can contain a single data byte (character) or a sequence of data bytes.
It's not uncommon that an expected data packet (string,...) is not completely defined (a checksum, a "LEN" byte). A Wildcard can here present the solution. A Wildcard is a character that substitutes for other character. For our purpose the Wildcard "\?" was defined. It uses two characters to define but substitutes one single character. Whenever a data byte in a specific position within the data packet is unknown it can be marked with the wildcard "\?".
The combination of Wildcards and Set and Ranges enables collecting of even complex data packets.
In the above sample the buffer of DPStart was defined as "a\?"CRLF. It physically uses 5 bytes but it defines a start sequence of 4 bytes ("ax"CRLF). It will match for any combination of the second character e.g. "at"CRLF, "aT"CRLF, "ax"CRLF, etc.
The Data Packet Collector is executing completely in background. The application can now do other thinks until it receives events with the reported data packets. An automated data packet collector very simple activated!
There are situations where the communication library is the one that should act fast on some special data received. The application can do other thinks until the received data require attention. The application will receive a data available event in order to act on.
In order to define a Trigger the functions accepts a text string or a binary data packet.
A Trigger can be a single data byte (character) or a sequence of data bytes.
It's not uncommon that an expected data packet (string,...) is not completely defined e.g. one or more data bytes are unknown. A Wildcard can here present the solution. A Wildcard is a character that substitutes for other characters. For triggers purpose the Wildcard "\?" was defined. It uses two characters to define but substitutes one single character. Whenever a data byte in a specific position within the trigger is unknown it can be marked with the wildcard \?. The buffer of the trigger "H\?llo" physically uses 6 bytes but it defines a trigger of 5 bytes. It will match for any combination of the second character e.g. "Hello", "Hallo". An extra small manual covers this powerfull Trigger Helper API and also presents some aspects of using triggers with protocols.
The combination of Wildcards and Set and Ranges enables running even complex Triggers.
The Trigger mechanism is a real relief for the application. As soon SuperCom receives the awaited data it will report it. The Trigger event EV_TRIGGER is received by the application through the known UserEventProc.
As soon SuperCom receives a trigger it reports the event SCOMM_EV_TRIGGER to the OnComm event function. One can define any amount of triggers as needed and remove every single one using the above properties.
For unknown data bytes (characters) the Wildcard "\?" can be used e.g. "H\?llo".
The combination of Wildcards and Set and Ranges enables running even complex Triggers.
Some tasks require to inspect and/or change data while received or transmited. It's obvious that letting SuperCom do this is advantageous.
SuperCom supports low level data filtering functionality inside the library (DataFilter). Predefined data filter can perform within the library and custom filter using custom functions.
The function ComFilterInit activates the SuperCom data filter. The whole data filter mechanism is running at low level within the library. There exist many predefined filter that can be set using ComFilterInit. The application will always receive the data after all conversions done.
The property DataFilter defines one or more filtering rules from the default SuperCom filtering rules set and activates the data filering mechanism. There exist many pre-defined filter that can be set using DataFilter. The application will always receive the data after all conversions done.
Events are reported continuously as needed. The application is always informed about which file is currently being transferred and the progress.
The presented tools are offering different ways to complete the mission. Other combinations are also possible. The manual provides additional information and on specific questions our technical team surely can show additional solutions.
Intelligent functions can solve complex tasks. Exactly as one would expect from a professional Tool.
A DUAL API SuperCom software allows even better utilization of the presented tools. Among other things, it allows to call functions from the ActiveX API and DLL API as required.
SuperCom is still the number one toolkit that supports different development environments providing extensive API support and samples. You're free to switch your compiler anytime and your are not bound to one and only. This saves a huge amount of time and costs of development.
As a SuperCom customer, you can always contact us and query fast the suitable function, parameter definition, Trigger to define etc. We will tell you exactly if and how to use a suitable SuperCom function in order to get specific data (-packets) fast and accurate.