Re: re NetBIOS/TCP (UDP)


Larry Backman (mailrus!ulowell!interlan!backman@tut.cis.ohio-state.edu)
8 Nov 88 12:40:42 GMT


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.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:44:29 GMT