This module accepts ephemeral SIK3, SOK3, and CCK3 keys and provides SIKZ, SOKZ, CCKZ and ZMK keys that may be longer-lasting. SIKZ, SOKZ, and CCKZ obey the SIK3, SOK3, and CCK3 protocols respectively. The supported ("Z") keys are connected transparently to the provided ("3") keys with the following exceptions. The zapper module only signals EOF on SIKZ and SOKZ when the zapper module is destroyed (not when EOF is signalled from the "3" keys). If EOF is signaled by the user of the "Z" keys, communication is ended permanently, but EOF is not signalled to the "3" keys.

See (zmc) about new zapper modules.

CCKZ

See (cck3) for standard CCK3 function. Also:

CCKZ(4;==>0;SIK3,SOK3,CCK3)

Destroys the zapper module and signals EOF on SIKZ and SOKZ.

The current SIK3, SOK3, and CCK3 are returned if they exist and are available.

Since no limit for SOK3 is returned, the user will have to assume a limit of zero initially.

CCKZ(kt;==>X'50E';)

This key provides the following functions:

ZMK(0,((4,limit));CCK3,SIK3,SOK3 ==> ;) "Reconnect"

The new keys CCK3, SIK3, and SOK3 will be used when a new circuit is required. "limit" is the number of bytes of output SOK3 can accept.

The following explains what is meant by "when a new circuit is required":

The input side of the zapper module is in one of three states.
In the "Waiting for Reconnect" state, the zapper module holds no SIK3 key. When a reconnect is done, the new key will be used and the "Transmitting" state is entered.

In the "Transmitting" state, if an EOF (i.e. zapper) is detected, the "Waiting for Reconnect" state is entered. If a reconnect is done, the offered SIK3 is saved and the "Reconnect Buffered" state is entered.

In the "Reconnect Buffered" state, if an EOF is detected, the "Transmitting" state is entered and the saved SIK3 is used. If another reconnect is done, the saved SIK3 is discarded and the new SIK3 is saved (and we remain in the "Reconnect Buffered" state).

This latter situation is not considered an error ("too many reconnects"), because SIK3 may have signaled an EOF but it may not be detected for a long time if the SIK3 interface is consuming (not asking for input). The saved SIK3 is discarded under the assumption that if it were used it would only signal EOF.

The output side similarly has three states.

The control side (CCK3) is handled similarly, but if an EOF is detected on CCK3, an EOF is sometimes presumed on SIK3.

It is assumed that there is initially no transmission in progress on the new circuit.

Usage Note: Since code 2 (destroy) is not in CCK3's repretoire and code 2 on the CCK key to the zapper module results in code 2 to CCK3, then the ZM will crash upon code 2 when endowed with CCK3! Perhaps some design should be changed here.

ZMK(1;==>c;) "Wait for Zapper"
If there is no circuit on CCK3, SIK3, or SOK3, returns immediately with c=0. Otherwise, waits until a zapper is detected on CCK3, SIK3, or SOK3. A zapper is not detected until there is a need to use the circuit. If there is already a domain waiting for a zapper, the operation returns immediately with c = 1, otherwise c is 0.

ZMK(2;==>c;) "Send Zapper"
Attempts to send a zapper on CCK3.

Return code c is 0 if a zapper was sent. After this operation, no data sent on SOK3 will go to the old circuit.

Return code c is 1 if there was no circuit.

{ni}ZMK(3;==>c,((4,limit));CCK3,SIK3,SOK3) "Give me the current circuit"
The zapper module returns the keys to the current circuit and acts as if a zapper had been received from that circuit.

Perhaps different calls should be provided to cover the case where the resume keys might not be available at the time of the call (whether or not to wait). The return should also signify whether there was a circuit.

ZMK(kt;==>X'1050E';)