		  Socket Emulation Library for SYSV
		  ---------------------------------

This library emulates the BSD sockets with SYSV named pipes. It is
meant as a drop-in for those who have no sockets, but still want to
use programs using sockets. In particular, it was developed to get
X-windows working on xenix without any networking (or streams).

WARNING:
--------
The whole package is a fast hack. Don't expect any miracles. I have no
access to an UNIX system with real pipes, and don't even have manual
pages for the functions, so the implementation is just an educated
guess. The functions might return the wrong error codes on failures,
etc. If you figure out something wrong, i am happy to hear about it.
Currently it is only working on a XENIX/386 2.3.2 system with gcc.


INSTALLATION:
-------------
If you have are running Xenix 2.3.2, and have gcc, you can just put
everything in a directory, and type make. Gcc will give some warnings,
that is allright, but the compilation should proceed nicely, and it
will stop with the libsocket.a library ready.
I put socket.h in /usr/include/sys, netdb.h in /usr/include, and
Slibsocket.a in /lib/386. If you like that, you can just do a "make
install", as root. Otherwise you have to install manually.

If you don't have Xenix or gcc, it will probably not compile so
easily.  Be prepared to do some hacking to get it going. I would
recommend to start trying on something less than X-windows, unless you
really like extra trouble.


DESCRIPTION:
------------
Each socket is implemented as a pipe (fifo) in the /tmp directory. The
names are generated uniquely, and have no significance outside the
socket library. This pipe is the control channel. It is only read on,
never written on by the socket creator.

When you bind a name to the socket, a link is created to that pipe,
with a name according to the bound name. The client program can later
connect to that socket, and the communication channel is created as
two more pipes (with unique names) in the /tmp directory. Two pipes
are needed since sockets are bi-directional, but pipes only
uni-directional. The hand-shaking between the two processes go through
the respective control pipes, created by the socket() call.

All in all, each socket connection uses 4 pipes. One each as control
channels for the sockets (in the two processes), and one each for the
data transfer.

The file descriptor returned by the socket() call, is connected to the
read channel, when the connection is established. But you should avoid
using any i/o calls on that file descriptor directly. The read(),
write(), ioctl(), and close() procedures are defined as macros in the
socket.h file, and are redirected to the procedures soread(),
sowrite(), soioctl() and soclose(). If the i/o is going to a socket
file descriptor, those procedures takes care of redirecting the
function to the correct i/o channel, otherwise they just to the same
thing as their normal counterparts.

This means that in every c-file where you do a read(), write(),
ioctl() or close() on a file, which is a socket, you have to include
socket.h. This is normally always the case anyway.

Only two address families are defined AF_UNIX and AF_INET. Inet
sockets all go to the same machine.

DIFFERENCES:
------------
There is no <netinet/in.h> file. The definitions in that file is
included in socket.h, so you can normally just comment out any
references to it. The same for un.h
There is a symbol SOCKET_EMULATION defined by socket.h, that can be
used for conditional compilation in the c files.
The error numbers are completely different from the BSD ones.


BUGS:
-----
select() should be trapped also. as it is now, select() on writes
does not work.


COPYRIGHTS:
----------- 
Copyright on a hack? Are you kidding?  Some parts were snatched from
the BSD tahoe distribution. Maybe their copyright should be somewhere.
I guess a warning is enough. But as all source is very heavily munged,
i figured it is so different, so that there is hardly any similarity.
Try grepping on the comments. Maybe one, or two, are left from the bsd
files. 

MY ADDRESS:
-----------
I would be happy to hear some feedback about problems. My e-mail
address is: p...@compuram.bbt.se


P.Garbha
