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)、Xerox Network Systems (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インタフェース | ソケットインタフェース | 意味論的に同一か |
|---|---|---|
| t_open | socket | イエス。ただしt_openはオープン時にt_getinfoを実行可能 |
| - | socketpair | - |
| t_getinfo | - | - |
| t_getprotaddr | getsockname, getpeername | イエス。しかしt_getprotaddrは対応する2つの機能を1つで実行可能 |
| t_bind | bind, listen | イエス。ただしt_bindは対応する2つの機能を1回のコールで実施可能 |
| t_optmgmt | getsockopt, setsockopt | イエス。ただしt_optmgmtはデフォルト値と調停値を取得できるのに対し、getsockoptとsetsockoptは現在値しか取得/更新できない。 |
| t_unbind | bind | イエス。ソケットの場合AF_UNSPECを指定することでunbind相当になる。 |
| t_close | close | イエス。ただし、t_closeでは常にアボート的切断になるのに対し、closeは終了を待ち合わせて解放することもある。 |
| t_getstate | - | - |
| t_sync | - | - |
| t_alloc | - | - |
| t_free | - | - |
| t_look | select, getsockopt | selectとgetsockopt (SO_ERROR) はt_lockの全機能をカバーしていない。 |
| t_error | perror | イエス。ただしXTIは通常のerrnoに追加的にt_errnoを使用し、トランスポート層のエラーだけでなくUNIXシステムのエラーも示すことができる。 |
| t_strerror | strerror | イエス |
| t_connect | connect | t_connectの前にt_bindが必須である。 |
| t_rcvconnect | select | t_rcvconnectは、selectでO_NONBLOCKを指定した場合と同等である。 |
| t_listen, t_accept, t_snddis | accept | acceptは接続を拒否できないが、t_listenで受け付けた接続要求はその後のt_acceptで初めて許可され、t_snddisを使えば拒否できる。 |
| t_snd, t_sndv | send, sendto, sendmsg | イエス。しかし t_snd と t_sndv はコネクションモードのトランスポートでのみ使用。 |
| t_rcv, t_rcvv | recv, recvfrom, recvmsg | イエス。ただしt_rcvとt_rcvvはコネクションモードのトランスポートでのみ使用。 |
| t_snddis | close, shutdown | t_snddisを発行後も接続要求をlistenし続けることができ、t_connectで接続を再確立することもできる。closeはソケットのファイル記述子を解放してしまう。通信を続ける場合、ソケットでは新たに接続を確立する準備をしなければならない。 |
| t_rcvdis | ENOTCONN, ECONNRESET, EPIPE, SIGPIPE | イエス。ただし、ソケットではエラーまたはシグナルで通知。 |
| t_sndrel, t_sndreldata | shutdown | イエス。しかしshutdownには通常解放時にデータを送信する機能はなく、t_sndreldataは通常解放時にデータを送信できる。t_sndrelは単にシャットダウンだけを行う。 |
| t_rcvrel, t_rcvreldata | - | - |
| t_sndudata, t_sndvudata | sendmsg | イエス。しかしt_sndudataとt_sndvudataはコネクションレス・モードでのみ使用。 |
| t_rcvudata, t_rcvvudata | recvmsg | イエス。しかしt_rcvudataとt_rcvvudataはコネクションレス・モードでのみ使用。 |
| t_rcvuderr | - | - |
| read, write | read, write | XTI/TLIではread/writeを使用する前にtirdwrモジュールをSTREAMSにプッシュする必要がある。 |
ライブラリ関数には呼び出し順序の規定があるため、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などの実装例もある。
