The Storyboard IO API, formerly known as GREIO, provides a platform independent communication API that allows inter-task, inter-process queued message passing. This is primarily used to allow external communication with a Storyboard application.
The API provides transport delivery guarantees for messages that are placed into the queue regardless of the implementation. The maximum transport size of a message and the total queue capacity varies slightly from implementation to implementation however a 2K message size should be considered a design limit with the practical implementation limit around a 4K message payload size.
Storyboard IO communicates events over a named uni-directional channel. By default, Storyboard applications have a receive channel, named after the deployment bundle file (i.e. [bundlename].gapp). This allows backend applications to send events to the Storyboard Application. A custom receive channel can be specified in the command option for sbengine. The Storyboard application can transmit events on one or more channels. The backend software will need to open the channel and listen for events. See Storyboard IO API for more details.
Storyboard IO integration with the Storyboard Engine is implemented as a plugin. It is possible to create alternate Storyboard IO implementations that take advantage of custom communication facilities available on a platform. Additionally, Storyboard IO has been extended to provide an abstraction of TCP/IP ports in the place of channels.
The Storyboard IO plugin provides a single communication channel that clients can use to inject events into the Storyboard application. These events will be queued and dispatched in the same manner as internally generated events.
Client applications can use Storyboard IO to create their own communication channels and then receive events from that channel from the Storyboard application or from any other Storyboard IO client.
The Storyboard IO API layers are implemented on top of native message passing and communication APIs. In addition to host operating system's TCP protocol support, the following protocols, dependent on the operating system, are supported:
- Linux
-
SysV message queue
- MacOS
-
SysV message queue
- QNX
-
QNX POSIX message queue (
mqueue
server ormq
server/library)Using the SBIO_MQ_PATH environment variable you can determine which message queue technology will be used. By default the standard
mqueue
server and corresponding C librarymq_*
functions will be used.If the SBIO_MQ_PATH environment variable is set to point at the
libmq.so
library (i.e.SBIO_MQ_PATH=/usr/lib/libmq.so
) then the default binding for the message queue implementation can be changed to use themq
server and the corresponding mq library functions.If the SBIO_MQ_PATH environment variable is used, then it must be used consistently with all Storyboard IO clients and servers that want to communicate with one another.
- WinCE/WinCompact7
-
WinCE MSMQ
- Win32
-
MS-Mailslots
- RTOS (FreeRTOS, MQX, ThreadX, etc)
-
In memory queue
It is possible to send events over TCP as long as the greio-tcp library is available on your system. In order to completely disable TCP functionality from Storyboard Engine, you may remove the greio-tcp library from your device all together.
A TCP connection is specified by the format of the Storyboard IO channel name.
Receiving:
tcp://<port or channel>
Sending:
tcp://<IP address>:<port or channel>
The default IP address is 127.0.0.1 (localhost). The default port is 50000.
If using a port number, the valid range is 49152..65535. If a text channel name is used, Storyboard IO will hash the string into a port value within the valid range of 49152..65535.
The following are examples of valid GREIO TCP channel names.
Receiving:
-
tcp://
(Will use default port of 50000) -
tcp://55555
-
tcp://my_channel
Sending:
-
tcp://
(IP 127.0.0.1 and port 50000) -
tcp://55555
(IP 127.0.0.1) -
tcp://my_channel
(IP 127.0.0.1) -
tcp://192.168.1.101:51515
-
tcp://192.168.1.101:my_channel
-
tcp://dev-machine101:my_channel
As shown above, if the network is configured to assign host names to machines on the network, these can be used in place of IPv4 addresses, provided that the machine has DNS capabilities.