The Generic Protocol Framework facilitates quick prototyping of various emerging communication protocols for users.
The Generic Protocol Framework is a tool designed for users to quickly prototype different emerging communication protocols. With its ease of implementation, users can simply "drop in" the implementation and test it independently of a finalized product. It was created with the goal of providing developers and end-users with a robust solution that can track message size, generation speed, and the number of each message type seen.
When considering why to use GPF compared to other similar tools, the most compelling reasons are that GPF is open source, easily adaptable to specific implementations, and best of all, free! Unlike other tools that suffer from being closed source, using custom languages, and being expensive.
The basic flow of modifying GPF is extremely user-friendly. The tool-opts.h file contains the basic options that will be applied to the packet. When transmitting the packet, it is done via the tx_message() function, where the message ID and option block are passed. Then, from the message ID, an appropriate tx_* function is selected (to be implemented by the user), and the buffer is written along with the option block. The add_buf_tu*() functions are utilized heavily in this step where users can add a tubyte8, tuint16, or tuint32 number to the buffer.
In daemonize mode, the system listens for incoming packets and when a packet arrives, the basic_parse() function is called on the packet which then calls basic_parse_custom() function in parse.c. This function can call any appropriate parsing helpers, including the get_tu*() functions, which allow users to retrieve tubyte8, tuint16 or tuint32 from the buffer. It's important to note that if the first two bytes of the buffer are zero'd, it will be treated as an END message. However, recovery is available. In the basic_parse_custom() message, users can set the end_signal_caught variable of the option_block to 0, and it will not stop the daemon from running.
In the new release, TCP support is currently experimental, and testing for that portion will continue. There are no clear examples provided but the examples/ directory contains the precursors to a MIP example.
When considering why to use GPF compared to other similar tools, the most compelling reasons are that GPF is open source, easily adaptable to specific implementations, and best of all, free! Unlike other tools that suffer from being closed source, using custom languages, and being expensive.
The basic flow of modifying GPF is extremely user-friendly. The tool-opts.h file contains the basic options that will be applied to the packet. When transmitting the packet, it is done via the tx_message() function, where the message ID and option block are passed. Then, from the message ID, an appropriate tx_* function is selected (to be implemented by the user), and the buffer is written along with the option block. The add_buf_tu*() functions are utilized heavily in this step where users can add a tubyte8, tuint16, or tuint32 number to the buffer.
In daemonize mode, the system listens for incoming packets and when a packet arrives, the basic_parse() function is called on the packet which then calls basic_parse_custom() function in parse.c. This function can call any appropriate parsing helpers, including the get_tu*() functions, which allow users to retrieve tubyte8, tuint16 or tuint32 from the buffer. It's important to note that if the first two bytes of the buffer are zero'd, it will be treated as an END message. However, recovery is available. In the basic_parse_custom() message, users can set the end_signal_caught variable of the option_block to 0, and it will not stop the daemon from running.
In the new release, TCP support is currently experimental, and testing for that portion will continue. There are no clear examples provided but the examples/ directory contains the precursors to a MIP example.
What's New
Version 1.0 RC1: N/A