00000008

IEEE P1284.4 Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces

Draft D2.00 April 5, 1999 Sponsor Microprocessor and Microcomputer Standards Committee of the IEEE Computer Society Prepared by the IEEE P1284.4 Working Group of the Microprocessor and Microcomputer Standards Committee

This is an IEEE Standards Project, subject to change. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities, including balloting and coordination. If this document is to be submitted to ISO or IEC, notification shall be given to the IEEE Copyrights Administrator. Permission is also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position. Other entities seeking permission to reproduce portions of this document for these and other uses must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk.

IEEE Standards Department Copyright and Permissions 445 Hoes Lane, PO Box 1331 Piscataway, NJ 08855- 1331, USA

ii Draft Revision History

Revision Date Issued Description 2.00 April 5, 1999 · (Change bars indicate changes from 1.7)

· Added end- of- message flag

· Added section title to all section reerences

· Added AsyncSelect

· Added description of error conditions

· Rearranged Transaction Channel flow control sections

· Made API clause closer match to Winsock- 2 API

· General cleanups 1.80 May 13, 1998 · As reviewed in .4 review mtg. on May 12, 1998. 1.70 April 13, 1998 · (Change bars also indicate changes from 1.5 to 1.6)

· Simplified by merging “address server” into “service discovery” and “CBT” into “1284.4”

· Cleaned up text. 1.60 February 18, 1998 · From other changes noted but not made during the May

1997 meeting. 1.50 August 12, 1997 · As reviewed and edited “on the fly” during the May 1997

meeting. 1.40 May 12, 1997 · Updated to reflect changes from March/ April 1997

meeting in Austin.

· Most sections were reviewed and edited “on the fly” during the meeting. Sections 5.4, 5.5, 5.6, 7, 8 and the Annexes were not reviewed.

· Updated SPI section. 1.30 March 31, 1997 · Updated to reflect changes from February 1997 meeting

in Orlando.

· Renamed “command channel” to “transaction channel”.

· Allowed multiple outstanding commands on the transaction channel.

· Removed MLC annex.

· Lots of editing for readability and better understanding. 1.20 February 24, 1997 · Updated to reflect changes from January 1997 meeting in

Albuquerque.

· ConfigSocket merged into OpenChannel

· Combined CBT commands and replies into transactions

· Moved address server to CBT commands

· Command channel flow control made the same as all other channels

· Added new flow control mechanism 1.10 January 3, 1997 · Update to reflect changes up to 5.6 per IEEE P1284.4

meeting in New Orleans, 11- 4 to 11- 5 1996.

· Cleaned up Error handling by adding replies to each command and clarifying use of the Error command.

· Cleaned up footnotes to add normative info to the actual standard.

· Added Init Revision negotiation

· Revised and added crediting and flow control information.

· Began error handling and FSM updates: categorized commands, updated tables.

· Updated command and replies for clarification and errors.

iii 1.00 October 30, 1996 Update to reflect changes covered through 5.4.1.1 per IEEE

P1284.4 meeting in NY, 10- 1- 96. Added Service Discovery information based on approved proposals in clause 7 and Annex B. Converted all appropriate host/ peripheral to primary/ secondary peer terminology. Added CBT as name for IEEE 1284.4 transport. Added MLC Ó Legacy Issues to annex C. Continued cleanup and formatting to IEEE Standards Style Manual. 0.20 September 24, 1996 Incorporated HP’s MLC 3.8 specification technology for

committee review. Incorporated data link requirements for committee review. Formatted & reworded as per committee review on 6/ 26/ 96 Converted packet offsets to hex Forced reserved values to be 0x00. Began reformatting to IEEE standards. 0.01 June 26, 1996 Formatting Changes 0.00 May 21, 1996 Initial Version

Introduction

(This introduction is not a part of IEEE P1284.4, Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces.)

This standard was formally started as an IEEE effort in January 1996. Members of the IEEE P1284.4 Working Group would like to thank the Hewlett- Packard Company, and the IEEE 1284.1 and 1284.3 committees for their efforts in establishing the foundation for this standard and allowing this committee to include their work as the basis for much of this standard.

At the time this standard was completed, the key contributors to the Working Group on "Standard for Data Delivery and Logical Channels for IEEE Std. 1284 Interfaces" were as follows:

Larry A. Stein, Chair

Mark T. Edmead, Secretary Brian Batchelder, Editor Bob McComiskie, Secretary Walt Scheiderich , Editor Jim Anderson Lee Farrell Robert Gross Joe Halpern Reed Hinkel Monte Johnson Laurie Lasslo Greg LeClair

Paul Lindemuth Raymond Lutz Mike Moldovan Ron Norton Rick Pennington Greg Shue Lance Spaulding Bill Stanley

Ron Talwalkar Randy Turner William Wagner Andrew Warner Forrest D. Wright Atsushi Yuki Steve Zilles

IEEE Standards documents may involve the use of patented technology. Their approval by the Institute of Electrical and Electronics Engineers does not mean that using such technology for the purpose of conforming to such standards is authorized by the patent owner. This working group is aware that this standard may read on issued or pending patents of the Hewlett- Packard Company and Genoa Technology. These companies have agreed to license these patents in a reasonable, non- discriminatory manner. Other patents may also exist. It is the obligation of the user of such technology to obtain all necessary permissions.

Contents

CLAUSE PAGE 1. Overview ................................................................................................................................... 1

1.1 Scope................................................................................................................................. 1 1.2 Purpose ............................................................................................................................. 1

2. References ............................................................................................................................... 1 3. Definitions ................................................................................................................................. 2

3.1 General terminology .......................................................................................................... 2 3.2 1284.4- specific terminology............................................................................................... 3

4. Features and compliance ......................................................................................................... 5 4.1 Overview............................................................................................................................ 5 4.2 Features............................................................................................................................. 5 4.3 Compliance criteria ............................................................................................................ 5 4.4 MLC compatibility criteria................................................................................................... 6

5. Theory of operation of the 1284.4 protocol ............................................................................... 7 5.1 Overview............................................................................................................................ 7 5.2 General packet structure ................................................................................................... 7 5.3 Communication procedures............................................................................................... 8 5.4 Service discovery............................................................................................................. 10 5.5 Data transfer and flow control.......................................................................................... 11

6. 1284.4 Transactions ............................................................................................................... 17 6.1 Overview.......................................................................................................................... 17 6.2 Transaction summary...................................................................................................... 17 6.3 Conversation Control Transactions ................................................................................. 19 6.4 Connection Control Transactions .................................................................................... 25

7. Data link service requirements ............................................................................................... 37 7.1 Overview.......................................................................................................................... 37 7.2 Required Services ........................................................................................................... 37

Annex A Bibliography (informative) ........................................................................................... 39 Annex B Service Names Registry (normative) .......................................................................... 40 Annex C 1284.4 Architecture (informative)................................................................................ 42 Annex D Example 1284.4 API (informative) .............................................................................. 43

vi API Overview.............................................................................................................................. 43

API Services ............................................................................................................................... 43 API Usage .................................................................................................................................. 49 D. 4 Mapping API services to 1284.4 transactions ................................................................. 49

Annex E Implementation Issues (informative)........................................................................... 53

1. Overview 1.1 Scope

The packet protocol described by this standard allows a device to carry on multiple, concurrent exchanges of data and/ or control information with another device across a single point- to- point link. The protocol is not a device control language. The protocol provides basic transport- level flow control and multiplexing services. The multiplexed information exchanges are independent and blocking of one has no effect on any other. The protocol shall operate over IEEE Std. 1284- 1994 interfaces and may operate over other interfaces, such as RS- 232, Universal Serial Bus (USB), and IEEE 1394- 1995.

1.2 Purpose

IEEE Standard 1284- 1994 defines and describes an updated PC parallel interface by adding multiple modes of operation, which provide for higher speed, bi- directional communication between devices. The IEEE Std. 1284- 1994 standard does not provide anything beyond a physical protocol. The 1284.4 standard specifies a point- to- point protocol with one or more layers above the physical interface and below the application. These layers take on the functions and characteristics of the transport and session layers of the OSI model.

2. References

This standard shall be used in conjunction with the following publications: None.

3. Definitions 3.1 General terminology

The following terms and acronyms are used in this standard. The definitions are not intended to be absolute, but they do reflect the use of the terms in this standard.

3.1.1 Big- endian: A data format where the most significant byte of a multi- byte object is at the lowest address and the least- significant byte is at the highest address.

3.1.2 Byte: An 8- bit value. In this standard, bits are read left to right with the MSB (Most Significant Bit) labeled 7 to LSB (Least Significant Bit) labeled 0 as shown in the following figure:

Bit 7 - MSB Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 – LSB

3.1.3 Connection: A persistent communications path between two endpoints.

3.1.4 Device Control Language: A language used to monitor and/ or control the state of a device.

3.1.5 Endpoint: A consumer or producer of data on a communication link.

3.1.6 Flow control: The function performed by a receiving entity to limit the amount of data that is sent by a transmitting entity.

