NCR RealScan 7802, User Manual

Page: 75 / 94

NCR RealScan 7802 Price Verifier User Guide
497-0425530 Release E 06/03 75 of 94
APPENDIX E – ProductInfo
Protocol
Abstract: This specification describes a bi-directional message passing protocol called
‘Product Information Protocol’, that is designed especially for retail store price verifier
applications. The protocol is designed to be generic and is not tied to any specific retail
hardware device. Any network topology or configuration capable of using or connecting
to TCP/IP can support ProductInfo based applications. The RealScan 7802 uses a sub-
set of the ProductInfo protocol to meet its functionality requirements.
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 is 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 always is a printable ASCII character – in nominal it is zero (unless you
are sending individual packets in excess of 16MB). When the server receives a trivial-
mode message 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, the server closes
sessions.
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 permit asynchronous
operation. Either side may act as client, or server, or both.
Errors
In the interest of robustness, both ends 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