Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!ut-sally!im4u!esc-bb!halley!bc From: bc@halley.UUCP (Bill Crews) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: standard interface Message-ID: <303@halley.UUCP> Date: Mon, 16-Nov-87 22:40:50 EST Article-I.D.: halley.303 Posted: Mon Nov 16 22:40:50 1987 Date-Received: Thu, 19-Nov-87 06:50:39 EST References: <11631@orchid.waterloo.edu> <8711110620.AA24292@violet.berkeley.edu> Reply-To: bc@halley.UUCP (Bill Crews) Organization: Tandem Computers, Austin, TX Lines: 27 My remarks about TLI and in qualified support of sockets in earlier postings were based on the assumption that Drew had a real reason to want to interface to the network at a network level, rather than at a (lean, mean) protocol- specific level. I would prefer that TLI get cast in concrete rather than sockets, though I still applaud support of sockets for the purpose of enabling straight-forward ports of networking applications written to that interface under Berkeley networking Unix. But the mini world (including Unix and OS/2) is not the DOS world. In the DOS world, cheating the system is still (and will continue to be) the norm, and in such an environment, a lower-layer and higher-performance interface should also be supported. Notice the word "also". Not all Telnet implementations will be updating the time-of-day clock on the 25th line between keyboard and display events, so a generic network interface would ALSO pay off. Your select (or SysV poll) might be useful under Windows 2.0, eh? An interface that might be worth looking at is 3Com's 3L Link Level Library, which provides "shared buffers", which is what Greg wants, but which also provides enough protocol-independence at least to allow the same interface to be used for access to either their Ethernet or their Token Ring boards. Of course, this is a link-level interface, but what the hey? -bc -- Bill Crews Tandem Computers Austin, Texas ..!rutgers!im4u!esc-bb!halley!bc (512) 244-8350