3.1.7 IEEE Std. 1284- 1994: The IEEE Std. 1284- 1994 defines a signaling method for asynchronous, half- duplex, fully interlocked, bi- directional parallel communications between hosts and printers or other peripheral devices.

3.1.8 IEEE P1284.3: The IEEE P1284.3 standard extends the IEEE Std. 1284- 1994 to provide port sharing and data link functionality.

3.1.9 ISO: Acronym for International Organization for Standardization. A voluntary, non- treaty organization whose members are designated standards bodies of participating nations, and non- voting observer organizations.

3.1.10 Logical channel: One connection over a single physical communication link. There may be multiple logical channels over a single physical communication link.

3.1.11 OSI model: Acronym for Open Systems Interconnect model. A seven- layer network communications model developed by an ISO subcommittee that governs communications interchange between systems. The model is an internationally accepted framework of standards for intersystem communications.

3.1.12 Packet: A group of bytes, including address, data, and control elements.

3. 1. 13 Point- to- point communications: Communications that take place between exactly two devices.

3.1.14 Service discovery: The function of providing transport clients with the ability to dynamically query service availability within a peer transport entity.

3.2 1284.4- specific terminology 3.2.1 Blocked channel: A channel with at least one blocked endpoint.

3.2.2 Blocked endpoint: An endpoint that is unable to send data due to lack of credit. A blocked endpoint becomes un- blocked when it is granted credit.

3.2.3 Channel: An independently flow- controlled connection between a socket on the primary device and a socket on the secondary device. It provides a logical conduit for moving data between the two endpoints.

3.2.4 Client: Name used to refer to the software component on one device that uses the services provided by a server on another device. The communication between the client and the server is managed by the protocol defined in this standard.

3.2.5 Command: The instruction sent from an initiator to a target directing the target to execute a specified process.

3.2.6 Conversation: Canonical name given to the interactions between two 1284.4 peers during the period of time bracketed between corresponding Init and Exit transactions.

3.2.7 Credit: A value issued by a peer 1284.4 indicating the number of packets that may be received on behalf of an endpoint.

3.2.8 End- of- message packet: The last packet of a message in the data stream.

3.2.9 Initiator: The peer 1284.4 implementation that initiated a transaction by sending a command.

3.2.10 Multiple Outstanding Transactions: A state where more than one transaction have been issued and are pending completion.

3.2.11 Out- of- band packet: A packet of exceptional data in the data stream. This type of packet may contain special information relating to the data at this position in the data stream, for example, “End of Job.”

3.2.12 Piggyback Credit: Term used to describe the inclusion of credit inside a 1284.4 packet header. By using piggyback credit, 1284.4 can reduce the overhead of credit transactions when processing a channel on which data is flowing bidirectionally.

3.2.13 Primary device: The device that issued the Init transaction that started the current 1284.4 conversation. The primary device has no precedence over the secondary device. The assignment of primary status is used only to identify the device that contains the primary sockets.

3.2.14 Primary Socket Identifier (PSID): A socket number identifying a particular endpoint on the primary device. A primary socket ID can be well known or can be assigned dynamically.

3.2.15 Reply: The response sent from a target to an initiator indicating that the target has successfully or unsuccessfully executed the process specified by the command originally sent from the initiator to the target.

3.2.16 Secondary device: The device that was the target of the Init transaction that started the current 1284.4 conversation. The secondary device is not subservient to the primary device. The assignment of secondary status is used only to identify the device that contains the secondary sockets.

3.2.17 Secondary Socket Identifier (SSID): A socket number identifying a particular endpoint on the secondary device. A secondary socket ID can be well known or can be assigned dynamically.

3.2.18 Server: The software component on one device that provides services for use by clients on the same or another device. The communication between the client and the server is managed by the protocol defined in this standard.

3.2.19 Service Name: The canonical name of a particular service available for use by a 1284.4 client.

3.2.20 Socket: Canonical name given to a 1284.4 endpoint to which or from which data is transmitted.

3.2.21 Socket ID (identifier): A byte used to uniquely identify the socket.

3.2.22 Target: The peer 1284.4 implementation to which the initiator’s command is being sent.

3.2.23 Transaction: A 1284.4 command exchange, including both the command and the reply.

3.2.24 Transaction Channel: The channel used for 1284.4 commands and replies. The primary socket identifier and the secondary socket identifier for the Transaction Channel are both 0x00.

4. Features and compliance 4.1 Overview

It is the intention of this document to complement various types of bi- directional, point- to- point links, such as those specified in IEEE Std. 1284- 1994, by providing a simple, flexible and scalable transport protocol. For the purposes of this standard, a point- to- point link may be a virtual connection over other physical topologies.

A device that implements 1284.4 functionality provides the ability to carry on multiple, concurrent, independent exchanges of information, whether control or data, over a single point- to- point link. This service is provided by use of the packet- based, non- blocking, flow control system defined in this specification.

4.2 Features

IEEE 1284.4 specifies a packet- based, bi- directional, connection- oriented, peer- to- peer communication protocol for a point- to- point link encompassing the following features:

a) Multiple, concurrent, logical channels: non- blocking, independent information exchange. b) Flow control to keep the channels independent

1) Negotiation of packet sizes. 2) Transmission rate control. Also known as pacing. 3) Specification of minimum and maximum packet sizes.

c) Service discovery 1) Dynamic query and mapping of channel address space. 2) Service names maintained in a 3 rd -party, open, persistent registry.

d) Low system overhead: small, fixed header allowing easy encoding and decoding of packets.

e) Extensibility 1) Control byte provides simple out- of- band and end- of- message signaling. 2) Within a conversation, services can be assigned to previously unallocated sockets.

f) Information exchange independence: the transport protocol is not dependent upon the data being exchanged.

g) Physical link independence: the protocol can be used in conjunction with any physical link, provided a data link layer of sufficient functionality is available (see clause 7 - Data link service requirements).

4.3 Compliance criteria

A 1284.4- compliant device shall provide all commands and functionality in clause 5 - Theory of operation of the 1284.4 protocol and clause 6 - 1284.4 Transactions and shall use a data link that meets the requirements enumerated in clause 7 Data link service requirements. 1284.4- compliant devices are not required to implement multiple outstanding transactions (see 5.5.6 Multiple Outstanding Transactions)

4.4 MLC compatibility criteria

IEEE 1284.4 is based upon the MLC protocol developed by Hewlett- Packard CompanyÔ. MLC devices are not necessarily compliant with IEEE 1284.4. For details on the MLC protocol, refer to Annex A - Bibliography.

5. Theory of operation of the 1284.4 protocol 5.1 Overview

1284.4 is a credit- based transport protocol. It provides a mechanism to establish, configure, and control communication between two endpoints. It provides this functionality through a well- defined packet structure and transaction protocol. 1284.4 transactions are symmetrical: each command has a corresponding reply.

1284.4 transports client data on logical channels. These logical channels are multiplexed on a single physical link. Client data is exchanged over data channels. 1284.4 transactions are exchanged over the 1284.4 Transaction Channel. All client data and 1284.4 transactions are encapsulated in packets. Packet transfer is managed using a credit- based flow control process to pace the exchange.

1284.4 also provides a service discovery mechanism to dynamically map service names to socket numbers.

5.2 General packet structure

All 1284.4 packets follow the general structure illustrated in Table 1. Each packet shall contain the 6- byte header and 0 or more data bytes. The packet header contains 5 fields detailed in Table 2: PSID, SSID, Length, Credit, and Control. To eliminate ambiguity, all numbers in the following descriptions that are in hexadecimal are designated beginning with “0x” and are in big- endian byte order. Packet fields are listed in the order they are transmitted reading from left to right. The length includes the header. The maximum amount of data that may be transmitted in the Payload field is 65,529 bytes (0xFFF9). The offset and length values specified in Table 2 are unsigned integers.

Table 1-- 1284.4 packet structure Header Payload

PSID 1 byte SSID

1 byte Length 2 bytes Credit

1 byte Control 1 byte 0- 0xFFF9 bytes

Table 2-- 1284.4 packet field descriptions Name Offset Length Description

Primary Socket ID (PSID) 0x00 1 byte An unsigned byte that indicates from which or to

which primary socket ID a packet is directed. Secondary Socket ID (SSID) 0x01 1 byte An unsigned byte that indicates from which or to

which secondary socket ID a packet is directed. Length 0x02 2 bytes An unsigned word that specifies the length, in bytes,

of the entire packet. The length includes the packet header. Valid values range from 0x0006 to 0xFFFF. Credit 0x04 1 byte A piggyback credit field that specifies the number of

additional packet credits the initiator is issuing to the target for data sent by the target on the channel indicated by the PSID and SSID fields. Control 0x05 1 byte A bit field containing information for controlling

8 operation of the 1284.4 protocol. It is a bit- encoded

field with the following definitions: Bit( s) Definition 7- 2 Reserved (0) 1 0 = Normal packet

1 = End- of- message packet 0 0 = Normal packet

1 = Out- of- band packet Payload 0x06 0- 65,529

bytes If PSID and SSID indicate the 1284.4 Transaction channel, the payload field contains a 1284.4

command or reply. If PSID and SSID indicate any other channel, the payload field contains data for that channel.

