Overview

A port provides access to a channel for a period of time during which the channel provides access to either just one "virtual call" or one "permanent virtual circuit". During this time the port may be used to send and receive user data and interrupts.

I summarize the functionality of an X.25 logical channel here as I understand it. I suppress X.25 details that are hidden by our proposed Gnosis abstraction. This abstraction does not diminish the function of the logical channel beyond preventing the abstraction user from doing things that the X.25 recommendation says he "shouldn't" do.

The functions of the X.25 logical channel are separated into two categories so that access to a logical channel may be granted to a user only for the duration of a "virtual call" called ... a "session" here.

Definitions
A packet is a string of bits of some definite length greater than zero. Our "packet" is the "complete packet sequence" of the X.25 recommendation. In Gnosis the packet length is always an integral number of bytes (called "octets").

Some packets are "qualified". The sender determines this and the receiver may choose to sense it.

An interrupt is a signal carrying from 1 to 32 bytes of "Interrupt user data".

Gnosis Embodiment
One each of the next five operations may be in progress at once. In each of these specifications "packet" refers to a string of bytes that compormise the user data portions of a "complete packet sequence" as defined by X.25.
In each of these operations, ge in the return code is 16 if there is already such an operation in progress; or ge is 32 if port CK is unmapped; otherwise ge is zero. The invocation has no effect unless ge is zero.

{send packet}CK(4*m+2*q+d,packet=>ge)
This invocation may stall due to network congestion or a slow peer (at other end of X.25 circuit).

m, q and d are each either zero or one.

If d is zero the operation will complete as soon as the packet can be accepted for delivery. Otherwise the operation completes only after the packet has been delivered across the network and the peer has accepted it.

If q is 1 the packet is qualified, otherwise not.

If m is one then this is not a complete packet and following packet is to be concatenated to this (recursively). The q of the next packet must be the same as this one. d for this packet must be 0.

{receive packet}CK(8192+4096*i+l=>ge+8*d+4*m+2*q+j,packet)
This completes when a packet has arrived or at least the first l bytes of a packet have arrived. q is one if the packet is qualified. d is 1 if delivery of this packet was requested. If the length of the packet is greater than l then m is one and only the first l bytes are returned and the undelivered portion remains as the next packet to be delivered.
l < 4096? j = 0?

If i is one then this operation will also complete when an interrupt arrives, whence j will be one and the interrupt user data from the interrupt returned as the string. If the interrupt user data length exceeds l, the tail is lost.

If the preceeding inbound packet required delivery confirmation and it has been not yet been confirmed it will be confirmed. This operation with l=0 has the effect of confirming such a delivery as well as providing a preview of bits d, m and q for the next inbound packet.

How can I confirm a delivery without waiting for the next packet? I think l=0 should do that and not return d, m, and q.

{send interrupt}CK(64,(Interrupt user data)=>ge)
Interrupt user data must be a string of length from 1 to 32. An interrupt is issued. This operation completes after the interrupt has been delivered to the other end of the circuit and the peer has accepted it.

{receive interrupt}CK(65=>ge,(Interrupt user data))
This operation waits until an interrupt arrives. The Interrupt user data may be delivered to both this operation and the "receive packet" operation.
Wouldn't it be simpler if interrupts were only delivered here?

{wait for reset}CK(66=>ge,((1,Resetting cause),Diagnostic code))
If a logical channel leads to a "permanent virtual circuit" then a network failure generates a reset and data may be lost. This is how the apology arrives.

{delay confirmations}CK(68;=>0)
Extablish mode for this circuit whereby packets requiring confirmation are not confirmed until the subsequent packet is read.
... until explicitly confirmed by the holder of the X key.

{expidite confirmations}CK(69;=>0)
Establish mode for this circuit whereby packets requiring confirmation are confirmed when they reach the 370.

{rest}CK(?;=>c,((4,who)))
This notifies the X.25 multiplexor that this circuit is expected to be idle for a while. Key X may become disassociated with any circuit for a while and then become associated with some other circuit with traffic. The operation will finish then and "who" will identify the new circuit (somehow).