Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!VAX.FTP.COM!jbvb
From: jbvb@VAX.FTP.COM (James Van Bokkelen)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: An attempt to rekindle interface discussions...
Message-ID: <8803032136.AA01418@vax.ftp.com>
Date: 3 Mar 88 21:36:31 GMT
References: <8801280234.AA14753@terminus.UMD.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32

Replying a month late, but things get that way when deadlines get near:

I don't mind the idea of sockets as an interface;  We did an emulation of
them for our 2.0 release, primarily to allow existing Berkeley code to be
ported to DOS.

Our sockets:
	Are an emulation:  You call subroutines, which do various things in
	your own address space, and then (maybe) do a native-mode syscall
	(via an interrupt instruction) to our TCP/IP kernel (a separate TSR).

	Support read/write, but via macros, which requres re-compilation.

	Support select(), but only on sockets (not on other C file handles).

	Support ioctl()  (only FIONREAD & FIONBIO)

	Support send(), sendto(), recv() and recvfrom().

	Support the backlog in listen().

	Supports get/setsockopt(), with SO_REUSEADDR, SO_KEEPALIVE,
	SO_BROADCAST, SO_DONTLINGER, and SO_LINGER.

We think that an asynchronous interface is essential under DOS.  However,
we don't think that kludging something of this nature onto sockets is the
right solution.  What we have done is define our own native-mode interface,
standardized around register contents in an interrupt instruction.  This
has copious asynch facilities, and is broad enough that the socket emulation
was relatively simple to do on top of it.

James VanBokkelen
FTP Software Inc.