Microsoft Corporation

December 1998

Introduction

Both the infrared picture transfer (IrTran-P) image transfer protocol and the infrared line print terminal (IrLPT) printing protocol depend on the IrCOMM family of protocols and associated serial application programming interfaces (APIs). Microsoft® Windows® 2000 supports a subset of the IrCOMM functionality in order to accommodate these applications.

Infrared Data Association (IrDA) application developers are strongly encouraged to develop future protocols directly to the tiny transport protocol (TinyTP), as exposed through Winsock on Windows.

Not all IrTran-P cameras are guaranteed to work under Windows 2000. Vendors should study the constraints described in this article to ensure compatibility.

IrCOMM Overview

IrCOMM is a family of protocols that run on top of the core IrDA protocol suite. IrCOMM supports the emulation of a peer device connected using a serial or parallel cable. This emulation is from the perspective of applications that are accessing serial and parallel ports through the operating system API.

An IrCOMM implementation generally takes the form of a system-installable serial port driver. Rather than talking to real serial hardware, it uses the services exported by the core IrDA protocol stack.

The basic mechanism of IrCOMM serial-connected device emulation is: convert RS-232 serial line state change requests generated by one application into protocol messages that are communicated to the peer application through the native serial API.

In the case of modems, some of line state change protocol messages correspond to established conventions for relaying state changes from the analog side of the modem back to the computer—drop Data Carrier Detect (DCD) to signal a line carrier drop. Other line state changes are used to stop the computer from overrunning buffers in the modem, such as clear to send (CTS) and request to send (RTS).

When two systems are connected together through an RS-232 cable (no modems), ad-hoc application conventions are used to map line state changes into bi-directional flow control and application specific signaling. The Windows 95 Direct Cable Connect feature is an example of such an application.

The use of line state changes to implement flow control is largely a legacy application-to-application concept. The underlying IrDA protocols fully support flow control between the systems. Even an IrDA modem could go without lead state changes and use the underlying IrDA protocol flow control mechanisms to stop the computer from sending more data.

Figure 1. Using a Serial NULL Cable to Connect Two Systems

Figure 2. Using IrCOMM to Replace a NULL Serial Cable

IrCOMM Modes

IrCOMM is actually a family of protocols. Only the 9 Wire Mode supports the propagation of line state change information. The IrLPT protocol is used to talk to printers. 3 Wire Raw Mode and IrLPT run the core IrDA stack in exclusive mode, which precludes other applications from using the stack at the same time. 3 Wire Cooked Mode, which uses the services of IrLMP and TinyTP, does not preclude other applications from using the stack, and does not propagate line state change information. 9 Wire Mode is like 3 Wire Cooked Mode, but also supports line state change messages.

In order to achieve communication, a common mode must exist between both systems.

Figure 3. IrCOMM Internal Architecture

The philosophy behind IrCOMM was to support IrDA modems and legacy applications built on the serial API. In practice, because the serial API was the most commonly available IrDA user space API, new IrDA applications were designed around IrCOMM.

IrCOMM runs on top of a reliable protocol layer, but session establishment/release services are not exposed through serial API. Additionally, the underlying IrDA connection can be broken and re-established without this information being communicated to the application through the serial API. The result of this is that IrCOMM is not a reliable protocol in practice, and applications must be prepared to add yet another layer of reliability.

No IrDA Virtual Serial Ports on Windows 2000

Windows 2000 does not expose virtual serial ports and does not provide a general implementation of IrCOMM. There are several reasons for this:

• Many customers have difficulty with the concept of virtual ports. This is especially confusing when the serial infrared (SIR) IrDA hardware itself may need to be configured on a real serial port, and then customers must further configure their applications to use a virtual serial port.
• Multiple applications cannot share a virtual serial port. This is particularly troublesome if, for example, an IrCOMM-based application like the Microsoft HP/C Explorer or an IrTran-P file transfer application running as a background service opens the single virtual serial port and holds it open until system shutdown. No other IrDA application or driver is able to run on that system. This is true, even though the underlying IrDA protocols provide support to allow multiple applications to be waiting for incoming connections, and allow clients to select a target application at connect time through established protocol mechanisms.
• Windows 2000 IrDA connections must be supported by multiple device connections. Windows 2000 supports multiple concurrent adapters and IrDA connections to different devices, and cannot be well supported under an API and protocol that assumes only a single device connection.

