snorthc@NSWC-OAS.ARPA (10/28/88)
To: tcp-ip@sri-nic.arpa > From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU (Robert English) > Saying "users don't want to be bothered" trivializes the issue somewhat. > There are many DOS applications in which users never see the actual > files involved. The application presents them with menus to perform > tasks, and manages the files itself. A user who had to transfer all of > the necessary files over via FTP would have to be much more > sophisticated than one who merely used the application. I agree with most of what you say above. > Furthermore, there is the issue of file-sharing. If users access the > files on the remote machine directly, they can share effectively share > data with other users. If they must copy the data back and forth, they > are likely to get inconsistent versions, forget to do the copies, etc. > (I know, you've never walked away from a terminal without writing out a > file). > Working in a non-transparent environment is significantly more > complicated than working in a transparent one. Here is where I have the problem. If you are talking theory or ideals you are right of course. If you are talking implementations of NetBIOS/TCP then perhaps the memory issue needs to be revisited. If you have an MS-DOS machine, you may find 256k or so of your available memory space gone to provide this transparency (example 3c505, FTP SW, IBM PC LAN program rdr). Cut off another 60 - 80k for DOS and many of the applications that provide the user with menus and manage the files cannot run. Then what does transparency buy you? There are work arounds. The Excelan implementation requires less memory, I think it was about 80k for RDR. Also for those with 80386 chips there are supposedly programs that allow TSR type SW or device drivers to run in memory space above 1mb. There is also OS/2 [I'm still waiting for the promised Oct update to my SDK Microsoft!!!!]. However, for the present, I have serious doubts that NetBIOS/TCP is providing usable services to anyone. It is my belief that the vendors who invested time/effort/ brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan, Bridge [they weren't 3Com at the time], Network Research Corp) wish they had placed their investment somewhere else like NFS or OSI or whatever. Finally file sharing. A simple file locking scheme may not be sufficient to make file sharing truly useful. Ever write code with someone else? What if the only mechanism for Source Code Control was that the file was locked after a user had it? That is why we RCS and friends. I have never written a document with anyone else, but I suspect you would run into some of the same problems. This is why multi-user databases handle their own locking (one reason they require so much memory). The point is you are still likely to get inconsistent versions with NetBIOS/TCP as your file sharing mechanism. It is not clear to me that an incomplete, memory hogging, broadcast based, transparent environment is less complicated than simply explictly transferring files with a mechanism like FTP or FTAM. Don't listen to me though, I wasn't able to figure out what a PS/2 would buy me either and do my development work on a Compaq, you see, I have already missed the boat :). Stephen Northcutt (snorthc@relay-nswc.navy.mil) Disclaimer: I have no financial ties with any commercial vendor mentioned. I am NOT against transparency. I haven't even given up on NetBIOS (should the OS/2 extensions prove to work out). It is simply my personal opinion that NetBIOS/TCP for DOS is not a workable solution.
snorthc%NSWC-OAS.ARPA.CP6%LADC@BCO-MULTICS.HBI.HONEYWELL.COM (snorthc) (10/28/88)
> From: hpda!hpcupt1!hpisod1!renglish@ucbvax.Berkeley.EDU (Robert English) > Saying "users don't want to be bothered" trivializes the issue somewhat. > There are many DOS applications in which users never see the actual > files involved. The application presents them with menus to perform > tasks, and manages the files itself. A user who had to transfer all of > the necessary files over via FTP would have to be much more > sophisticated than one who merely used the application. I agree with most of what you say above. > Furthermore, there is the issue of file-sharing. If users access the > files on the remote machine directly, they can share effectively share > data with other users. If they must copy the data back and forth, they > are likely to get inconsistent versions, forget to do the copies, etc. > (I know, you've never walked away from a terminal without writing out a > file). > Working in a non-transparent environment is significantly more > complicated than working in a transparent one. Here is where I have the problem. If you are talking theory or ideals you are right of course. If you are talking implementations of NetBIOS/TCP then perhaps the memory issue needs to be revisited. If you have an MS-DOS machine, you may find 256k or so of your available memory space gone to provide this transparency (example 3c505, FTP SW, IBM PC LAN program rdr). Cut off another 60 - 80k for DOS and many of the applications that provide the user with menus and manage the files cannot run. Then what does transparency buy you? There are work arounds. The Excelan implementation requires less memory, I think it was about 80k for RDR. Also for those with 80386 chips there are supposedly programs that allow TSR type SW or device drivers to run in memory space above 1mb. There is also OS/2 [I'm still waiting for the promised Oct update to my SDK Microsoft!!!!]. However, for the present, I have serious doubts that NetBIOS/TCP is providing usable services to anyone. It is my belief that the vendors who invested time/effort/ brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan, Bridge [they weren't 3Com at the time], Network Research Corp) wish they had placed their investment somewhere else like NFS or OSI or whatever. Finally file sharing. A simple file locking scheme may not be sufficient to make file sharing truly useful. Ever write code with someone else? What if the only mechanism for Source Code Control was that the file was locked after a user had it? That is why we RCS and friends. I have never written a document with anyone else, but I suspect you would run into some of the same problems. This is why multi-user databases handle their own locking (one reason they require so much memory). The point is you are still likely to get inconsistent versions with NetBIOS/TCP as your file sharing mechanism. It is not clear to me that an incomplete, memory hogging, broadcast based, transparent environment is less complicated than simply explictly transferring files with a mechanism like FTP or FTAM. Don't listen to me though, I wasn't able to figure out what a PS/2 would buy me either and do my development work on a Compaq, you see, I have already missed the boat :). Stephen Northcutt (snorthc@relay-nswc.navy.mil) Disclaimer: I have no financial ties with any commercial vendor mentioned. I am NOT against transparency. I haven't even given up on NetBIOS (should the OS/2 extensions prove to work out). It is simply my personal opinion that NetBIOS/TCP for DOS is not a workable solution.
bc@halley.UUCP (Bill Crews) (11/02/88)
I hope and doubt the readers of this group don't really need to be convinced of the value of network file systems versus network file transfer and network login, although a couple of the messages made it sound that way. If the argument is rather that NetBIOS in a DOS address space consumes an intolerable amount of additional RAM, I suggest that in my experience (with Excelan and UB stuff) is that it doesn't. I think what is happening is that some people have a prejudice, somewhat deserved, against NetBIOS, and that subverts all other rational thinking. We do it, and I'm glad we do, because there are a lot of people out there on IBM PC Networks, Token Rings, and other MS-Nets that want to share data, file system space, and/or printers with Unix users, and we give them that capability. We also provide NFS, in case people would rather use that. Why consciously segment network users from network resources? -bc -- Bill Crews bc@halley.UUCP (512) 244-8350 ..!rutgers!cs.utexas.edu!halley!bc
larry@tapa.UUCP (Larry Pajakowski) (11/02/88)
We use Netbios/UDP from Excelan and love it. We use Xenix on the host which allows us to develop both DOS and Xenix/Unix applications. Also since rsh is supported we use SCCS for source code control for the DOS applications. Total memory usage is about 70k on a 286 box and 7k on a 386 box thanks to QEMM from Quaterdeck. We use it and love it. A very happy Netbios over UDP user (TCP/IP stuff also). Larry larry@tapa.UUCP
backman@interlan.UUCP (Larry Backman) (11/08/88)
In article <8811010516.AA05874@ucbvax.Berkeley.EDU> snorthc@NSWC-OAS.ARPA writes: >To: tcp-ip@sri-nic.arpa > >Here is where I have the problem. If you are talking theory or ideals >you are right of course. If you are talking implementations of >NetBIOS/TCP then perhaps the memory issue needs to be revisited. >If you have an MS-DOS machine, you may find 256k or so of your available >memory space gone to provide this transparency (example 3c505, FTP SW, >IBM PC LAN program rdr). Cut off another 60 - 80k for DOS and many >of the applications that provide the user with menus and manage the >files cannot run. Then what does transparency buy you? > >It is my belief that the vendors who invested time/effort/ >brains/$$$$ to develop NetBIOS/TCP implementations (FTP SW, Excelan, >Bridge [they weren't 3Com at the time], Network Research Corp) wish >they had placed their investment somewhere else like NFS or OSI or >whatever. > [] An individual employee of a vendor's view: I've implemented NETBIOS on top of ISO as both a host based and board based protocol under both DOS and OS/2. Observations: 1). The board is 8 Mhz. 80186 based; the board based protocol is 50% as fast as the host based protocol. 2). The host based protocol takes up 128K of space under both DOS and OS/2. The board based protocool takes up less than 10K of space. 3). The board based protocol can support 32 sessions easily; the host based protocol can support at most 8-16 sessions before needing another 64K of memory for data buffers. Opinions: 1). Under OS/2 you want a host based protocol for performance; under DOS you want a board based protocol for memory. 2). Future DOS NETBIOS protocol stacks will be more cognizent of Expanded memory version 4.0; there is no reason why a 128K driver can't use 64K of DOS memory for code, and a large chunk of expanded memory for data; this would save valuble DOS memory, and also allow more data buffers; i.e. more sessions. Larry Backman Interlan, Inc.