mark@zok.UUCP (Mark W. Snitily) (01/17/90)
In article <1990Jan16.011859.5080@mks.com> eric@mks.com (Eric Gisin) writes: >In article <403@zok.UUCP>, mark@zok.UUCP (Mark W. Snitily) writes: >> Has anyone tried to create a socket using the libinet.a that comes >> with ISC's X11 development package? >> ... > >The -linet routines emulate BSD sockets by using the native stream >devices and system calls in System V. ... > >Your basic misconception is that /dev/.X11-unix/0 is a UNIX domain socket. >The socket emulation does NOT implemement AF_UNIX. >/dev/.X11-unix/0 is one end of a Stream pipe. ... > >I figured all this out while trying to decide what it would >take to build X11.4 on 386/IX. ... Thanks. Building X11R4 was exactly what I was doing too. Ended up building X11R4 with debug info (libX11.a was about 11MB !) and traced the "could not open display" message to the socket() call in XConnDis.c. (Used -DSTREAMCONN and -DUNIXCONN in the build.) I'm rather comfortable with sockets but know very little about streams. What references (books/journals/source code) would people out there recommend for learning about streams for the first time? -- Mark Mark W. Snitily Consulting Services: 894 Brookgrove Lane Graphics, Operating Systems, Compilers Cupertino, CA 95014 (408) 252-0456 mark@zok.uucp
hwajin@ganges.wrs.com (Hwa Jin Bae) (01/18/90)
In article <404@zok.UUCP> mark@zok.UUCP (Mark W. Snitily) writes:
I'm rather comfortable with sockets but know very little about streams.
What references (books/journals/source code) would people out there
recommend for learning about streams for the first time?
The STREAMS has no conceptual resemblance to sockets. It is a kernel
facility that lets you build device drivers and individual modules
that can be used to implement various system level functions. It contains
a well defined collection of functions that can be used to manage
bidirectional queues of messages and defines a structure of the software
implementation of STREAMS conforming drivers and modules. For example,
I've written varous network interface STREAMS drivers for the Motorola System
V Unix for their Delta-series machines that get I_LINK'ed below a multiplexing
IP protocol STREAMS module (actually a driver). It is a nice model for
implementing modular pieces of software in the kernel. [There are a couple
individual acquaintences of mine who have implemented a user level hook
into the kernel STREAMS mechanism so that you can actually develop a STREAMS
driver/module at the user level before putting it into the kernel, which
makes the development process go much easier.]
The socket mechanism is a programmer interface to the Berkeley based
networking protocol implementation. AT&T defines a different programmer
interface called TLI which resembles the semantics of OSI protocol services.
You can actually write a program that uses TCP sockets on a Sun workstation
and another program that uses TCP TLI end-points on a 386 Unix box and
have them talk to each other without any problems, for example.
AT&T and Prentice Hall publishes a set of documents for both TLI and
STREAMS. Call your local Unix bookstores. They'll have both a
"STREAMS primer" and "STREAMS programmer's guide" as well as a
"network programmers guide".
I guess I hear too many people confuse STREAMS with TLI thesedays and
thus have the occasional urge to elaborate the redundant details.
--
hwajin@wrs.com
Wind River Systems
415/428-2623