5.3 Communication procedures 5.3.1 1284.4 conversation management

A conversation is the set of interactions between two 1284.4 peers during the period of time bracketed between corresponding Init and Exit transactions.

The following sections describe how 1284.4 conversation management is handled, including the 1284.4 transactions that are used to establish and terminate the conversation. Once the conversation is established, 5.3.2 - Channels explains how the channels are opened, data is transferred, and channels are closed. Details of the transactions are discussed in clause 6 1284.4 Transactions.

5.3.1.1 Conversation initiation

When one 1284.4 peer wishes to establish a 1284.4 conversation, it may do so by initiating an Init transaction on the 1284.4 transaction processor channel. The target of the Init transaction will complete the transaction.

The device that generated the successful Init transaction becomes the primary device for the duration of the 1284.4 conversation. The device that completes the Init transaction becomes the secondary device for the duration of the 1284.4 conversation.

During this exchange each side of the link indicates which revision of the protocol it supports. All 1284.4 implementations shall support the 0x10 revision of the protocol defined by this standard.

5.3.1.2 Conversation termination

The Exit transaction is used as a companion to the Init transaction. It is used to terminate 1284.4 conversations. The graceful termination process is to first complete all outstanding transactions and close all open channels, and then to initiate an Exit transaction.

5.3.2 Channels

A channel is defined as a logical connection between two socket endpoints. The minimum number of supported channels is one: the 1284.4 Transaction Channel. The maximum number of channels is 65026 (255* 255+ 1). Implementations may support fewer channels.

5.3.2.1 Socket IDs

A primary socket ID (PSID) and a secondary socket ID (SSID) are used to identify the endpoints of a specific channel on which communication occurs. Socket IDs range from 0x00 to 0xFF. Communication between 1284.4 peers occurs on the 1284.4 Transaction Channel. The PSID and SSID for the Transaction Channel are both 0x00.

9 Other sockets are dynamically allocated by 1284.4 peers and assigned to applications wishing to

communicate with services on the other side of the link. Service Discovery (see 5.4) provides a mechanism used to locate those services. Unlike other channels, the Transaction Channel is assumed to be open when 1284.4 is initialized. No open or close of the Transaction Channel is allowed. See 5.3.2.2 - Packet size and 5.5.5 - 1284.4 transaction channel flow control for details on the transaction channel.

5.3.2.2 Packet size

The maximum size of packets in both primary- to- secondary and secondary- to- primary directions on the 1284.4 transaction channel is fixed at 64 bytes (6 byte header plus up to 58 bytes for the commands and replies). Fewer than 64 bytes may be sent in a 1284.4 transaction packet.

The maximum packet size on all other channels is limited by the two- byte length field to a maximum of 65,535 bytes (6 byte header plus up to 65,529 bytes of data). The actual maximum packet sizes supported will be implementation specific. When a channel is opened the maximum sizes of both primary- to- secondary and secondary- to- primary packets are negotiated and can be different. Packets smaller than the negotiated maximum size may be sent.

The minimum packet size is 6 bytes (6- byte header plus zero bytes of data).

5.3.2.3 Opening a channel

Once the 1284.4 conversation has started, channels may be established between endpoints on the 1284.4 peers. Channels are established using the OpenChannel transaction. Data packets may be transmitted on a channel only while that channel is open.

5.3.2.4 Channel credit

Credit is the fundamental mechanism by which the flow of data on 1284.4 channels is controlled (see 5.5 - Data transfer and flow control). A receiving 1284.4 peer, having knowledge of how many packets it can accept, uses credit to control the number of packets the sender can transmit across each open channel. Using credit to control the flow of data allows 1284.4 to avoid the overhead of interlocked send- receive- acknowledgment transmissions. This provides a simple mechanism for the receiver to prevent the sender from overwhelming its resources with packet transmissions. Credit is granted by OpenChannel, Credit, or CreditRequest transactions, or by piggyback credit in a packet.

5.3.2.5 Channel data exchange

Once a channel is open and credit has been granted, data packets may be freely exchanged between the two endpoints as long as the sender has credit to do so. Credit may be piggybacked in the data packets. If the data stream is bi- directional (i. e., data is flowing in a primary- tosecondary direction as well as a secondary- to- primary direction), piggybacking credit reduces the crediting traffic.

5.3.2.6 Closing a channel

When either 1284.4 peer determines the channel is no longer necessary, it closes the channel by initiating a CloseChannel transaction.

5.3.3 Special Data Packets 5.3.3.1 End- of- message Packets

Packets can be marked as the end of a message by setting the "End- of- message Packet" flag in the packet header. The sending client indicates which packets are to be marked end- ofmessage. The 1284.4 peer transport will pass the end- of- message indication to the receiving

10 client. End- of- message data shall not be split across multiple packets. End- of- message data shall

not be combined with non end- of- message data. All data shall be processed in order. All other processing of end- of- message data shall be in the same manner as non end- of- message data. End- of- message packets are not supported on the 1284.4 Transaction Channel.

5.3.3.2 Out- of- band Packets

Packets can be marked as out- of- band by setting the "Out- of- band Packet" flag in the packet header. The sending client indicates which packets are to be marked out- of- band. The 1284.4 peer transport will pass the out- of- band indication to the receiving client. Out- of- band data shall not be split across multiple packets. Out- of- band data shall not be combined with in- band data. All data shall be processed in order, regardless if it is in- band or out- band. All other processing of out- of- band data shall be in the same manner as non out- of- band data. Out- of- band packets are not supported on the 1284.4 Transaction Channel.

5.3.4 Errors 5.3.4.1 Error indications

Two mechanisms are provided for communicating errors to the 1284.4 peer. Errors detected within a transaction can be communicated in the transaction reply. Other errors can be communicated using the Error packet.

5.3.4.2 Response time

There are no response time requirements specified by the 1284.4 protocol. Implementers should consider using timers to avoid potential deadlock situations.

5.3.4.3 Other Error Conditions

Packets other than Init received outside of a conversation shall be ignored. The implementer shall handle any other unspecified error conditions.

5.4 Service discovery 5.4.1 Overview

Service discovery provides a standard method for 1284.4 client applications to locate a particular service application. It provides the ability to dynamically determine service name to socket ID mapping.

5.4.2 Service names

Canonical names of services are maintained by an administrative authority. Names may be reserved by vendors through the administrative authority, along with a description of the service functionality. IEEE 1284.4 registered service names shall be expressed within the 7- bit ASCII character set with a maximum length of 40 characters. Service names are limited to the set of uppercase letters, digits, and the punctuation character hyphen. They must start with a letter, and end with a letter or digit. The registry process is defined in Annex B - Service Names Registry.

5.4.3 Service Discovery protocols

Service Discovery is supported through the GetSocketID and GetServiceName transactions. These complementary transactions allow name- to- socket and socket- to- name conversions.

5.5 Data transfer and flow control 5.5.1 Introduction

Within the context of 1284.4, flow control ensures that a sender only sends data when the receiver is ready to accept the data. This prevents a channel from blocking other channels. It also allows the transport layer to avoid retransmitting data. To provide flow control in 1284.4, the receiver informs the sender how much data can be sent. The sender then limits the amount it sends to this value.

The maximum amount of data that can be sent is communicated in two steps. First, the maximum size of the packets to be exchanged is negotiated. Second, during data transfer, the receiver of the data communicates to the sender the number of packets that can be sent (credits). The product of the maximum packet size and the number of credits specifies the maximum amount of data that can be sent by the sender at one time. The maximum size of packets remains constant while the channel is open. The receiver enables further data transfer by granting more credits to the sender.

5.5.2 Packet size negotiation

Packet size negotiation sets the maximum size of packets, per channel, in both the primary- tosecondary and secondary- to- primary directions. This is done when the connection is established, using the OpenChannel transaction. The packet size can differ with direction. A zero- length packet size indicates that no data packets will be sent in that direction. The maximum size of packets remains constant while the channel is open. Packet size negotiation allows optimization of data transfers in the 1284.4 conversation.

5.5.3 Credit

The receiver grants credit to the sender to indicate that the receiver is prepared to accept a specific number of data packets. Credit is associated with packets on a one- for- one basis; i. e. one credit equals one packet. An endpoint may only send data across a channel if it has the credit to do so.

Credit used for 1284.4 communications is additive. When a sender is granted credit, it adds the additional credit to any unused credit it has already been granted. As the sender sends packets, it subtracts the corresponding credits from its available credit. Once a sender’s credit reaches zero, it shall not send any more packets until it is granted more credit for that channel.

Initial credit can be granted in the OpenChannel transaction. Once a channel is open, credit can be granted via a Credit transaction or requested via a CreditRequest transaction. To avoid the overhead of these explicit credit commands, credit can also be granted by piggybacking credit in 1284.4 packets. All outstanding credit for a given channel is implicitly discarded upon the completion of a CloseChannel transaction.

Flow control of the 1284.4 conversation is controlled by 1284.4 peers managing the credit by using the modes detailed in 5.5.4 - 1284.4 Data flow control and preventing deadlock as described in 5.5.7 - Deadlock avoidance.

5.5.4 1284.4 Data flow control

