IEEE P1284.4 draft standard for data delivery and logical channels for IEEE std. 1284 interfaces.Draft D4.00.1999

IEEE P1284.4, Draft D4.00, December 1, 1999

Table 5 shows an example of the commands and credits associated with establishing a 1284.4 conversation, and opening and closing a channel between a primary and secondary 1284.4 peer. Note that after a successful Init transaction both the primary and secondary peers have one credit for issuing a command.

Table 5--Flow control of 1284.4 transaction packets

4.5.6 Multiple Outstanding Transactions

It is permitted to issue multiple outstanding transactions; i.e. an initiator may issue another transaction without waiting for the completion of a previous transaction. This is only permitted when the target has granted extra credit on the transaction channel. An initiator can issue only one outstanding transaction referencing a particular channel. The transactions do not need to be completed in order. The reply carries enough information to match it to the appropriate command. 1284.4 implementations are not required to support multiple outstanding transactions. The CreditRequest transaction is used to request extra credit on the transaction channel.

Flow control for multiple outstanding transactions differs from 4.5.5 - 1284.4 transaction channel flow control as follows:

a)1284.4 initiators may request multiple outstanding transactions by setting MaximumOutstandingCredit to a value greater than one (1) using a CreditRequest command. Targets that support multiple outstanding transactions can then enable them by granting additional credit on the Transaction channel in the CreditRequestReply or a subsequent Credit command. Implementations that don't support multiple outstanding commands shall not grant any additional credit.

b)Each 1284.4 peer can issue only one outstanding transaction referencing a particular channel. For example, it is only acceptable to issue more than one Credit transaction concurrently if the Credit transactions refer to different channels.

Table 6 shows an example of multiple outstanding transactions. Included are the commands and credits associated with establishing a 1284.4 conversation, discovering the socket IDs for two services, and opening channels to those services.

15

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

Table 6--Flow control of 1284.4 transaction packets (multiple outstanding transactions)

4.5.7 Deadlock avoidance and blockage prevention

1284.4 implementations shall avoid deadlocking on credit. Deadlock occurs whenever the receiver is waiting for the sender to request credit while the sender is waiting for the receiver to grant credit. This is an exceptional condition, since either the sender failed to request credit or the receiver failed to grant credit. All senders shall implement a “fail-safe” mechanism to request credit if a deadlock occurs. This mechanism can be as simple as using a relatively long deadlock time-out before requesting credit. The length of this time-out should be sufficiently long to avoid asking for credit before the receiver has had the chance to consume the previously sent data and grant more credit.

1284.4 implementations shall prevent blocking of a channel due to activity on other channels. Examples of buffer allocation issues are included in E.4 - Allocating buffers to avoid channel interaction.

16

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

5. 1284.4 Transactions

5.1 Overview

The transactions described in this section of the document are composed of transport commands and replies. The initiator of a transaction is the 1284.4 peer that sends the command starting the transaction and receives the reply completing the transaction. The target of a transaction is the 1284.4 peer that receives the command starting the transaction and sends the reply completing the transaction. The initiator assumes the transaction to have started when it sends the command and to be complete when it receives the reply. The target assumes the transaction to have started when it receives the command and to be complete when it sends the reply.

Transactions can be simultaneously initiated by both peers. Neither peer shall assume that the next incoming packet will be the reply to the command it just sent.

5.2 Transaction summary

Table 7 summarizes the transactions exchanged between 1284.4 peers. These transactions consist of matched commands and replies. Reply codes are formed by setting bit 7 of the corresponding command code. Command codes can range from 0x00 to 0x7F. Reply codes can range from 0x80 to 0xFF. Unassigned values are reserved. All of these commands are sent over the 1284.4 Transaction Channel.

Table 7--Summary of transactions

a These values are used by Hewlett-Packard’s MLC protocol and are deprecated for compatibility purposes.

17

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

The following table summarizes the possible result values for all of the 1284.4 transactions.

18

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

5.3 Conversation Control Transactions

A conversation is the set of interactions between two 1284.4 peers during the period of time bounded by the completion of corresponding Init and Exit transactions. This section describes the 1284.4 transactions that establish, manage and terminate the conversation.

5.3.1 Init

The Init transaction is used to establish a 1284.4 conversation. A conversation shall be established before any subsequent 1284.4 communications take place.

The initiator of the conversation sends an Init command with the requested 1284.4 revision. If the target supports the requested 1284.4 revision and can begin a 1284.4 conversation, the target shall send an InitReply with a matching revision and a success result value. If the target does not support the requested 1284.4 revision, the target shall send an InitReply with the highest revision it does support (less than that requested by the initiator), and a result value indicating that it is unable to support the requested revision.

When an Init transaction is completed with a result value indicating success, the 1284.4 conversation has been established at the revision level requested by the initiator. The initiator of the successful Init transaction becomes the primary device for that conversation. The target of the successful Init transaction becomes the secondary device for that conversation.

