Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uwm.edu!linac!att!ucbvax!DEVELOPMENT.WATSTAR.UWATERLOO.CA!erick
From: erick@DEVELOPMENT.WATSTAR.UWATERLOO.CA
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: (none)
Message-ID: <9103251627.AA07596@watserv1.uwaterloo.ca>
Date: 25 Mar 91 16:24:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 45

Subject: Re: TCP API, binary standards

First of all, I'd like to thank everyone for their involvement on this topic.

Perhaps, as was suggested in an earlier message, it would be best to devise
a new, simple API and write interface programs for all commercial stacks.
The acedemic community and friends would be responsible for the API
definition.  We'ld also be responsible for the interface programs unless
sufficient concern was raised for a commercial response.

Rich Goldschmidt suggested NetBIOS as a potential model.  James B VanBokkelen
of FTP disagreed, as do I.

    1. It is relatively hard to implement and keep working.
    2. It involves hardware generated ISRs, extra stacks, and other things
       which lead to differences between vendors.
    3. It is based too much on one device and extra calls have had to be
       added or changed for other products.
    4. It allows/requires re-entrancy and other things which just don't
       work well on top of a typical tcp stack.

Usually a simpler interface would suffice.  For example, practically everybody
supports serial port emulation.  The only problems with making it as simple
as TNGLAS (or whatever) would be

    1. Too slow - need a method of transferring more data at a time and faster
    2. Needs more open channels (sockets)
    3. Need name resolution features
    4. Need ability to test for data without busywaiting.
    5. Needs record based (UDP) capabilities in addition to stream data

Unless I have missed something, the above could be implemented relitively 
easily.  It wouldn't even have to be as large as the FOSSIL spec.  

I'm still looking for ideas before anything gets done.  I only really see a
need for name resolution, open/close, blocking read/writes, nonblocking i/o, 
perhaps string i/o capabilities, and udp packet i/o.  Most of this could be
rolled into a generic driver and calls added for vendor.

Would register variables or structured based requests be better, or would
some form of DOS character device be best?

(You might consider making these responses through mail and I will summarize.) 
  
Erick