The sender controls a parameter to manage the receiver’s granting of credit. The sender sets this parameter using a field in the OpenChannel and CreditRequest commands. The receiver grants credit via the OpenChannelReply, Credit, or CreditRequestReply commands, or by piggybacking credit in a data packet.

12 The credit control parameter is called Maximum Outstanding Credit. Maximum Outstanding Credit

is the maximum amount of credit that the sender will need at any given time. The receiver shall attempt to maintain the sender’s credit balance equal to the value of this parameter.

The initial value of the Maximum Outstanding Credit parameter is set by the OpenChannel transaction. The sender may subsequently change the credit parameter at any time by sending a CreditRequest command. Changing the Maximum Outstanding Credit parameter does not change the available credit that the sender has already accumulated.

The Maximum Outstanding Credit parameter defines the following modes: a) “No credit” mode: when the Maximum Outstanding Credit parameter is set to 0x0000 the

sender is asking the receiver to send no credit. This may be used at the start of communications by an OpenChannel command when the sender wants to open a channel prior to having data ready to send and does not want to burden the receiver with having to supply credit until it is needed. It may also be used at the end of a channel packet exchange, e. g. the sender wishes to keep the channel open but has no more data to send at that time.

b) “Unlimited credit” mode: when the Maximum Outstanding Credit parameter is set to 0xFFFF, the sender is asking the receiver to send as much credit as possible.

This may be used when the sender has a large or unknown number of packets to send. As it approaches the end of job, the sender may monitor the number of packets left to be sent so that it can switch to “no credit” mode.

c) “Maintain credit” mode: when the Maximum Outstanding Credit is in the range 0x0001 to 0xFFFF, the receiver will try to keep the sender’s outstanding credit at the amount specified by the Maximum Outstanding Credit parameter.

This mode may be used when the sender will be sending bursts of packets, where the burst size will never exceed the Maximum Outstanding Credit parameter. Since the maximum number of credits needed at any time is known, the receiver can efficiently manage its buffers.

The sender is not required to use all of the above modes. For example, the sender may use unlimited credit mode for every channel and allow the receiver to clean up resources only as channels are closed. The sender may also start in “no credit” mode, switch to “maintain credit” mode to send bursts of packets, and finish by switching back to “no credit” mode. The three modes provide the sender with flexibility in managing its need for credit and not burden the receiver with unnecessary requests or crediting.

Table 3 and Table 4 are examples of flow control of 1284.4 data packets associated with opening a channel between primary and secondary 1284.4 peers, granting initial credit, sending data, granting additional credit and closing the channel. Time increases with each row as you move down the tables from top to bottom. In addition, only the sending of packets is shown. The reception of packets is implied (e. g., an Init packet is sent by the primary 1284.4 peer but the tables do not show the secondary 1284.4 peer receiving it). The tables do not show the transactions required to establish the 1284.4 conversation. Transaction channel flow control is detailed in 5.5.5 - 1284.4 transaction channel flow control.

Table 3 is an example of a unidirectional channel. Unidirectional channels are used when data flows in only one direction across the link. Common uses of unidirectional channels include print data and scan data.

Table 3-- Flow control of 1284.4 data packets (unidirectional channel)

Time Primary 1284.4 peer

Secondary 1284.4 peer

Primary peer data credit

Secondary peer data credit

0 0 0 1 OpenChannel

(unlimited credit mode) 0 0 2 OpenChannelReply

grant 5 credits 0+ 5= 5 0 3 Primary To Secondary

Data Packet 1 5- 1= 4 0 4 Primary To Secondary

Data Packet 2 4- 1= 3 0 5 Primary To Secondary

Data Packet 3 3- 1= 2 0 6 Credit

grant 2 credits 2 0 7 CreditReply 2+ 2= 4 0 8 Primary To Secondary

Data Packet 4 4- 1= 3 0 9 Primary To Secondary

Data Packet 5 3- 1= 2 0 10 CloseChannel 2 0

11 CloseChannelReply 0 0 Table 4 is an example of a bidirectional channel. Bidirectional channels are used when data flows in both directions across the link. Common uses of bidirectional channels include control, status, and other request- reply service.

Table 4-- Flow control of 1284.4 data packets (request- reply channel) Time Primary 1284.4

peer Secondary 1284.4

peer Primary peer

data credit

Secondary peer data credit

0 0 0 1 OpenChannel

(maintain credit mode max outstanding credit = 1)

0 0 2 OpenChannelReply

grant 1 credit (maintain credit mode - max outstanding credit = 1)

0+ 1= 1 0 5 Primary To Secondary

Packet1 Piggyback 1 credit

1- 1= 0 0+ 1= 1 8 Secondary To Primary

Packet1 piggyback 1 credit

0+ 1= 1 1- 1= 0 5 Primary To Secondary

Packet2 Piggyback 1 credit

1- 1= 0 0+ 1= 1

14 8 Secondary To Primary

Packet2 piggyback 1 credit

0+ 1= 1 1- 1= 0 10 CloseChannel 1 0 11 CloseChannelReply 0 0

5.5.5 1284.4 transaction channel flow control

Flow control for the transaction channel is similar to flow control for data channels, with the following exceptions:

a) 1284.4 command and reply packets have a maximum size of 64 bytes. b) The transaction channel is always open. Neither OpenChannel nor CloseChannel

transactions of the transaction channel are permitted. c) Upon system initialization and after a successful Init, there is credit on the transaction

channel for 1 command in each direction. Commands contain piggyback credit of exactly one (1), which is used for the reply to that command. Replies contain piggyback credit of exactly one (1), which is used for the next command. d) The transaction channel defaults to “maintain credit” mode, with a Maximum Outstanding

Credit of one (1) (see 5.5.4 - 1284.4 Data flow control). e) Transaction channel credit shall be used to complete outstanding transactions before it is

used to issue new transactions. Only when there is more credit than there are pending replies can a new transaction be issued. f) Error and Init commands can always be sent. Credit balances are unaffected by the Error

command. The Init command resets the credit balance to one (1). In the following tables, only the sending of packets is shown. The reception of packets is implied (e. g., an Init packet is sent by the primary 1284.4 peer but the table does not show the secondary 1284.4 peer receiving it).

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 Time Primary 1284.4

peer Secondary

1284.4 peer Primary peer

transaction channel credit

Secondary peer transaction channel credit

0 Don’t care Don’t care 1 Init Don’t care 1 2 InitReply 1 1 3 OpenChannel 1- 1= 0 1+ 1= 2

4 OpenChannelReply 0+ 1= 1 2- 1= 1 5 CloseChannel 1+ 1= 2 1- 1= 0 6 CloseChannelReply 2- 1= 1 0+ 1= 1

5.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

15 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 5.5.5 - 1284.4 transaction channel flow control as follows:

a) 1284.4 implementations may request multiple outstanding transactions by setting Maximum Outstanding Credit to a higher value using a CreditRequest command. Implementations 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.

Table 6-- Flow control of 1284.4 transaction packets (multiple outstanding transactions) Time Primary 1284.4 peer Secondary 1284.4 peer Primary peer

transaction channel credit

Secondary peer transaction channel credit

0 Don’t care Don’t care 1 Init Don’t care 1

2 InitReply 1 1 3 CreditRequest

Request MaximumOutstandingCred it of 3 on transaction channel

1- 1= 0 1+ 1= 2 4 CreditRequestReply

Grant 0 additional credits on transaction channel

0+ 1= 1 2- 1= 1 5 Credit

Grant 2 additional credits on transaction channel

1+ 1+ 2= 4 1- 1= 0 6 CreditReply 4- 1= 3 0+ 1= 1 7 GetSocketID "Service A" 3- 1= 2 1+ 1= 2 8 GetSocketID "Service B" 2- 1= 1 2+ 1= 3 9 GetSocketIDReply "Service A" 1+ 1= 2 3- 1= 2 10 GetSocketIDReply "Service B" 2+ 1= 3 2- 1= 1 11 OpenChannel "Service A" 3- 1= 2 1+ 1= 2 12 OpenChannel "Service B" 2- 1= 1 2+ 1= 3 13 OpenChannelReply "Service B" 1+ 1= 2 3- 1= 2 14 OpenChannelReply "Service A" 2+ 1= 3 2- 1= 1

5.5.7 Deadlock avoidance

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.

6. 1284.4 Transactions 6.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.

6.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 Transaction Command a Reply a Purpose

Init 0x00 0x80 Establish a 1284.4 conversation. OpenChannel 0x01 0x81 Open a channel between a primary and

secondary socket and set the initial crediting mode. CloseChannel 0x02 0x82 Close a channel between a primary and

secondary socket. Credit 0x03 0x83 Grant credit on a specific channel. CreditRequest 0x04 0x84 Request credit for, and set the credit mode of,

a specific channel. 0x05 0x85 Deprecated – do not use b 0x06 0x86 Deprecated – do not use b 0x07 0x87 Deprecated – do not use b Exit 0x08 0x88 Terminate the current 1284.4 conversation GetSocketID 0x09 0x89 Request the socket ID of the specified service. GetServiceName 0x0A 0x8A Request the name of the service on the