A random back-off strategy shall be implemented to successfully establish the 1284.4 conversation and to establish the primary and secondary devices if Init transactions are initiated by both 1284.4 peers at the same time. If an Init command is received by a 1284.4 peer that has initiated its own outstanding Init transaction, it shall send an InitReply with a failure result value as shown in Table 11. After the 1284.4 peer receives the InitReply completing its outstanding Init transaction, the peer shall then wait a random length of time and again initiate an Init transaction. This process continues until one of the Init transactions completes successfully. It is illustrated in Figure 1.

Figure 1 - Random back-off of simultaneous Init transactions

Init and InitReply may be sent at any time, even if there is no credit on the 1284.4 transaction channel. Sending the command during a 1284.4 conversation will cause that conversation to be reset and a new conversation to start. The reset implicitly terminates all pending transactions for the conversation, and closes all channels associated with the conversation.

Init and InitReply consume no credit. The initiator of an Init transaction may not receive an InitReply. In this situation, it is valid to send another Init, because Init consumes no credit. The piggyback credits received with Init and InitReply become the initial credit balance of the 1284.4

19

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

transaction channel. If more than one Init command is received, only the credit from the final Init is valid.

If there is no reply to the Init command, the initiator shall wait some time before initiating another Init command. This will avoid issuing a second Init command before the target has had enough time to reply to the first Init command. Since it is still possible that the target may reply to each command, any extra InitReply replies received by the primary 1284.4 peer before the replies to any other commands and before receiving any commands from the secondary 1284.4 peer shall be ignored.

Table 9 and Table 10 show the contents of the Init command and reply packets including the packet header.

Table 9--Init command

a Indicates the revision of 1284.4 to which the initiator is attempting to negotiate. This provides some indication as to which commands and replies are recognized by the initiating 1284.4 peer. The initial and current revision of the 1284.4 protocol is 0x20. Future revisions shall be greater than 0x20. All implementations are required to support the base (0x20) revision of the 1284.4 protocol.

Table 10--InitReply packet

a When the Result field indicates success, Revision indicates the actual revision to be used, which shall match the Revision requested by the initiator. When the Result field indicates that the target can not support the Revision requested by the initiator, Revision indicates the highest revision of 1284.4, less than the requested revision, the target of the Init transaction implements.

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

0x02 Unable to support requested revision. The initiator can attempt to negotiate to a common revision.

0x0B The Init transaction can not be completed due to an outstanding Init transaction initiated by this 1284.4 peer. The initiator of this transaction should wait a random length of time and then try again to establish the conversation.

21

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

5.3.2 Exit

The Exit transaction is used to terminate the current 1284.4 conversation. Either 1284.4 peer can initiate an Exit transaction, regardless of which peer started the current conversation. To terminate normally, complete all outstanding 1284.4 transactions and close all open channels before initiating the Exit transaction.

If a 1284.4 peer determines that it is not possible to terminate normally, it is acceptable to initiate the Exit transaction without completing outstanding 1284.4 transactions or closing open channels. The Exit transaction causes all outstanding transactions to be aborted, all open channels to be closed, and the conversation to be terminated.

The initiator of the Exit transaction begins the transaction by sending an Exit command. No other 1284.4 transactions shall be initiated once the Exit transaction begins. Upon receiving the Exit command, the target of the transaction optionally completes any outstanding transactions, and then completes the Exit transaction by sending the ExitReply. It is not necessary for the initiator to wait for the ExitReply. The 1284.4 conversation is considered terminated after the completion of the Exit transaction.

If both 1284.4 peers initiate Exit transactions at the same time, both Exit transactions shall be completed. The 1284.4 conversation is considered terminated after the completion of both Exit transactions.

Each peer shall have no more than one Exit transaction outstanding at any time (see 4.5.5 - 1284.4 transaction channel flow control).

Data received prior to issuing or receiving an Exit command shall be delivered. Data received after issuing an Exit command may be delivered. Any packets received after receiving an Exit command shall be ignored, since the conversation has been terminated.

Table 12 and Table 13 show the contents of the Exit and ExitReply packets, including the packet header.

Table 12--Exit packet

22

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

a Indicates the outcome of the Exit command. This field shall take on the value shown in Table 14.

Table 14--ExitReply result values

23

Copyright © 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.

IEEE P1284.4, Draft D4.00, December 1, 1999

5.3.3 Error

The Error packet is used to report errors that can not be reported in a 1284.4 transaction.

The Error packet does not have a reply. It may be sent at any time, even if there is no credit on the 1284.4 transaction channel. Error consumes no credit. Piggyback credit can not be granted via the Error packet.

Error packets do not implicitly close connections nor terminate the conversation.

Table 15 shows the contents of the Error packet, including the packet header.

Table 15--Error packet

aSpecifies the PSID of the packet in which the error was detected.

bSpecifies the SSID of the packet in which the error was detected.

cSpecifies what type of error has occurred. This field can take on the values listed in Table 16.

Table 16--Error command ErrorCode values

24

Copyright 1996-1999 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change.