Named pipe platform provides for relatively easy testing and debugging of networking and application layers for those who don't have a radio board to run opentag, or would prefer to test Opentag on their host computer.
The Named_pipe provides a simple and reliable method of satisfying the radio transceiver dependency of Opentag for execution on personal computer. The primary motivation being that instead of running two Dash7 boards, two opentag processes will each run in their on console on personal computer.
Why bother to do this?
Firstly, a new user may not yet have radio boards, and wants to try Opentag quickly.
Secondly, for purpose of test, debugging or tracing execution. Executing Opentag on PC instead of reprogramming flash on embedded target can promote more efficient work environment.
When one is working on networking or application layers, quicker results may be had if
printf is desired to be temporarly used to investigate behavior. In some cases, the embedded target may not have the IO resources or extra memory to support something like
Also, Valgrind testing to catch memory access errors which can only be found at run-time.
Why a named pipe?
Pipe naming is useful because the spectrum-ID can be used in the name, uniquely identifing the communication channel is separate from any other spectrum-ID, in the same way that on a real target: radio communication can only occur when same spectrum-ID is used.
Only one processes can be reading from a pipe at a time, otherwize only one receiver (reader) will get the message. Original implementation is limited to two processes.
Addtional Opentag processes can be supported by proposed methods:
First, multiple pipes can be opened for transmitting purpose so each receiver can have its own pipe to itself.
Secondly, for more advanced support: An intermediary process could pass radio messages between processes, which could (for example) facilitate simulation of radio propogation path loss (dB) for validating correct behavior in the networking layers under those conditions.
Posix named pipes provide reliable performance, and is tested under linux.
Performance is good because open/read/write/close operations are very atomic in behavior, meaning they appear to execute in a single instant of time rather than a multi-step process. This is important for asynchronously executing processes which repeatedly open and close pipes.
For reading from a pipe,
SIGIO is used because it provides an efficient callback function, behaving like an RX interrupt from a real radio chip.
1024Hz rate is directly supported by the posix interval timer.
Microsoft API implements a non-posix compliant named-pipe implementation.
Posix implementation is prefered. However, microsoft named pipe can be made reliable by leaving the pipe(s) open and connected forever until the entire process quits. The reason for this is that the microsoft implementation is non-atomic compared to posix implementation such as linux.
Win32 operations of creating pipe, connecting/opening are unreliable under the operating conditions of Opentag where pipes are quickly opened/read/write/closed repeately between two asynchronous processes. However, it is reliable when a pipe is kept opened/reading continuously and repeatedly opened/written/closed by another process.
The problem is further compounded by the fact that
ConnectNamedPipe function doesn't support a completion callback.
Windows provides a timer with one-millisecond resolution, called multimedia timer. The millisecond value is scaled by 0.976 to provide the 1024Hz behavior required by Dash7.
timeSetEvent() function has
lpTimeProc callback to provide same behavior as posix sigaction callback.