specified socket. Vendor Specific 0x50- 0x6F 0xD0- 0xEF Reserved for private vendor extensions. Error 0x7F Indicates an unrecoverable error has occurred. a Values not defined in this standard are reserved. b These values are used by Hewlett- Packard’s MLC protocol and are deprecated for compatibility

purposes.

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

Table 8- Transaction result value summary Value Result

0x00 The command was successful. 0x01 Unable to begin 1284.4 conversation at this time. The initiator can retry at a later time. 0x02 Unable to support requested revision. The initiator can attempt to negotiate to a

common revision. 0x03 The command was rejected because the requested channel was the 1284.4 transaction

channel, which cannot be closed. 0x04 Sufficient resources to support the requested connection are not currently available. The

channel is not open. 0x05 The connection has been denied. The channel is not open. 0x06 This channel is already open. The channel remains open, with credit unchanged by the

OpenChannel transaction. 0x07 Credit overflow – the specified credit causes the total outstanding credit for this direction

on this channel to exceed 0xFFFF. On a credit overflow failure the target shall keep its credit count as it was before the credit command. The credit is ignored. 0x08 The command was rejected because this channel is not open. 0x09 There is no service on the specified socket. The channel is not open. 0x0A Service name to socket ID mapping failed, either because the service was not available

(GetSocketID) or there was no service on the specified socket (GetServiceName). 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 Init. 0x0C One or both of the packet sizes requested was invalid. (0x0001- 0x0005) The channel is

not open. 0x0D The packet sizes requested in both directions were 0x0000. No data can be transferred.

The channel is not open. 0x0E The command was rejected because the requested credit mode is not supported on the

specified channel.

6.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.

6.3.1 Init

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

The initiator of the Init transaction 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 below.

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 transaction channel. If more than one Init command is received, only the credit from the final Init is valid.

Device A Device B Init Init InitReply (fail) InitReply (fail)

Init InitReply (success)

20 If there is no reply to the Init command, the initiator should 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 Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0008 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x00 Revision a 0x07 0x10

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 0x10. Future revisions shall be greater than 0x10. All implementations are required to support the base (0x10) revision of the 1284.4 protocol.

Table 10-- InitReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0009 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x80 Result 0x07 (see Table 11) Revision a 0x08 0x10

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.

Table 11-- InitReply result values Value Result

common revision.

21 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 Init.

6.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 gracefully, 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 gracefully, 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 5.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 Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0007 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x08

Table 13-- ExitReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0008 Credit 0x04 0x00 Control 0x05 0x00 Command 0x06 0x88 Result a 0x07 (See Table 14)

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

Table 14-- ExitReply result values Value Result

0x00 The command was successful.

6.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 Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000A Credit 0x04 0x00 Control 0x05 0x00 Command 0x06 0x7F ErrorPSID a 0x07 0x00- 0xFF ErrorSSID b 0x08 0x00- 0xFF ErrorCode c 0x09 (See Table 16)

a Specifies the PSID of the packet in which the error was detected. b Specifies the SSID of the packet in which the error was detected. c Specifies what type of error has occurred. This field can take on the values listed in Table 16.

Table 16-- Error command ErrorCode values ErrorCode Error description

0x80 A malformed packet was received. All fields in the packet shall be ignored. 0x81 A packet was received for which no credit had been granted. The packet was

ignored. 0x82 A 1284.4 reply was received that could not be matched to an outstanding

command. The reply was ignored. Credit granted in the reply was ignored. 0x83 A packet of data was received that was larger than the negotiated maximum size

for the socket indicated. The data was ignored 0x84 A data packet was received for a channel that was not open. 0x85 A reply packet with an unknown Result value was received. 0x86 Piggybacked credit received in a data packet caused a credit overflow for that

channel. 0x87 An unknown 1284.4 command or reply was received. Any piggybacked credit was

ignored 0x88 A non- zero length packet of data was received in a direction that has its maximum

packet size set to 0.

6.4 Connection Control Transactions

A connection is a persistent communications path between two endpoints. 1284.4 connections consist of a channel specified by primary and secondary socket identifiers. This section describes the 1284.4 transactions that are used to discover endpoints, and establish, manage and terminate connections.

6.4.1 GetSocketID

This transaction is used to request the socket ID for a specified service. The initiator of the GetSocketID transaction begins the transaction by sending a GetSocketID command with the specified service name. Upon receiving the GetSocketID command, the target of the transaction locates the specified service and sends the GetSocketIDReply. Requesting the socket ID of a zero- length service name shall result in an unsuccessful completion.

Once a service has been reported to be mapped to a particular socket ID, that mapping shall remain unchanged until the 1284.4 conversation is terminated. No other service shall be mapped to that particular socket ID. The mapped service may be unbound from that particular socket ID, but may not be mapped to any other socket ID. If it is again bound during the same conversation, it will be mapped to the same socket ID.

Multiple GetSocketID transactions may be outstanding at any time, if credit to issue them is available on the transaction channel (see 5.5.5 - 1284.4 transaction channel flow control).

Service names are between 1 and 40 (0x28) bytes and are character restricted as per 5.4.2 Service names. Service names are registered using the mechanism defined in Annex B - Service Names Registry.

Table 17 and Table 18 show the contents of the GetSocketID and GetSocketIDReply packets, including the packet header.

Table 17-- GetSocketID command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0007 + length of service name Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x09 ServiceName 0x07 (service name)

Table 18-- GetSocketIDReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0009 + length of service name Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x89 Result a 0x07 (see Table 19) SocketID b 0x08 0x00- 0xFF

26 ServiceName 0x09 (service name)

a Indicates the outcome of the GetSocketID transaction. This field can take on the values shown in Table 19. b The socket ID of the specified service. This field is not valid if the specified service does not

exist.

Table 19-- GetSocketIDReply result values Value Result

0x00 The command was successful. 0x0A Service name to socket ID mapping failed, either because the service was not available

(GetSocketID) or there was no service on the specified socket (GetServiceName).

6.4.2 GetServiceName

This transaction is used to request the name of the service on the specified socket. The initiator of the GetServiceName transaction begins the transaction by sending a GetServiceName command with the specified socket ID. Upon receiving the GetServiceName command, the target of the transaction identifies the service on the specified socket and sends the GetServiceNameReply.

Multiple GetServiceName transactions may be outstanding at any time, if credit to issue them is available on the transaction channel (see 5.5.6 - Multiple Outstanding Transactions).

Service names are between 1 and 40 (0x28) bytes and are character restricted as per 5.4.2 Service names. Service names are registered using the mechanism defined in Annex B - Service Names Registry.

Table 20 and Table 21 show the contents of the GetServiceName and GetServiceNameReply packets, including the packet header.

Table 20-- GetServiceName command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0008 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x0A SocketID a 0x07 0x00- 0xFF

a The socket ID of the requested service.

Table 21-- GetServiceNameReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0009 + length of service name Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x8A Result a 0x07 (see Table 22 ) SocketID b 0x08 0x00- 0xFF ServiceName 0x09 (service name) c

a Indicates the outcome of the GetServiceName transaction. This field can take on the values shown in Table 22. b The socket ID of the requested service. c A successful completion with a zero- length service name indicates an unnamed service on this

socket. This field is not valid if there is no service mapped to this socket.

Table 22-- GetServiceNameReply result values Value Result

0x00 The command was successful. 0x0A Service name to socket ID mapping failed, either because the service was not available

(GetSocketID) or there was no service on the specified socket (GetServiceName).

6.4.3 OpenChannel

This transaction is used to open and configure a channel between two 1284.4 endpoints. The initiator of the transaction starts by sending an OpenChannel command with the socket IDs specifying the desired channel. Upon receiving the OpenChannel command, the target of the transaction checks the validity of the command, allocates the necessary resources for the channel, and sends the OpenChannelReply. The target shall choose valid maximum packet sizes for the channel, less than or equal to the maximum packet sizes requested by the initiator. A maximum packet size of zero (0) indicates data will not be sent in that direction, although zerolength data packets may still be sent to carry piggyback credit (see 5.5.3 - Credit). An OpenChannel command with maximum packet sizes of zero (0) in both directions is not supported as it results in a channel on which no data can be transferred. The channel is considered to be open only after the completion of a successful OpenChannel transaction.

If both 1284.4 peers initiate OpenChannel transactions for the same channel simultaneously, the transactions shall complete with the minimum of the packet sizes requested in both OpenChannel commands. This results in a single open channel.

Since the 1284.4 transaction channel is always open, it does not require an OpenChannel transaction. An OpenChannel transaction for the transaction channel shall be handled the same as any other OpenChannel transaction received for a channel that is already open.

A peer shall initiate only one outstanding OpenChannel transaction per channel. Multiple OpenChannel transactions may be outstanding at any time, if each transaction refers to a different channel and credit to issue them is available on the transaction channel (see 5.5.6 - Multiple Outstanding Transactions).

Table 23 and Table 24 show the contents of the OpenChannel and OpenChannelReply packets, including the packet header.