The complexity and various modes of IrCOMM make real world interoperability a very tough problem.

Connection establishment and release notifications are lost through the serial API, reducing a fully error-corrected IrDA stack to the level of an unreliable serial cable.

Figure 4. Windows 2000 IrDA Architecture

Windows 2000 Support for IrLPT Printers

IrLPT printing is directly supported in Windows 2000. When IrDA is installed, an IrDA local port will appear in the local printer ports list of the Add Printer dialog. Associating a printer with this port, and then printing to that printer, will cause the system to print via IrLPT. The print monitor itself accesses the IrLPT protocol through the Winsock API. It is possible for another application to print through this same interface, although it is not expected that this will be necessary or common.

Windows 2000 Support For IrTran-P V1 Cameras

A subset of IrTran-P V1 is supported in Windows 2000. This support consists of a user space background image transfer service that accepts incoming IrTran-P images, and then writes those files to the hard disk. This service accesses the IrDA stack through Winsock. Because this service is continuously listening for incoming connections, it is not feasible for another application to use the IrCOMM services exposed for the IrTran-P server. The IrCOMM protocol itself prevents more than a single IrCOMM application at once to be listening for incoming connections.

Constraints

Windows 2000 only advertises that it supports the IrCOMM 9 Wire Mode. Cameras must support this mode to work with Windows 2000.

Cameras must be able to initiate the IrDA connection. The IrTran-P file transfer service is a listen-only service and will never try to connect to a camera. It is not be possible to initiate an outbound IrCOMM connection through any other user space application.

No lead state change information is supported. The built-in IrCOMM support consists of adding a zero byte (the simplest IrCOMM header) to the front of every outbound TinyTP message and removing and ignoring incoming IrCOMM headers. Beyond supporting IrCOMM TinyTP connection syntax, no other IrCOMM support is provided. Cameras must use native TinyTP flow control mechanisms (9 Wire Mode rules).

This is identical to the level of IrCOMM support in Windows CE.

IrTran-P on TinyTP Support

The Windows 2000 IrTran-P service also supports operation directly over TinyTP. A camera wishing to support this mode would perform an IAS GetValueByClass on the class name "IrTran-Pv1," attribute "IrDA:TinyTP:LsapSel," and initiate a TinyTP connection to the returned LSAP-SEL. It would then run IrTran-P V1 unchanged over the TinyTP connection.

It is possible for any application to initiate an outbound connection to a camera supporting IrTran-P, or any other image transfer protocol, that runs directly over TinyTP. It is also possible to write a server that can support an arbitrary number of concurrent connections with cameras, provided the image transfer protocol is based on TinyTP. This is the recommended approach.

Windows 2000 Support For Point-to-Point IrDA Networking

PPP and IrDA Networking

In addition to supporting access to public and private networks, the point-to-point protocol (PPP) can also be used to connect two computers together to create a network of two (or more) computers. This feature is supported in Windows 2000.

IrNET

This section defines a very thin protocol called IrNET that is used to support this feature.

A client wishing to initiate an IrNET connection would perform an IAS GetValueByClass on the class name "IrNetv1," attribute "IrDA:TinyTP:LsapSel," and initiate a TinyTP connection to the returned LSAP-SEL. It would then run PPP over the TinyTP connection.

Figure 5. Point-to-Point IrDA Networking with IrNET

References

Find references to the following at www.irda.org/standards/specifications.asp.

• IrDA Serial Infrared (SIR) Physical Layer Specification
• IrDA Serial Infrared Link Access Protocol
• IrDA Link Management Protocol
• IrDA TinyTP: A Flow-Control Mechanism for use with IrLMP
• IrDA Plug&Play Extensions to Link Management Protocol
• IrCOMM: Serial and Parallel Port Emulation over IR

-------------------------------------------------------------------------------------------------

Disclaimer for Working Documents

The information contained in this document represents the current view of Microsoft Corporation of the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.