Transport Layer Interface

Transport Layer Interface（TLI、トランスポート層インタフェース）とは、1987年にAT&TのUNIX System V Release 3.0で提供されたネットワーク用APIであり^[1]、Release 4 (SVR4) でもサポートが継続された^[2]。

概要

BSDのソケットに対抗したSystem VのAPIである。TLIは後にThe Open Groupが XTI (X/Open Transport Interface) として標準化した^[3]。実装は下位に位置するキャラクタ型入出力機構であるSTREAMSと密接に関連している。

当時、OSIプロトコルが TCP/IP に取って代わると予測されていたため、TLIはOSI参照モデルに準拠したプロトコルから独立した仕様になっており、OSIのトランスポート層に対応している^[4]。XTI/TLIを使ったプログラムは、Transmission Control Protocol (TCP)、Xerox Network Systems (XNS)、Systems Network Architecture (SNA)、X.25、Asynchronous Transfer Mode (ATM) などOSI参照モデルの第4層の機能を提供する様々なトランスポート層プロバイダ上で動作可能である^[5]。

APIとしてはソケットと同様の機能を提供しているが、ソケットがインターネット・プロトコル・スイートと密接に関連しているのに対し、XTI/TLIはプロトコルから独立している^[6]。XTIは、連携するSTREAMSモジュール、ライブラリAPI、ヘッダファイル群、XTIプロセスの動作に関する規則や制限で構成されている^[6]。

TLIとXTIはUNIX 98まではPOSIXソケットAPIよりも好まれ、広く使われていた^[7]。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となっていた^[7][5]。その後Single UNIX SpecificationにおいてSTREAMSを実装していないBSDやLinuxを考慮すべきだという議論が起き、UNIX 03ではSTREAMSとXTIをオプションとし、POSIXソケットをサポート推奨APIとした。

プロトコル独立性

XTI/TLIはプロトコルから独立している。しかし、どのプロトコルを使うかを指定する必要があるため、結局アプリケーションは使用するプロトコルについて知っている必要がある^[8]。使用するプロトコルに関する知識もアプリケーションから排除するには、Network Selection Facilities を使用する。これはXTI/TLIライブラリ (libnsl) の一部となっている^[9]。

XTI/TLI とソケットの比較

XTI/TLIとBSDソケットは似ているが、完全に同じというわけではなく、同じ役割の関数が異なる振る舞いをすることも多い。UNIX SVR3^[10] とSVR4^[4] では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非同期モード

XTI/TLIには非同期モードがあり、リアルタイム性が要求されるアプリケーションで利用できる。非同期モードでない場合、データを待ち続けてずっとブロックされる可能性がある。初期化の際に O_NONBLOCK というパラメータを指定すると非同期モードになる。その場合、接続要求、新規データ到着、タイムアウトなどのイベントを非同期にアプリケーションに通知する。

XTIでの改良点

XTIでTLIから改良した点として、エラーメッセージの追加、フロー制御のためのイベント追加、パラメータ指定の簡素化（オープンの際はデフォルトでリード・ライトとなるなど）がある。また、t_listenでずっとブロックしてしまうのを防ぐためqlenの値をチェックするようになった。さらにt_strerror()とt_getprotaddr()というインタフェースが追加された。

実装

XTI/TLIはUNIX System Vで実装されているが、Linux向けのOpenSS7などの実装例もある。