Table 23-- OpenChannel command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000F Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x01 SocketID (primary) a 0x07 0x01- 0xFF SocketID (secondary) b 0x08 0x01- 0xFF MaximumPrimaryToSecondaryPacketSize c 0x09 0x0000 or 0x0006- 0xFFFF MaximumSecondaryToPrimaryPacketSize d 0x0B 0x0000 or 0x0006- 0xFFFF MaximumOutstandingCredit e 0x0D 0x0000- 0xFFFF

a Specifies the socket of the requested channel on the primary 1284.4 peer. b Specifies the socket of the requested channel on the secondary 1284.4 peer. c Indicates the maximum size of data packets in the primary- to- secondary direction. A value of 0x0000 indicates primary- to- secondary data packets are not supported. d Indicates the maximum size of data packets in the secondary- to- primary direction. A value of 0x0000 indicates secondary- to- primary data packets are not supported. e Indicates the maximum outstanding credit requested by the initiator of this transaction. See 5.5.3 - Credit for details on credit.

Table 24-- OpenChannelReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0012 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x81 Result a 0x07 (see Table 25 ) SocketID (primary) b 0x08 0x01- 0xFF SocketID (secondary) c 0x09 0x01- 0xFF MaximumPrimaryToSecondaryPacketSize d 0x0A 0x0000 or 0x0006- 0xFFFF MaximumSecondaryToPrimaryPacketSize e 0x0C 0x0000 or 0x0006- 0xFFFF MaximumOutstandingCredit f 0x0E 0x0000- 0xFFFF Credit g 0x10 0x0000- 0xFFFF

a Indicates the outcome of the OpenChannel transaction. This field can take on the values shown in Table 25. b Specifies the socket of the requested channel on the primary 1284.4 peer. c Specifies the socket of the requested channel on the secondary 1284.4 peer. d Indicates the maximum packet size that will be used to send data from the primary to the

secondary 1284.4 peer. A value of 0x0000 indicates primary- to- secondary data packets for this channel will not be used. If the result value indicates an error, this field has no meaning. e Indicates the maximum packet size that will be used to send data from the primary to the

secondary 1284.4 peer. A value of 0x0000 indicates secondary- to- primary data packets for this channel will not be used. If the result value indicates an error, this field has no meaning. f Indicates the maximum outstanding credit requested by the target of this transaction. See 5.5.3 Credit

for details on credit. g Indicates initial credit that the receiver of this command is granting the sender. See 5.5.3 - Credit for details on credit.

Table 25-- OpenChannelReply result values Value Result

0x00 The command was successful. 0x04 Sufficient resources to support the requested connection are not currently available. The

channel is not open. 0x05 The connection has been denied. The channel is not open. 0x06 This channel is already open. The channel remains open, with credit unchanged by the

OpenChannel transaction. 0x09 There is no service on the specified socket. The channel is not open. 0x0C One or both of the packet sizes requested was invalid. (0x0001- 0x0005) The channel is

not open. 0x0D The packet sizes requested in both directions were 0x0000. No data can be

transferred. The channel is not open.

6.4.4 Credit

The Credit transaction is part of the 1284.4 flow control mechanism. This transaction is used to grant credit for a specific channel to the sending endpoint. See 5.5 - Data transfer and flow control for more details on flow control.

A peer shall have no more than one outstanding Credit transaction per channel. Multiple Credit transactions may be outstanding at any time, if each transaction refers to a different channel and credit to issue them is available on the transaction channel (see 5.5.6 - Multiple Outstanding Transactions).

Table 26 and Table 27 show the contents of the Credit and CreditReply packets including the packet header.

Table 26-- Credit command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000B Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x03 SocketID (Primary) a 0x07 0x00- 0xFF SocketID (Secondary) b 0x08 0x00- 0xFF Credit c 0x09 0x0000- 0xFFFF

a Specifies the socket on the primary 1284.4 peer of the channel for which credits are being issued. b Specifies the socket on the secondary 1284.4 peer of the channel for which credits are being

issued. c Indicates additional credit that the sender of this command is granting to the recipient of the command.

Table 27-- CreditReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000A Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x83 Result a 0x07 (See Table 28) SocketID (primary) b 0x08 0x00- 0xFF SocketID (secondary) c 0x09 0x00- 0xFF

a Indicates the outcome of the Credit command. This field can take on the values shown in Table 28. b Specifies the socket on the primary 1284.4 peer of the channel for which credits are being

issued. c Specifies the socket on the secondary 1284.4 peer of the channel for which credits are being issued.

Table 28-- CreditReply result values Value Result

0x00 The command was successful. 0x07 Credit overflow – the specified credit causes the total outstanding credit for this direction

6.4.5 CreditRequest

The CreditRequest transaction is used to request credit from the receiving endpoint. The transaction is also used to modify the Maximum Outstanding Credit parameter (see 5.5.4 - 1284.4 Data flow control). If the credit mode is set to "unlimited" or "maintain credit" modes, the target of the CreditRequest transaction shall grant some or all of the requested credit as quickly as possible, either through the CreditRequestReply or a subsequent Credit transaction. Credit can be requested at any time.

A peer shall initiate only one outstanding CreditRequest transaction per channel. Multiple CreditRequest transactions may be outstanding at any time, if each transaction refers to a different channel and credit to issue them is available on the transaction channel (see 5.5.6 Multiple Outstanding Transactions).

A MaximumOutstandingCredit value of zero (0) is not supported on the 1284.4 Transaction Channel.

Table 29 and Table 30 summarize the contents of the CreditRequest and CreditRequestReply packets, including the packet header.

Table 29-- CreditRequest command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000B Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x04 SocketID (primary) a 0x07 0x00- 0xFF SocketID (secondary) b 0x08 0x00- 0xFF MaximumOutstandingCredit c 0x09 0x0000- 0xFFFF

a Specifies the socket on the primary 1284.4 peer of the channel for which credit is being requested. b Specifies the socket on the secondary 1284.4 peer of the channel for which credit is being

requested. c Indicates the maximum outstanding credit requested by the sender of this command. See 5.5.3 - Credit for details on credit.

Table 30-- CreditRequestReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000C Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x84 Result a 0x07 (See Table 31) SocketID (primary) b 0x08 0x00- 0xFF SocketID (secondary) c 0x09 0x00- 0xFF

Credit d 0x0A 0x0000- 0xFFFF

34 a Indicates the outcome of the CreditRequest command. This field can take on the value shown in

Table 31. b Specifies the socket on the primary 1284.4 peer of the channel for which credit is being requested. c Specifies the socket on the secondary 1284.4 peer of the channel for which credit is being requested. d Indicates additional credit that the sender of this reply is granting to the sender of the CreditRequest command. A value of 0x0000 is a valid credit field value and indicates no additional credit is being granted.

Table 31-- CreditRequestReply result values Value Result

0x00 The command was successful. 0x08 The command was rejected because this channel is not open. 0x0E The command was rejected because the requested credit

mode is not supported on the specified channel.

6.4.6 CloseChannel

This transaction is used to close a channel between two 1284.4 endpoints. Either 1284.4 peer can initiate a CloseChannel transaction, regardless of which peer initiated the OpenChannel transaction for the channel.

The initiator of the CloseChannel transaction begins the transaction by sending a CloseChannel command with the socket IDs of the channel it desires to close. Upon receiving the CloseChannel command, the target of the transaction waits for any outstanding transactions for this channel to complete, and then sends the CloseChannelReply. Once the target of the transaction has sent the CloseChannelReply, it may de- allocate the resources for the channel. The channel is considered to be closed only after the completion of a successful CloseChannel transaction. Once the CloseChannel transaction starts, no new 1284.4 transactions may be initiated for the specified channel, but all 1284.4 transactions for that channel must be completed before the CloseChannel transaction completes.

Data received prior to issuing or receiving a CloseChannel command shall be delivered. If both 1284.4 peers initiate CloseChannel transactions for the same channel at the same time, both CloseChannel transactions shall complete appropriately.

Since the 1284.4 transaction channel is needed for the 1284.4 conversation, it can not be closed. A peer shall initiate only one outstanding CloseChannel transaction per channel. Multiple CloseChannel transactions may be outstanding at any time, if each transaction refers to a different channel and credit to issue them is available on the transaction channel (see 5.5.6 Multiple Outstanding Transactions).

Table 32 and Table 33 show the contents of the CloseChannel and CloseChannelReply packets, including the packet Header.

Table 32-- CloseChannel command packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x0009 Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x02 SocketID (primary) a 0x07 0x01- 0xFF SocketID (secondary) b 0x08 0x01- 0xFF

a Specifies the socket on the primary 1284.4 peer of the channel that is being closed. b Specifies the socket on the secondary 1284.4 peer of the channel that is being closed.

Table 33-- CloseChannelReply packet Packet field Packet offset Field contents

PSID 0x00 0x00 SSID 0x01 0x00 Length 0x02 0x000A Credit 0x04 0x01 Control 0x05 0x00 Command 0x06 0x82 Result a 0x07 (See Table 34) SocketID (primary) b 0x08 0x01- 0xFF SocketID (secondary) c 0x09 0x01- 0xFF

