RAF@CU.NIH.GOV (Roger Fajman) (05/29/90)
Regarding two TCP/IP stacks on one PC using NDIS and/or packet drivers: what are the problems if the two stacks use different IP addresses?
jbvb@VAX.FTP.COM (James Van Bokkelen) (05/30/90)
The primary issue is the same: Current Packet Drivers demux at the network layer, and pay no attention to IP addresses. If one added logic to create a new class, that demuxed on IP addresses, it could be done. However, both the ARP implementation and IP fragment reassembly would have to be in the Packet Driver itself, which makes it somewhat bulky, and you'd have to remove the current IP/ARP in the stacks that used it. Because the people who want two TCP/IP stacks under the PDS are usually after the union of the feature sets of two freeware packages, and unwilling to do major surgery on them, I don't know of anyone who has done this particular hack. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
RAF@CU.NIH.GOV (Roger Fajman) (05/30/90)
Let me explain why I asked. We are heavy users of 3+Share and expect to migrate to 3+Open LAN Manager. I would love to be able to run 3+Open over TCP/IP and do away with XNS. However, 3+Open TCP is functionally deficient. We would rather use PC/TCP. As long as 3+Open uses XNS all should be well. But will PC/TCP coexist with 3+Open running TCP/IP? I'm interested in the answer for both DOS and OS/2.
jbvb@VAX.FTP.COM (James Van Bokkelen) (05/30/90)
Given prior discussion of XNS Netbios vs. TCP Netbios as presently widely
available (B-nodes only), it seems that the only satisfactory solution
for your site is to keep XNS for 3+Open, and use TCP/IP side-by-side over
an NDIS driver of your choice:
NDIS (NDIS provides the demultiplexing)
/ \
TCP/IP 3+Open
kernel (XNS)
This solution gives you your choice of TCP/IPs under both DOS and
OS/2. Under DOS you can chose any TCP/IP that supports NDIS: PC/TCP,
WIN/PC, PC-NFS, BW-NFS, or the 3Com product. Under OS/2, all the
available TCP/IPs support NDIS, except for some of those that run
on 'smart' boards.
If B-node RFC 1101/1002 support is viable in your environment, or the
vendor you like can supply either M-Nodes or a static name exporter on
the lines of 3Com's 'locator', the multiplexing can take place above
TCP/IP, as follows:
NDIS (actually, since NDIS isn't being used to
| demux anything, it isn't required and you
TCP/IP could use a Packet Driver, a linked-in
kernel driver or a smart board instead)
/ \
Telnet, Netbios
FTP, etc. (RFC 1001)
/ \
3+Open/LM Other Netbios apps
On DOS, this scenario lets you use any of the vendors who supply an
RFC 1001/1002 Netbios. On OS/2, your choices are more limited,
because only Excelan and 3Com have so far offered the requisite
kernel-resident Netbios implementation. We intend to, but NFS has
priority.
The only work I have ever heard of that ran two TCP/IP stacks on a
single machine was done under DOS at a university that wanted the RVD
support in PCIP to run alongside NCSA Telnet, and they recently went
to some effort to replace it with a cleaner solution that only loads
one TCP/IP.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901dmatlock@eecs.cs.pdx.edu (Delbert Matlock) (05/31/90)
In article <9005300317.AA12582@alw.nih.gov> RAF@CU.NIH.GOV (Roger Fajman) writes: >However, 3+Open TCP is functionally deficient. We would >rather use PC/TCP. As long as 3+Open uses XNS all should be For God sake, would somebody please say what's wrong with 3+Open TCP. Numerous people have made comments about it being deficient, but nobody has elaborated as to what's wrong. Sometime this summer, I have to bring a 120 node 3+Open network upto ULANA compliance. (For those non-goverment people, ULANA is a goverment network specification mandating TCP/IP) I would hat to make the $40,000 dollar mistake. :-) ============================================================================= Delbert Matlock Internet: dmatlock@eecs.cs.pdx.edu MicroNet Northwest UUCP: dmatlock@eecs.UUCP Voice: (503)228-3071
RAF@CU.NIH.GOV (Roger Fajman) (05/31/90)
The problem with running 3+Open over Netbios is that not all applications are Netbios applications. With XNS, at least, 3+Open Mail is not. I don't know what the situation is with 3+Open over TCP/IP. But we are probably stuck with XNS for now.
jbvb@VAX.FTP.COM (James Van Bokkelen) (05/31/90)
It is puzzling to hear that 3+Open mail doen't use Netbios sessions, in light of the way that OS/2 and NDIS are structured. The theory of how OS/2 was supposed to network (as propounded by Microsoft and 3Com) was that all network activity was going to take place via "named pipes" (preferred) or Netbios sessions (via the user NCB API), and thus they didn't specify any means of programming the actual transport layer from a user application. LAN Manager talked to a Netbios embedded in the kernel, user NCBs were passed to this Netbios, and that was it. A vendor could presumably specify a private API for a particular transport layer, but Microsoft stayed out of it. If 3Com (and other LM OEMs) had implemented things this way, then it would be fairly simple to swap one transport layer for another (XNS vs. OSI vs. TCP/IP was what Microsoft promised) at the cost of difficulty in doing "standard" applications like FTAM or Telnet. But if in fact 3+Open mail goes direct to the transport, then 3Com is married to their own transport layer (presumably XNS or TCP/IP), and my 2nd alternative isn't viable for 3COM (a bit of a surprise). Oh, well... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
backman@interlan.Interlan.COM (Larry Backman) (06/01/90)
In article <9005311412.AA02654@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes: >It is puzzling to hear that 3+Open mail doen't use Netbios sessions, >in light of the way that OS/2 and NDIS are structured. The theory of >how OS/2 was supposed to network (as propounded by Microsoft and 3Com) >was that all network activity was going to take place via "named >pipes" (preferred) or Netbios sessions (via the user NCB API), and >thus they didn't specify any means of programming the actual transport >layer from a user application. LAN Manager talked to a Netbios >embedded in the kernel, user NCBs were passed to this Netbios, and >that was it. A vendor could presumably specify a private API for >a particular transport layer, but Microsoft stayed out of it. > Ah James, performance, performance, performance..... NDIS --> NETBIOS is a pretty interface but as with most generic interfaces is slower than a private (read transport layer) interface. I've gone through at least 4 rounds of OS/2 NDIS drivers's; the things I do to go around the OS at this point are reminiscent of DOS to say the least. For instance, my IPX driver uses a private transport interface up to user space. Rounds 1 & 2 used the DosDevIOCtl call. How do you spell ring transition --- slow.... Round 3 uses a shared memory queue and RAM semaphores to speed things up. For another instance; use the kernel debugger to step through and count the instructions in your favorite DevHelp call, some of them are scary! I used to use PhystoGDT at interrupt time when I received a packet; no more! I also lock user buffers at Open time, the DevHelp Lock/Unlock calls are basically useless for real-time programming. BTW, OS/2 1.2 does clean up some of the sins and slowness of OS/2 1.0/1.1. Give Microsoft the credit for at least trying. Larry Backman backman@interlan.com
RAF@CU.NIH.GOV (Roger Fajman) (06/02/90)
I'm no 3+Open expert, but my understanding is that 3+Open Mail requires XNS. It will not run over NBP (NetBios Protocol). NBP is their stripped down, non-internetworkable NETBIOS implementation. I'm not sure how 3+Open Mail interacts with the TCP/IP support.
CCECL@NUSVM.BITNET ("L. Chandra") (06/04/90)
>Let me explain why I asked. We are heavy users of 3+Share >and expect to migrate to 3+Open LAN Manager. I would love >to be able to run 3+Open over TCP/IP and do away with XNS. >However, 3+Open TCP is functionally deficient. We would >rather use PC/TCP. As long as 3+Open uses XNS all should be >well. But will PC/TCP coexist with 3+Open running TCP/IP? >I'm interested in the answer for both DOS and OS/2. PC/TCP works with 3+Open running NBP or XNS NetBios, but not with 3+Open running NetBios over TCP/IP. Does anybody knows why? It seems to me that the TCP/IP stacks which is loaded first would get all the packets, and the other gets none (I am not sure, I am just guessing). One possible solution is to run the redirector (and Lan Manager) over PC/TCP's NetBios, forget about 3+Open's TCP all together. But I have not tried this. Incidentally, does PC/TCP supports expanded/extended memory? For DOS with 640k limit, this is a very desirable feature.
RAF@CU.NIH.GOV (Roger Fajman) (06/04/90)
> For God sake, would somebody please say what's wrong with 3+Open TCP. Numerous > people have made comments about it being deficient, but nobody has > elaborated as to what's wrong. Of course, "functionally deficient" is relative to what you want to do. Just reading the specs I noticed that there's no TN3270, NFS, or XWindows capability. I haven't actually used the product, so I can't say how it performs or comment on the quality of what is implemented.
CCECL@NUSVM.BITNET ("L. Chandra") (06/04/90)
>For God sake, would somebody please say what's wrong with 3+Open TCP. Numerous >people have made comments about it being deficient, but nobody has >elaborated as to what's wrong. > >Sometime this summer, I have to bring a 120 node 3+Open network upto ULANA >compliance. (For those non-goverment people, ULANA is a goverment network >specification mandating TCP/IP) I would hate to make the $40,000 dollar >mistake. :-) > >Delbert Matlock Internet: dmatlock@eecs.cs.pdx.edu >MicroNet Northwest UUCP: dmatlock@eecs.UUCP >Voice: (503)228-3071 Some of the our problems with 3+Open TCP 1. For a start, 3+Open TCP does not have TN3270. This is a big problem for us since our main computing resource is IBM mainframe. Further more 3Com has not annouced any plan to support TN3270. 2. No support for Bootp/Rarp for dynamic IP address allocation. This is another big problem as we have many PCs without harddisk for student cluster. 3. Telnet client does not come with a ftp server. We are kind of use to (free) NCSA/Clarkson's version which has this feature. 4. For DOS, it comes with ONLY ftp, telnet and ping. (cf: PC/TCP provides ftp, telnet, ping, tn3270, tftp, ftp server, tftp server, rcp, rexec, rlogin, lpr, smtp, NFS ..... etc etc). 5. For OS/2, there is ZERO application (no ftp, no telnet, no nothing), just a bare TCP/IP protocol stack (what is that for? I wonder) 6. There is a socket driver but NO development kit (yet). So the socket interface is useless (for now). 7. No Netbios support (yet). ps: This is cross-posted to 3com-l and pcip.
steve@castle.ed.ac.uk (S D Law) (06/06/90)
In article <9006031750.AA29111@alw.nih.gov> RAF@CU.NIH.GOV (Roger Fajman) writes: >> For God sake, would somebody please say what's wrong with 3+Open TCP. Numerous >> people have made comments about it being deficient, but nobody has >> elaborated as to what's wrong. > >Of course, "functionally deficient" is relative to what you want to do. Just >reading the specs I noticed that there's no TN3270, NFS, or XWindows capability. >I haven't actually used the product, so I can't say how it performs or comment >on the quality of what is implemented. Well, I recently phoned around to get some info on 3com's TCP. Our contact is a chap from Logitek. When I phoned him and asked if it would support X-windows, he said yes and infact he was running pc-xview (X-windows package for pcs that runs over tcp-ip) on the machine sitting in front of him which had the nbp and the tcp protocol loaded.
RAF@CU.NIH.GOV (Roger Fajman) (06/07/90)
> I think we need to clarify the way in which 3Com 3+Open uses XNS > and TCP/IP. 3Com uses XNS under Open exclusively for 3+Mail. > Assuming the correct PROTOCOL.INI you can demand load XNS prior > to running mail and then release it. All other 3+open operations > make no use of XNS whatsoever. In much the same way, you can > demand load 3Com's 3+Open TCP to Telnet, FTP, etc. Once finished, > you can unload the TCP/IP stack. I'm told by 3Com that this is true for the workstations, but that 3+Open servers do support Netbios over XNS. They are coming out with Netbios over XNS for the workstations in some later release of 3+Open. > As you mentioned, 3+Open TCP is not all it is cracked up to be. > As an alternative you can use the NDIS/PACKET DRIVER version of > PC/TCP from FTP Software. I am running this right now on top > of Open. When finished with this session, I will use the usual > INET UNLOAD to release the RAM it occupies. This is working > very smoothly. Glad to hear that it works well. This is fine as long as you use only NBP and XNS with 3+Open itself. But if 3+Open starts to use TCP/IP, you have the much dreaded two TCP/IP stacks on one PC. One solution proposed for that problem was to run 3+Open over FTP Software's Netbios. But that Netbios has only B-nodes, so there's no internetworking of Netbios. Also, there might be a problem with 3+Open Mail wanting to load XNS, although perhaps a 3+Open over TCP/IP wouldn't use XNS, even for 3+Open Mail. I was told by 3Com today that their initial release of Netbios over TCP/IP in 3+Open TCP will be B-node only too.
ljm@obelix.twg.com (06/08/90)
>> As you mentioned, 3+Open TCP is not all it is cracked up to be. >> As an alternative you can use the NDIS/PACKET DRIVER version of >> PC/TCP from FTP Software. I am running this right now on top >> of Open. When finished with this session, I will use the usual >> INET UNLOAD to release the RAM it occupies. This is working >> very smoothly. > >Glad to hear that it works well. This is fine as long as you use only >NBP and XNS with 3+Open itself. But if 3+Open starts to use TCP/IP, >you have the much dreaded two TCP/IP stacks on one PC. One solution >proposed for that problem was to run 3+Open over FTP Software's >Netbios. But that Netbios has only B-nodes, so there's no >internetworking of Netbios. Also, there might be a problem with 3+Open >Mail wanting to load XNS, although perhaps a 3+Open over TCP/IP >wouldn't use XNS, even for 3+Open Mail. > >I was told by 3Com today that their initial release of Netbios over >TCP/IP in 3+Open TCP will be B-node only too. I still think you'll be better served by an all TCP/IP network, it's just a question of how you want to overcome the ubiquitous nature of B-node implementations. Our NetBIOS over TCP/IP includes NetBIOS to DNS name mapping support so you aren't limited to a single broadcast segment. It also allows you to load and unload NetBIOS, TCP, and IP (though if you buy into the idea of one protocol stack that feature isn't all that useful in a LAN Manager environment). Or you could look into using NetBIOS 'bridges' to connect your various segments. I know Performance Technologies provides one and I know there are others out there. Lastly, there are M-node implementations out there -- if I can believe my LAN Manager installation instructions, UB does sell one. enjoy, leo j mclaughlin iii The Wollongong Group ljm@twg.com
krumseea@hpuxa.ircc.ohio-state.edu (Arthur J. Krumsee) (06/12/90)
> >Our NetBIOS over TCP/IP includes NetBIOS to DNS name mapping support >so you aren't limited to a single broadcast segment. It also allows >you to load and unload NetBIOS, TCP, and IP (though if you buy into >the idea of one protocol stack that feature isn't all that useful >in a LAN Manager environment). > Can you give us some general idea of how your NetBIOS to DNS name mapping support works? Do you maintain a host table in the PC, in another PC on the network functioning as a router (e.g. WIN/ Route)? Forgive my curiousity but this is a topic of considerable discussion here. Art Krumsee Ohio State University