jbvb@VAX.FTP.COM (James Van Bokkelen) (07/01/88)
Thus, this is a good approach for occasional use by a subset of the PCs on your PC network. But if you plan prolonged use by most of your PCs, you would be better served by obtaining a multiplexing interface at a lower layer than Netbios. The trouble here is that there is little more than rumours of support for such multiplexing interfaces from many of the PC LAN vendors (e.g. 3Com, Novell). Of course, if the PCs spend all their time using TCP/IP, it would be better to connect to the Ethernet directly. Keith McCloghrie The first commercial offering that allowed multiplexing a single Ethernet interface between a LAN program and TCP/IP was offered by BICC Data Networks, in 1986, for MS/NET and PC-IP. Presently, the market looks like this (as fas as I know), in order of first commercial offering: Board /network type LAN Program TCP/IP available BICC 4113/Ethernet MS/NET, Netware FTP's PC/TCP Univation NC516/Ethernet Netware, Lifenet FTP's PC/TCP All supported Ethernet boards Banyan Vines 2.10 FTP's PC/TCP Sytek/Ethernet & Broadband Netware FTP's PC/TCP IBM Token Ring Adapter/802.5 Vines, Netware, PC LAN IBM TCP/IP, FTP PC/TCP Schneider & Koch/Ethernet Netware FTP's PC/TCP Excelan EXOS205/Ethernet Netware Excelan TCP/IP Bridge PCS1/Ethernet 3+ Bridge Proteon P1300/ProNET-10 Netware FTP's PC/TCP Interlan NI5120 & NI9210/Ether Netware FTP's PC/TCP There are a number of things pending which will affect this picture: One is TRW's support for our Packet Driver spec. Another is Banyan's introduction of Vines 3.0, which will allow co-existence with TCP/IP on any network interface they support, instead of just Ethernet as it is now. The forthcoming "MAC/Vector" specification from 3Com and Microsoft, which should open up 3+/Open to co-existence with other vendors, and might change the whole picture of co-existence and drivers. James VanBokkelen FTP Software Inc.
KGJHH@ASUACAD.BITNET (Jim Howard) (07/01/88)
How much additional memory do these multiplexing drivers use? In many LAN's memory can be pretty tight unless you add expanded or extended memory and move some drivers or TSR's there (at a fair amount or additional cost). Jim Howard Manager, Technical Services Computing Services Customer Support Arizona State University Tempe, Arizona 85287 602-965-5677 Bitnet: KGJHH@ASUACAD
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/02/88)
From: Jim Howard <KGJHH%ASUACAD.BITNET@cunyvm.cuny.edu> How much additional memory do these multiplexing drivers use? In many LAN's memory can be pretty tight unless you add expanded or extended memory and move some drivers or TSR's there (at a fair amount or additional cost). Our PC/TCP product comes in two versions: In 1.1, the entire protocol stack is linked into each program (like PC-IP), and so the only permanent memory usage is for the two device drivers that hold the configuration (about 2K bytes). In 2.0, the TCP/IP has been moved into a TSR module, which is about 88K in the current production version (2.02). Say 90K for 2.02, including the configuration device drivers. More is needed when a TCP/IP utility is in use. Of course, our TSR can be unloaded, but this is still cumbersome. We have been selling both versions since late last year, and plan to continue selling them side by side, because each has its benefits: The disk-resident version is aimed at people concerned with memory issues, and the TSR for people who want things like RFC-conforming NETBIOS, where the TCP/IP needs to be shared amongst multiple programs. I am also working on making 2.03 smaller, but it won't be dramatic... James VanBokkelen FTP Software Inc.
acm@RELAY.PROTEON.COM (07/02/88)
> How much additional memory do these multiplexing drivers use? In many > LAN's memory can be pretty tight unless you add expanded or extended > memory and move some drivers or TSR's there (at a fair amount or > additional cost). The Proteon ProNET-10 driver on Novell that is multiplexing requires about an extra 10 bytes to do it. This is hardly a penalty to make it work. It is the same driver used whether you use it or not. -Al Marshall, Proteon
kzm@TWG.COM (Keith McCloghrie) (07/02/88)
James, If I understand correctly, the Excelan and Bridge solutions in your list only work with their own hardware, in which case users must replace all the existing hardware boards in each of their PCs. All the others that you list are your own customers !!! However, it is still only a small subset of all the available permutations of boards/technologies. I agree that the breakthrough will come when the likes of 3Com and Novell support multiplexing interfaces. The MAC/Vector interface from 3Com has, for some time, been promising to provide one half of this, but I understand it may now be slated as an integral part of LAN Manager (which will come with its own version of TCP/IP, and a whole lot more). However, your solution does not meet the requirement stated in Brendan's original message. It is a subtle distinction, but I think it's worth clarifying that there are multiple different user-requirement scenarios here : 1) a user who has an already-installed proprietary LAN, who wants to expand the possible connectivity of his PCs to include hosts on a TCP/IP network. Here, the best solution is the one which provides the minimum disruption/effort/problems. It is clear that IP-over-Netbios provides less or equal disruption, without imposing any limits on connectivity. As stated in my previous message, this is available from several public domain sources, and at least one commercial vendor (us). 2) a user who is setting up a new network in order to provide his PCs with connectivity to TCP/IP-based hosts. For such a user, the best solution is to ignore proprietary LANs and use TCP/IP exclusively (unless there is a financial advantage in a proprietary LAN). If proprietary LANs are ignored, any TCP/IP package for DOS can be used. 3) a user who is setting up a new network and wants to have both the functionality of a proprietary LAN plus connectivity to TCP/IP-based hosts. This is the case where the extra complexity of a multiplexing interface becomes potentially worthwhile, but even so, the extra complexity is not just at installation/configuration-time, but there is also a greater or equal level of continuing network management support because of the use of multiple protocols at the link layer. There's also the issue that some proprietary LANs consist of multiple segments, where the segments are tied together by, say, a Novell IPX-gateway, rather than a MAC-level bridge. In this case, full connectivity for TCP/IP across the whole multi-segment LAN, is not possible if multiplexing is done at the driver interface. If/when Novell provide a multiplexing interface to allow multiple protocols to run on top of IPX, then this is probably the optimum level at which to interface (i.e. using IPX as the sub-network layer) if the requirements for extra functionality demand the extra complexity. Keith.
gts@violet.berkeley.edu (Greg Small) (07/02/88)
= From: KGJHH@ASUACAD.BITNET (Jim Howard) = Newsgroups: comp.protocols.tcp-ip.ibmpc = How much additional memory do these multiplexing drivers use? In many LAN's = memory can be pretty tight unless you add expanded or extended memory and = move some drivers or TSR's there (at a fair amount or additional cost). We have been using Ungermann-Bass's TCP-PC product since 1986. It provides Netbios on tcpip plus Netbios extensions for direct TCP, UDP, IP and raw Ethernet multiplexing/demultiplexing. We run IBM PC Network, Netbios applications, TN3270 and ftp simultaneously. Others on campus also run tcpip applications developed on the UB socket library, for example PB (phone book) which looks up staff phone numbers and mail addresses. We have about 600 PCs on the network now with about 1200 to go in this round. We chose their intelligent PCNIU rather than the dumb PCNIC in part because all of the tcpip code is loaded into the board and does not take up any of the 640k space. This has proved quite valuable. Actually, the PC resident Netbios interface does take about 9k within the 640k space. Gregory T Small (415)642-5979 Personal Computer Networking & Communications gts@violet.Berkeley.EDU Workstation Support Services - Software Group ucbvax!jade!gts 267 Evans Hall SPGGTS@UCBCMSA.BITNET University of California, Berkeley, Ca 94720 (Workstation Consulting 2-8899, 262 Evans, 10-12 and 2-4pm, mondays)
jbvb@VAX.FTP.COM (James Van Bokkelen) (07/02/88)
I agree, that my message wasn't intended to answer Brendan's stated question, which revolved around what he could do with his existing IBM PC LAN cards. I didn't reply to the original message, since I had nothing specific to say about it. However, in the course of giving Brendan a pretty good solution for his broadband cards, you touched on the subject of multiplexing interfaces, and I felt that I did have something to say about them... Your mention implied that multiplexing interfaces were relatively new on the scene, and rare, when in fact, commercial offerings of multiplexing interfaces considerably pre-date and outnumber the IP-over-NETBIOS variety you described. This was why I changed the subject line... A correction: I mentioned the IBM Adapter Support Interface (TOKREUI) as being one of the multiplexing hardware drivers, supported by TCP/IP from both us and IBM, as well as most LAN programs (I haven't yet encountered anyone who wrote their own driver for the IBM 802.5 adapter). I view this as an excellent example of what can be done with a properly designed and documented multiplexing interface. It has even been supported by some of IBM's competitors in the 802.5 market (although the quality of the emulation can be uneven, just like many non-IBM NETBIOSes). We have placed a somewhat less elaborate interface in the public domain (our Packet Driver spec), which has been used by about half of the FTP OEMs and customers I mentioned. A version of the CMU PC-IP which supports this has been done by Karl Auerbach, and other p-d and commercial software may appear in the future. We obviously don't have the clout of 3Com or Microsoft, but our spec has been in the field for more than a year, and wins on a few technical considerations, as well (MAC/Vector binds only device drivers, and doesn't have an un-bind function). One further comment: Banyan Vines 3.0 servers function as IP routers, using both the normal IP encapsulation for each attached LAN (if a standard encapsulation exists), and an IP-over-Banyan encapsulation which allows TCP/IP to be used on any of the less-standardized LANs that Vines has been implemented on. This is an effort in the direction of "full connectivity for TCP/IP across the whole multi-segment LAN" that goes somewhat further than using NETBIOS (with its one-cable addressing limitations) as a local encapsulation. Perhaps other LAN vendors will develop similar offerings. James VanBokkelen FTP Software Inc.
backman@interlan.UUCP (Larry Backman) (07/05/88)
>I agree that the breakthrough will come when the likes of 3Com and >Novell support multiplexing interfaces. The MAC/Vector interface from >There's also the issue that some proprietary LANs consist of multiple >at the driver interface. If/when Novell provide a multiplexing interface >to allow multiple protocols to run on top of IPX, then this is probably the >optimum level at which to interface (i.e. using IPX as the sub-network layer) [] I got a strange phone-call from one of my Novell contacts laast week. He asked if we (Interlan) were interested in rewriting all of our drivers to a new Novell specification that allowed multiple protocols to access the same board. I refered him to our existing NI5210 Netware packet driver that support's FTP Software's paackage. He said their new speecification was like that but better!! Anyways, he was a marketing type who was easily confused by terms like "multiplex". Anyone out there know about this. It may be a Novell fantasy which will not become real for 2 years!! Larry Backman
karl@TRWIND.IND.TRW.COM (Karl Auerbach) (07/06/88)
The packet driver interface seems to degrade performace by only a few percent when compared against a linked-in driver. I have pumped more than 2500 packets per second through a packet driver I wrote for the TRW board. Someone who is clever could put the bulk of the driver out in EMS memory or on a mildely smart board, keeping only the first level interface code in the critical 640K zone. --karl--