a Indicates the outcome of the OpenChannel transaction. This field can take on the values shown in Table 34. b Specifies the socket on the primary 1284.4 peer of the channel that is being closed. c Specifies the socket on the secondary 1284.4 peer of the channel that is being closed.

Table 34-- CloseChannelReply result values Value Result

0x00 The command was successful. 0x03 The command was rejected because the requested channel was the

1284.4 transaction channel, which cannot be closed. 0x08 The command was rejected because this channel is not open.

7. Data link service requirements 7.1 Overview

The following section describes the data link services required by 1284.4. This specification describes the requirements but not the implementation of these services. 1284.4 places no other requirements on the data link. IEEE P1284.3 is an example of a data link that meets all of these requirements.

7.2 Required Services 7.2.1 Register/ unregister

A 1284.4 implementation shall be able to register itself with the data link. The 1284.4 implementation will identify itself as being the processor for the 1284.4 protocol by using the 1284.4 protocol ID. Only one processor for the 1284.4 protocol is permitted to be registered with a particular data link at any time. The 1284.4 implementation shall be able to unregister itself to allow another 1284.4 implementation to register itself as the 1284.4 processor for the data link.

The following is an example of register and unregister services. In the example, a request is a call from a data link client to the data link and an indication is a call from the data link to one of its clients.

DL_ Register. request ProtocolID, AsyncBlk, Handle

ProtocolID The identification number of the protocol served by this client of the data link. Only one 1284.4 client is allowed. The protocol ID for the 1284.4 protocol is registered by the Internet Assigned Number Authority and published in RFC 1700 - PPP Assigned Numbers List. Its value is 0x0285.

AsyncBlk A block of memory that contains whatever information is needed to deliver data link indications to this client. The delivery mechanism is implementation specific.

Handle The address of a container to hold the client’s handle. This handle is used to identify the client in future data link requests.

DL_ Unregister. request Handle

Handle The client’s handle as returned in DL_ Register. request.

7.2.2 Packet Data Transfer

The 1284.4 implementation shall be able to send packets of data to the 1284.4 peer. The data shall be delivered to the 1284.4 peer, and only to the 1284.4 peer, error free and in the same order as it was presented to the data link. Each 1284.4 packet shall be presented to the data link as a single data packet and delivered by the data link to the 1284.4 peer in the same form. If no 1284.4 peer exists, the data shall be discarded. Data from other data link clients shall not be delivered to either 1284.4 peer. The data link shall accept a destination device address with all data to be sent and return the source device address with all delivered data. The following is an

38 example of data transfer services. A 1284.4 implementation uses the request to send data. The

peer data link uses the indication to deliver the data to the 1284.4 peer.

DL_ Data. request Handle, DeviceAddress, Data

Handle The client’s handle as returned in the DL_ Register. request.

DeviceAddress Operating system dependent address of destination device for this data.

Data The packet of data to be delivered.

DL_ Data. indication DeviceAddress, Data

Data The packet of data passed to the peer data link through DL_ Data. request. The packet of data shall be in the same order and form as it was presented to the remote data link in the DL_ Data. request.

DeviceAddress Operating system dependent address of source device for this data. Can be used in DL_ Data. request to deliver data back to the 1284.4 peer.

7.2.3 Asynchronous operation

The 1284.4 implementation shall be able to operate asynchronously. It shall not at any time be required to poll the data link.

Annex A Bibliography

(informative) [1] IEEE Std. 1284- 1994, Standard Signaling Method for a Bi- directional Parallel Peripheral Interface for Personal Computers. [2] MLC Packet Protocol Revision 3.8, Hewlett- Packard Company. More information regarding this document can be obtained from stds- 1284@ ieee. org. [3] IEEE Std. 1284.3- 1999, Standard for Interface and Protocol Extensions to IEEE Std. 1284- 1994 Compliant Peripheral and Host Adapter Ports [4] IEEE Std. 1284.1- 1997, Standard for Transport Independent Printer/ System Interface [5] IANA Protocol and Service Names List, available both on their web- site at: http:// www. iana. org/ and on their FTP site at: ftp:// ftp. isi. edu/ in- notes/ iana/ assignments/ servicenames

[6] Winsock- 2 API available at http:// www. sockets. com.

Annex B Service Names Registry

(normative)

B. 1 Purpose and scope

This annex is provided to explain how 1284.4 implementers can register service names to provide public knowledge of services that are available and prevent different services from erroneously using the same name. IANA (Internet Assigned Numbers Authority) maintains a list of service names on the list titled “Protocol and Service Names” available both on their web- site at: http:// www. iana. org/ and on their FTP site at: ftp:// ftp. isi. edu/ in- notes/ iana/ assignments/ servicenames.

Implementers should only register service names as needed; different names for the same service should be avoided. The registry provides a method to avoid service name collisions.

B. 2 service- names list

The service- names list contains an alphabetical listing of each service name following the format as described in the service- names file:

A protocol or service may be up to 40 characters taken from the set of uppercase letters, digits, and the punctuation character hyphen. It must start with a letter, and end with a letter or digit.

Each service name is followed by a brief description of its use. Examples of existing protocols and services from the service- names file include:

Table 35— Examples of Service Names Service Name Service Description

BOOTP Bootstrap Protocol BOOTPC Bootstrap Protocol Client BOOTPS Bootstrap Protocol Server BR- SAT- MON Backroom SATNET Monitoring CFTP CFTP CHAOS CHAOS Protocol CHARGEN Character Generator Protocol IEEE- 1284- 4- TRANSACTION IEEE 1284.4 Transaction Processor (Socket 0x00)

B. 3 Registry process

Implementers of 1284.4 may follow the following process to register their service name with IANA. 1. Check the service- names file available at

ftp:// ftp. isi. edu/ in- notes/ iana/ assignments/ service- names to verify that the proposed service name has not already been registered.

2. Send e- mail using the template below to iana@ iana. org and stds- 1284@ ieee. org requesting the new service- name. The IANA web- site may provide updates to the template.

1284.4 Service name registry request template:

41 Subject: 1284.4 Service Name Registry Request

Service- name (40 characters maximum, letters/ digits/ hyphen only): Description (brief description, 1 sentence recommended) :

Contact Name (person to be contacted in case of any problems): Contact Name e- mail: Contact Name Company:

An example:

Subject: 1284.4 Service Name Registry Request Service- name: XYZ- INPUT Description: Input data stream for an XYZ

Contact Name: John Doe Contact Name e- mail: john@ anycompany. com Contact Name Company: AnyCompany, Inc.

IANA will update the list as requests are received. The 1284.4 registry coordinator will intervene only if IANA has a problem completing a request. Questions regarding the registry process can be directed by e- mail to the coordinator at stds- 1284@ ieee. org.

Annex C 1284.4 Architecture

(informative) The following figure illustrates an example of the protocol architecture of several devices using 1284.4 and other related protocols. The top of the figure shows devices on various physical links. The bottom of the figure shows applications and drivers in a host. The center of the figure shows the various protocols required to connect the applications and drivers to the devices.

Figure 1 - 1284.4 Device Architecture Fax

P/ SSID 0

P/ SSID 1

Status

P/ SSID 2

1284 MFP Fax

P/ SSID 0

P/ SSID 1

Status

P/ SSID 2

1284 MFP Data

P/ SSID 0

Status

P/ SSID 1

Scanner Print

P/ SSID 0

Control

P/ SSID 1

1394 Camera 1394.x Datalink

1394 SPI 1284.3 Datalink

AF_ 1284 LPT13: Socket

0 AF_ 1284

LPT12: Socket

1 AF_ 1284

LPT14: Socket

2 AF_ 1284

FWnm: Socket

3 LPT13: LPT12: LPT14: FWnm:

1284.4 1284.4 Datalink Interface

P/ SSID 0

Control

P/ SSID 1

Photo Application Fax

P/ SSID 0

P/ SSID 1

Status

P/ SSID 2

1284 MFP Application Data

P/ SSID 0

Status

P/ SSID 1

Scanner

EPP/ ECP Ch. X

LPT14: LPT13: LPT12:

EPP/ ECP Ch. Z EPP/ ECP Ch. X

FWnm: 1284.4 Datalink I/ F 1284.4 Datalink I/ F

Winsock I/ F LPT13: LPT14:

LPT12: FWnm: 1284.3 SPI

zip Drive (1284.3 compliant)

zip Driver 1284.3 Compliant Legacy

Printer Application

Driver Legacy

Device (Printer)

LPT15: LPT15: LPT1: LPT1:

1284.4 Applications 1284.3 Applications Legacy Parallel P t Applications

Annex D Example 1284.4 API

(informative)

D. 1 API Overview

This example Application Programming Interface (API) is sockets- based interface for use by clients and servers to access the services provided by 1284.4. The API is modeled after the Winsock- 2 interface available at http:// www. sockets. com.

1284.4 sockets and API sockets are not necessarily equivalent. 1284.4 sockets refer to an endpoint to which or from which data is transmitted. API sockets refer not only to an endpoint, but also to a particular connection to that endpoint. A pair of 1284.4 sockets, one on each end of the link, uniquely identifies a 1284.4 connection. A single API socket uniquely identifies an API connection. More than one API socket can be mapped to the same local 1284.4 socket by the 1284.4 implementation, as long as each API socket mapped to the same local 1284.4 socket specifies a connection to a different remote 1284.4 socket.

