Transport Layer Interface (TLI、トランスポート層インタフェース)とは、1987年にAT&Tの UNIX System V Release 3.0 で提供されたネットワーク用APIであり、Release 4 (SVR4) でもサポートが継続された。BSDのソケットに対抗した System V のAPIである。TLI は後に The Open Group が XTI (X/Open Transport Interface) として標準化した。実装は下位に位置するキャラクタ型入出力機構であるSTREAMSと密接に関連している。当時、OSIプロトコルが TCP/IP に取って代わると予測されていたため、TLI は OSI参照モデルに準拠したプロトコルから独立した仕様になっており、OSI のトランスポート層に対応している。XTI/TLIを使ったプログラムは、Transmission Control Protocol (TCP)、 (XNS)、Systems Network Architecture (SNA)、X.25、Asynchronous Transfer Mode (ATM) などOSI参照モデルの第4層の機能を提供する様々なトランスポート層プロバイダ上で動作可能である。APIとしてはソケットと同様の機能を提供しているが、ソケットがインターネット・プロトコル・スイートと密接に関連しているのに対し、XTI/TLIはプロトコルから独立している。XTIは、連携するSTREAMSモジュール、ライブラリAPI、ヘッダファイル群、XTIプロセスの動作に関する規則や制限で構成されている。TLIとXTIは UNIX 98 まではPOSIXソケットAPIよりも好まれ、広く使われていた。TLIとXTIは、SolarisなどSVR4から派生したOSやUNIXブランド (UNIX 95, UNIX 98, UNIX03 Single UNIX Specification) 準拠のOSでは今もサポートされている。また、Mac OS でも Open Transport という名称で使われた。UNIX 95 (XPG4) と UNIX 98 (XPG5.2) ではXTIがサポート推奨APIとなっていた。その後 Single UNIX Specification においてSTREAMSを実装していないBSDやLinuxを考慮すべきだという議論が起き、UNIX 03 ではSTREAMSとXTIをオプションとし、POSIXソケットをサポート推奨APIとした。XTI/TLIはプロトコルから独立している。しかし、どのプロトコルを使うかを指定する必要があるため、結局アプリケーションは使用するプロトコルについて知っている必要がある。使用するプロトコルに関する知識もアプリケーションから排除するには、Network Selection Facilities を使用する。これはXTI/TLIライブラリ (libnsl) の一部となっている。XTI/TLIとBSDソケットは似ているが、完全に同じというわけではなく、同じ役割の関数が異なる振る舞いをすることも多い。UNIX SVR3 と SVR4 ではTLIとソケットがSTREAMSの Transport Service Interface の上に実装されている。下記の表はPOSIXでのXTIとソケットのインタフェースを比較したものである。ライブラリ関数には呼び出し順序の規定があるため、XTI/TLIは状態インジケータを使用しており、ソケットAPIにも同様の仕組みがある。ただし、ソケットのAPI関数は複数の状態で呼び出せることがあるのに対し、XTIのAPI関数は特定の状態でないと呼び出せないようになっている。XTI/TLIには非同期モードがあり、リアルタイム性が要求されるアプリケーションで利用できる。非同期モードでない場合、データを待ち続けてずっとブロックされる可能性がある。初期化の際に O_NONBLOCK というパラメータを指定すると非同期モードになる。その場合、接続要求、新規データ到着、タイムアウトなどのイベントを非同期にアプリケーションに通知する。XTIでTLIから改良した点として、エラーメッセージの追加、フロー制御のためのイベント追加、パラメータ指定の簡素化（オープンの際はデフォルトでリード・ライトとなるなど）がある。また、t_listen でずっとブロックしてしまうのを防ぐため qlen の値をチェックするようになった。さらに "t_strerror()" と "t_getprotaddr()" というインタフェースが追加された。XTI/TLIは UNIX System V で実装されているが、Linux向けの OpenSS7 などの実装例もある。

出典:wikipedia