Rich Trapp ([log in to unmask]) wrote:
: Chris askes:
: >
: > Hello All,
: >
: > Has anybody got experience with character-based applications
: > running over X.25 ?
: [snipped]
 
Thought to spare couple of things about X.25 and PADs.  The communication
between the host computer and a PAD over X.25 is dictated by standards and
of those involved are X.3, X.25, X.28, X.29, possibly also X.75 and X.121.
 
The ones of importance in PAD communication are X.3, X.28 and X.29.  X.3
defines what parameters the PAD MUST support, X.29 defines how a host can
control PADs X.3 parms over X.25 network and X.28 defines how the PAD
attached terminal can control the PADs X.3 parms locally.
 
As you see, it all boils down to is "what the X.3 parms are and how they can
be controlled?".  Another thing is that as these are CCITT standards - i.e.
if one wants to operate in X.25 cloud, one has to and one only can do what
has been defined in the yellow/blue/red book from CCITT (the color changes
with every revision...).
 
To the point.  For doing reads over X.25, there are only two(2) options
for a PAD for terminating a read (and IMHO it's missing one important one).
These are:
 
  1) Data forwarding character typed from terminal (often <CR>)
  2) idle timer expired
 
Note that the data forwarding character can be configured any or ALL, which
is kind of third option;- you can have all characters to cause the PAD to
build an X.25 packet and send it.  As you can see, this option generates
lots of X.25 traffic...
 
The one that you *CANNOT* do (and is the one I think we are missing from X.3
spec) is the read count.  An X.25 pad following CCITT X.3 recommendations
__can_not_terminate_read_on_read_count__.  If your application wants to do
one character read, there is no way in X.3 to tell it to the PAD.  The only
way you can accomplish this is to either:
 
  1) Configure PAD to forward data on ALL chars.
  2) set idle timer to a low value, typically 0.1 secs
 
These both have their advantages and disadvantages but as far as I can tell,
there is no other way to do it.  Many PADs support some manufacturer_specific
parms, often referred to as "local parms" and those also are settable/readable
over X.25 using a special form of an X.29 command.  However, I haven't seen
one that implements read count.  Second, if there was one, the read count
would only work with that specific manufacturer's PAD and would require the
host to allow the user application to create it's own type of X.29 packet
to be sent to the PAD.  I'm not saying it cannot be done... only that I
haven't seen any PADs capable of doing it (so far).
 
Eero Laurila - HP CSY Networking lab, NS services.