D. 2 API Services D. 2.1 Socket

Socket establishes a new endpoint. The 1284.4 layer manages the allocation of 1284.4 sockets. Neither clients nor servers need be aware of the management of 1284.4 sockets.

socket = Socket ( IN address_ family IN socket_ type)

socket A new socket allocated by the 1284.4 transport layer.

address_ family An address family specification. The address family for 1284.4 is "AF_ 12844".

socket_ type

A type specification for the new socket. The following are the only two socket_ type specifications supported for 1284.4:

· SOCK_ STREAM: Provides connection- based byte streams with an out- of- band data transmission mechanism. The transport is free to divide or aggregate client buffers. In- band data shall not be combined with out- of- band data. End- of- message data shall not be combined with non end- ofmessage data.

· SOCK_ DGRAM: Supports datagrams, which are buffers of a fixed (typically small) maximum length. These buffers are delivered to the receiving client in the exact same form as the sending client presents them to the transport. For example, if the sending client presents data in a buffer of 30 bytes, it must be delivered to the receiving client in a buffer of 30 bytes. The transport stack may limit the size of datagrams. It is not required to support segmentation and reassembly of client buffers that do not fit in a single transport packet.

Since the transports will not exchange the socket_ type at the time the connection is opened, the transport clients must set the same socket_ type for the sockets at both ends of the connection.

D. 2.2 Bind

Bind assigns a name to a socket. A server uses bind to register its name so that it can be found through service discovery. Bind will fail if service_ name is already bound to another socket.

Bind ( IN socket, IN service_ name)

socket A socket previously allocated by a call to socket().

service_ name The name by which the server wishes to be known. The name must follow the restrictions in 5.4.2 - Service names or must be an explicit 1284.4 socket number. The format of the explicit 1284.4 socket number is operating system dependent.

D. 2.3 Listen

Listen allocates space for queuing incoming connection requests.

Listen ( IN socket)

socket A socket previously allocated by a call to socket() and assigned a name or explicit socket number by a call to bind().

D. 2.4 Accept

Accept accepts new connections on a socket. When a connect request is received for that socket from the remote transport, the 1284.4 transport layer allocates a new socket for that connection and the call to accept() completes.

new_ socket = Accept ( IN socket)

new_ socket A new socket allocated for this connection by the 1284.4 transport layer.

socket A socket previously allocated by a call to socket(), assigned a name or explicit 1284.4 socket number by a call to bind(), and placed in a listen state by a call to listen().

D. 2.5 Connect

Connect opens a connection to a server.

Connect ( IN socket,

IN device_ address, IN service_ name)

socket A socket previously allocated by a call to socket().

device_ address Operating system dependent address of the device to which the connection is to be opened. The 1284.4 implementation may not interpret the device address. It may instead be passed to the appropriate data link layer for interpretation.

service_ name Name or explicit 1284.4 socket number of the service to which the connection is to be opened.

D. 2.6 Send

Send data over an open connection.

Send ( IN socket, IN data, IN out- of- band_ flag, IN end- of- message_ flag)

socket A socket to a connection opened by a call to accept() or connect().

data Buffer of data to be sent over the connection.

out- of- band_ flag Flag indicating that the data is out- of- band. 1284.4 shall process out- of- band data in the same manner as in- band data. In- band data shall not be combined with out- of- band data. The receiver of out- of- band data shall be notified that the data is out- of- band.

end- of- message_ flag Flag indicating that the data is the end of a message. 1284.4 shall process end- of- message data in the same manner as non end- of- message data. End- of- message data shall not be combined with non end- of- message data. The receiver of end- of- message data shall be notified that the data is the end of a message.

D. 2.7 Receive

Receive data over an open connection. The receive call completes when data is received or when the connection is terminated by the remote client.

Receive ( IN socket, IN OUT data, OUT out- of- band_ flag, OUT end- of- message_ flag)

46 socket

A socket to a connection opened by a call to accept() or connect(). data Buffer for data to be received over the connection.

out- of- band_ flag Flag indicating that the data is out- of- band.

end- of- message_ flag Flag indicating that the data is the end of a message.

D. 2.8 Shutdown

Disable sends and/ or receives on a socket

Shutdown ( IN socket, IN direction)

socket A socket to a connection opened by a call to accept() or connect().

direction The direction( s) to be disabled. Can be SEND, RECEIVE, or BOTH.

Shutdown() does not close the socket. Resources allocated to the socket will remain reserved until the socket is closed using CloseSocket().

D. 2.9 CloseSocket

CloseSocket releases a socket. If the socket has an open connection, the connection is closed before the socket is released.

CloseSocket ( IN socket)

socket A socket previously allocated by a call to socket() or accept().

D. 2.10 SetSockOpt

SetSockOpt sets socket options. Since the client is not required to call SetSockOpt, the implementation shall establish reasonable default values for each of the socket options.

SetSockOpt ( IN socket, IN option_ name, IN option_ value)

socket A socket previously allocated by a call to socket() or accept().

47 option_ name

The socket option for which the value is to be set. option_ value The buffer in which the value for the requested option is supplied.

Option_ name Description

outgoing packet length If there is no open connection to this socket, sets the maximum outgoing packet length 1284.4 shall attempt to establish when opening a connection to this socket. If there is an open connection to this socket, the maximum outgoing packet length may not be changed. incoming packet length If there is no open connection to this socket, sets the maximum

incoming packet length 1284.4 shall attempt to establish when opening a connection to this socket. If there is an open connection to this socket, the maximum incoming packet length may not be changed. maximum outstanding credit If there is no open connection to this socket, sets the maximum

outstanding credit value 1284.4 shall request when opening a connection to this socket (see 5.5.4 - 1284.4 Data flow control). If there is an open connection to this socket, 1284.4 shall use CreditRequest to request a change to the actual maximum outstanding credit value for the open connection.

D. 2.11 GetSockOpt

GetSockOpt returns the current socket options.

GetSockOpt ( IN socket, IN option_ name, OUT option_ value)

socket A socket previously allocated by a call to socket() or accept().

option_ name The socket option for which the value is to be retrieved.

option_ value The buffer in which the value for the requested option is to be returned.

Option_ name Description

maximum outgoing packet length

If there is no open connection to this socket, returns the maximum outgoing packet length 1284.4 shall attempt to establish when opening a connection to this socket. If there is an open connection to this socket, returns the maximum outgoing packet length 1284.4 established when opening the connection. maximum incoming packet length

If there is no open connection to this socket, returns the maximum incoming packet length 1284.4 shall attempt to establish when opening a connection to this socket. If there is an open connection to this socket, returns the maximum incoming packet length 1284.4 established when opening the connection.

48 maximum outstanding credit If there is no open connection to this socket, returns the

maximum outstanding credit value 1284.4 shall request when opening a connection to this socket (see 5.5.4 - 1284.4 Data flow control). If there is an open connection to this socket, returns the current maximum outstanding credit value for the open connection.

7.2.4 AsyncSelect()

Request notification of network events for a socket.

AsyncSelect ( IN socket, IN message, IN event_ mask) socket

A socket previously allocated by a call to socket () or accept (). message The message to be received when a network event occurs.

event_ mask A bit mask which specifies a combination of network events in which the application is interested.

Value Meaning

FD_ READ Want to receive notification of readiness for reading FD_ WRITE Want to receive notification of readiness for writing FD_ OOB Want to receive notification of the arrival of out- of- band data FD_ EOM Want to receive notification of the arrival of end- of- message data FD_ ACCEPT Want to receive notification of incoming connections FD_ CONNECT Want to receive notification of completed connection FD_ CLOSE Want to receive notification of socket closure FD_ CREDIT_ MODE Want to receive notification upon change in requested credit mode.

D. 3 API Usage D. 3.1 Servers

Servers first establish a socket by calling Socket() and then bind their service name to that socket by calling Bind(). Once the socket has been allocated, servers call Listen() to establish an incoming request queue, and then call Accept() to wait for a connection request. When a client requests a connection, Accept() will complete with a new socket for the now open connection. If the server can accept more concurrent connections, it may call Listen() again with the original socket. When the server is finished using a socket, it releases the socket by calling Shutdown() followed by CloseSocket().

Once a connection is open, servers can use Send() and Receive() to transfer data across the open connection.

D. 3.2 Clients

Clients establish a socket by calling Socket(); they need not bind a name to that socket. Once the socket has been allocated, the client can request a connection by calling Connect(). When

49 Connect() completes, the connection is open. When the client is finished using a socket, it

releases the socket by calling Shutdown() followed by CloseSocket(). Once a connection is open, clients can use Send() and Receive() to transfer data across the open connection.

D. 4 Mapping API services to 1284.4 transactions

This section describes a sample mapping of API services to 1284.4 transactions. Other mappings are possible and implementation- dependent.

D. 4.1 Socket ()

No 1284.4 transactions required. An available, local 1284.4 socket is mapped to this API socket.

D. 4.2 Bind ()