User manual

ScanVue5® Mini Kiosk
User Manual
M37574–01T
Industrial Electronic Engineers, Inc.
23-June-2008 RevT Page 77
Introduction
The ProductInfo Protocol provides a network–based messaging system whereby a client can obtain item
price and description information about specific products. This information can be in any form such as
text, graphic images, sound or combinations. The protocol will be submitted as an RFC for the Internet
community.
Protocol Types
There are two forms of the protocol: trivial and nominal. The trivial version consists purely of <NUL> terminated
text sent from the client to the host, or from the host to the client. From the client, it is a product query; from the
host it is a text response. This may not support all the features of any particular device, so nominal mode must be
used for advanced features.
The trivial and nominal cases can be distinguished by examination of the first byte; in trivial mode it will
always be a printable ASCII character—in nominal it will be zero (unless you are sending individual
packets in excess of 16MB). When a trivial–mode message is received by the server it is interpreted as a
product query; it optionally contains the client’s identification and white space preceding the product code.
When received by the client, it is interpreted as a single, text response to a query. In either case, sessions
are closed by the server.
In the nominal case, messages consist of a length, followed by a token, possibly followed by more
information as specified by the length and the token.
Symmetry
The format is the same in both directions but the implementations at either end may or may not understand
all the same tokens. In normal operation, the client opens a connection for each request, and keeps it open
until the server instructs the client to close it. The client can also wait for the server to open a socket, to
allow asynchronous operation. Either side may act as client, or server, or both.
Errors
In the interest of robustness, both ends will accept any message whether defined or not invalid messages
are discarded. A maximum reasonable message length may be used as a means to detect implementation
bugs that could result in loss of synchronization; such errors terminate the connection. If the client detects
a loss of synchronization it may send an error token following re–establishment of the connection in order
to log the error on the server. If the server detects this condition, it can log it directly.
Following a query, the client may choose to take an error action if it receives nothing from the server
within a defined timeout period.
Status Requests
The server can make capability queries and/or mode changes before, after, or in lieu of sending any
response. The client may send capability messages regardless of whether the key name is known to the
server; the server retains this information. When the server needs to know the value of one of these
capabilities, it consults this retained information. If it is not known, a capability query may be sent and the
server may wait a moment for a reply to be received. This reply will asynchronously update the server’s
information, and the value should be found there by a subsequent lookup following the brief interval
required for the client to respond to the query. If it remains undefined, it can be assumed that the client
declined to respond, most probably because that capability name is not known to it.