A hálózatokkal kapcsolatban kiadott szabványok csak a protokoll-specifikációkat tartalmazzák (például azt, hogy a TCP-fejrész bitjei mit jelentenek, és hogyan kell oket beállítani ahhoz, hogy a kommunikáció a végbemehessen), és nem specifikálják azt, hogy a programozók ezeket a szolgáltatásokat hogyan vehetik igénybe (például az operációs rendszer rendszerhívásain keresztül vagy valahogy máshogy). A 4.3BSD UNIX (hálózati) alapszoftvere két fontos részbol áll: az egyik rész felel magáért a kommunikációért, a például az elküldendo adatok feldarabolásáért, a TCP fejrész kitöltéséért, az adatoknak az IP fejrésszel bovítéséért, az Ethernetre továbbításáért. Ezt szokás transzport szoftvernek nevezni. A hálózati alapszoftver másik része - a socket rendszer - pedig olyan (fájl-)deszkriptorokat (és ezzel együtt a szükséges memória-buffereket) nyújt a programozónak, amelyre a szokásos read() illetve write() rendszerhívásokkal adatokat lehet küldeni illetve onnan adatokat lehet olvasni. Amikor a sockethoz implicit ( socket()-tal) vagy explicit ( bind()-dal) módon egy (hálózati) címet rendelünk, akkor hozzuk létre a kernelben a fent említett két komponens közti kapcsolatot.
A socket rendszert eredetileg a Berkeley UNIX-ban alakították ki, az AT&T ezzel szemben a System V UNIX-ában az úgynevezett TLI (Transport Layer Interface) könyvtárat alakította ki, amelynek szintén az volt a célja, hogy az operációs rendszerbe épített transzport- protokollokhoz a programozó valahogyan hozzá tudjon férni. Az X/Open szabványosító csoport a TLI-t XTI néven szabványosította (X/Open Transport Interface).
Késobb a Sun Microsystems alakított ki egy olyan UNIX rendszermodult (ún. STREAMS modult ), amely az AT&T UNIX-okon a Berkeley socket rendszert szimulálja. (Ez a szimuláció nagyon nehezen megoldható, mert a TLI több komponense nem a kernelen belül helyezkedik el, és ezért például egy exec() rendszerhívás során a TLI belso állapota elveszik, mert az is a programnak abban a memóriarészében van, amely az új folyamat betöltésekor elveszik).
A TLI könyvtári függvények és a felhasználó közti kommunikációban nagy szerepe van egy netbuf nevu struktúrának, amelyben "változó hosszúságú" adatokat lehet a TLI rutinoknak átadni vagy azoktól visszakapni (például hálózati címeket ...). A struktúra a <tiuser.h> nevu C header-fájlban van definiálva, és szerkezete a következo:
struct netbuf {
unsigned int maxlen;
unsigned int len;
char *buf;
};
Ebben a struktúrában a buf egy mutató valamilyen memóriabeli objektumra (mondjuk egy olyan adatterületre, ahova az adatokat be kell olvasni a hálózatról vagy valami hálózati címet vagy valami mást tartalmaz). Ennek a memóriabeli objektumnak a maximális méretét tartalmazza a maxlen mezo (mondjuk oda az kerül, hogy mekkora adatterületet allokáltunk a malloc()-kal ...). Ez az adatterület nincs mindig teljes egészében kitöltve, ezért van szükség a len komponensre, amely a buffer aktuális tartalmának a hosszát tartalmazza. (Látható, hogy ez a struktúra a socket rendszernél használt sockaddr_in strukturának a megfeleloje.)
Fontos megemlíteni, hogy a legtöbb TLI rutin valamilyen hiba jelzésére negatív visszatérési értékkel tér vissza, míg ha nincs hiba, akkor leggyakrabban nullát adnak vissza. (A kivételek majd meg lesznek említve.) Hibás visszatérési érték esetén a hiba kódját a t_errno globális változó értékébol tudhatjuk meg (ez a változó minden TLI szabványnak megfelelo rendszeren megvan).