davidc@TERMINUS.UMD.EDU (01/28/88)
It appears the pcipdriver mailing list died without resolving
anything other than we need to resolve stuff. I guess the attempt to
standardize on a way to talk to an internet TSR was too late, since
several people had already invested lots of effort defining their own.
I would like to resurrect the interface discussions in order to attempt
to standardize on an application to transport layer interface library.
This would seem to me to be the easiest thing for us to agree on since
standardizing on a transport layer interface would be a relatively
painless operation. No one would have to rewrite anything, they'd just
have to add a new library to their developer's toolkit or whatever.
The issues involved with a transport layer interface that I feel
need to be resolved are the following:
o Which interface?
The two major contenders in previous discussions were BSD
Sockets and SYSV TLI. I personally would prefer to standardize
on BSD sockets. I readily admit they aren't the best things
created, but I feel they have the largest following in the
TCP/IP world.
o Which calls to support?
Do you support read() and write() on BSD sockets? How about
ioctl() and send/recvmsg()?
o How in depth do you support the calls?
Do you support the backlog in listen()? Which options in
get/setsockopt() will be supported?
o How to provide an asynchronous interface?
Does TLI provide anyway to do this?
I'm sure there are a lot of other things that need to be discussed
along with the above issues. Anyone care to comment?
-drc
PAP4@AI.AI.MIT.EDU ("Philip A. Prindeville") (02/02/88)
Well, I'm still interested in the driver interface specification, but I haven't seen anything on pcipdriver since the BOF. Has there been any mail? It may be that we've all lost interest, and are waiting to see what happens with OS/2. I, for one, am breathless. -Philip
jbvb@VAX.FTP.COM (James Van Bokkelen) (03/04/88)
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.