289 lines
15 KiB
Plaintext
289 lines
15 KiB
Plaintext
(Note: AppNote August 1990)
|
|
|
|
A Comparison of NetWare IPX, SPX and NetBIOS
|
|
|
|
Bill Bodine
|
|
Consultant
|
|
Systems Engineering Division
|
|
|
|
Abstract:
|
|
|
|
One of the first questions always asked during comparisons of NetWare
|
|
IPX, SPX and NetBIOS is which of these protocols will transfer data
|
|
the fastest, and how much slower the others are. This AppNote details
|
|
the results of four benchmarks written to illustrate the relative
|
|
speed of each of these communication interfaces. Performance, maximum
|
|
packet length, naming capabilities and memory usage are each singled
|
|
out as additional factors in the decision to implement systems using
|
|
these protocols. Clarification and explanation of SHELL.CFG parameters
|
|
are also included.
|
|
|
|
Novell, Inc. makes no representations or warranties with respect to
|
|
the contents or use of these Application Notes, or any of the third-party
|
|
products discussed in the AppNotes. Novell reserves the right to revise
|
|
these Application Notes and to make changes in their contents at any
|
|
time, without obligation to notify any person or entity of such revisions
|
|
or changes. These AppNotes do not constitute an endorsement of the
|
|
third-party product or products that were tested. The configuration
|
|
or configurations tested or described may or may not be the only available
|
|
solution. Any test is not a determination of product quality or
|
|
correctness, nor does it ensure compliance with any federal, state or local
|
|
requirements. Novell does not warranty products except as stated in
|
|
applicable Novell product warranties or license agreements.
|
|
|
|
Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved.
|
|
|
|
As a means of promoting NetWare Application Notes, Novell grants you
|
|
without charge the right to reproduce, distribute and use copies of
|
|
the AppNotes provided you do not receive any payment, commercial benefit
|
|
or other consideration for the reproduction or distribution, or change
|
|
any copyright notices appearing on or in the document.
|
|
|
|
Introduction
|
|
|
|
When Novell began operations in 1982, several proprietary protocols
|
|
for transferring data between workstations were used. As time went
|
|
on, the decision was made to base Novell's network communications
|
|
on a fast and efficient networking standard. Xerox's XNS protocol
|
|
was determined to be one of the best available at the time so Novell's
|
|
Internetwork Packet Exchange (IPX) protocol was developed to conform
|
|
to the XNS standard. NetWare IPX is functionally equivalent to Xerox's
|
|
Internet Datagram Protocol (IDP).
|
|
|
|
This AppNote discusses the three primary peer-to-peer protocols
|
|
that are supported in the NetWare LAN environment-NetWare IPX, SPX
|
|
and NetBIOS. Additional protocols supported include the Transport
|
|
Layer Interface (TLI), Named Pipes, LU6.2 and others, but are not
|
|
covered in this AppNote.
|
|
|
|
NetWare IPX
|
|
|
|
NetWare IPX is a true datagram protocol. It makes a best-effort
|
|
attempt to send packets by using a 12-byte addressing scheme.
|
|
The 12-byte address is split into three addresses: the network
|
|
address, which is used to address individual workgroups; the node
|
|
address, which addresses network nodes within the workgroups; and
|
|
the socket address, which can be used to multiplex between functions
|
|
within a network node. When sending an NetWare IPX packet from one
|
|
node to another, the sending node must know the receiving node's 12-byte
|
|
address.
|
|
|
|
SPX
|
|
|
|
The Sequenced Packet Exchange protocol (SPX) is a connection-oriented
|
|
communications protocol that is built upon NetWare IPX. When a call
|
|
is made to SPX to send a packet by an application program, SPX will
|
|
do some housekeeping-type work on the packet, but will call NetWare
|
|
IPX to actually send the packet. SPX guarantees packet delivery, whereas
|
|
NetWare IPX only gives a best effort to deliver packets. This added
|
|
feature of SPX has obvious advantages, but as we shall see later in
|
|
the paper, it also adds overhead to the data transfer cycle and is
|
|
slower.
|
|
|
|
NetBIOS
|
|
|
|
The Network Basic Input/Output System (NetBIOS) functions in either
|
|
a connectionless mode or a connection-oriented mode. An application
|
|
written to the NetBIOS interface can be designed to use either of
|
|
these modes. For instance, if an application functions in a request/reply
|
|
mode with a transfer size of only one packet, then the connectionless
|
|
mode should be used to take advantage of connectionless response times.
|
|
On the other hand, if most of the transfers are one-sided or consist
|
|
of large numbers of packets, the transfers should use the connection-
|
|
oriented mode in order to ensure packet delivery and integrity of data.
|
|
Novell's NetBIOS emulator is built upon NetWare IPX in the same way
|
|
that SPX is.
|
|
|
|
The NetBIOS emulator is called an emulator because it is implemented
|
|
entirely in software, whereas the original NetBIOS introduced by IBM
|
|
and Sytek was located in firmware.
|
|
|
|
Because NetBIOS was introduced by IBM, it was almost instantly accepted
|
|
as an industry standard. Most networking vendors have implemented
|
|
the specification given by IBM that allows almost any application
|
|
written to the NetBIOS interface to operate in any environment.
|
|
|
|
A common problem with the NetBIOS specification, however, is that
|
|
it only deals with the upper layer functions of the interface. It
|
|
does not specify what communications protocol should be used underneath
|
|
it. As a result, almost every networking vendor has written NetBIOS
|
|
on top of their own proprietary communications protocol, which cannot
|
|
communicate with other vendors' protocols.
|
|
|
|
A nice feature that NetBIOS has to offer the networking industry is
|
|
its allowance of easy address resolution among locally-connected
|
|
workstations. All nodes on a network that use NetBIOS register a unique
|
|
name. When a node desires to communicate with another node, all it
|
|
needs to know is the node's unique NetBIOS name and NetBIOS will ensure
|
|
that the packet arrives at the proper location.
|
|
|
|
Performance Results
|
|
|
|
One of the first questions regarding the comparison of NetWare IPX,
|
|
SPX and NetBIOS is which of these protocols will transfer data the
|
|
fastest, and how much slower the others are. As part of this AppNote,
|
|
four benchmarks have been written to illustrate the relative speed
|
|
of each of these communications interfaces. The scope of the benchmark
|
|
is relatively simple-to send 2,000 255-byte packets and to record
|
|
the time that it takes for the transfer to complete. All the programs
|
|
were written by the same person and were intentionally kept as simple
|
|
as possible to make each benchmark represent the speed of the interface
|
|
and not efficiencies or lack thereof in the benchmark tests.
|
|
|
|
Each of the benchmarks encompassed two programs. One program
|
|
was used to send packets and the other was used to receive. The sending
|
|
side sent a packet and then incremented a counter. Before the packet
|
|
was sent, a call was made by the sender to the system clock. Once
|
|
the 2,000th packet had been sent successfully, another call was made
|
|
to the system clock. The first value was subtracted from the second
|
|
and the result represented the time in clock ticks that it took to
|
|
send 2,000 packets on the given communication interface. The receiving
|
|
side did nothing but receive packets and count the number that arrived.
|
|
No other processing took place within the code.
|
|
|
|
The following results were achieved on standard 8MHz 80286-based
|
|
machines on a 4MB Token-Ring network. While the test does not
|
|
represent any real-world scenario, it does indicate the relative
|
|
speed of each interface tested.
|
|
|
|
NetWare IPX 366.0 packets per second
|
|
|
|
SPX 140.3 packets per second
|
|
|
|
Novell NetBIOS datagram 224.8 packets per second
|
|
|
|
Novell NetBIOS session 135.9 packets per second
|
|
|
|
NetWare IPX is the fastest protocol available from Novell. This is
|
|
expected since all others are written in terms of NetWare IPX. SPX
|
|
and NetBIOS are slower than NetWare IPX due to the extra overhead
|
|
they introduce into the communications process. SPX and the NetBIOS
|
|
session level interface run at virtually the same speed. They both
|
|
have to maintain the same level of connection overhead for the
|
|
guaranteeing of packets and are both written in terms of another
|
|
interface.
|
|
|
|
Other Decision Criteria
|
|
|
|
There are a few primary differences between writing an application
|
|
to NetWare IPX or SPX and writing an application to NetBIOS. Two of
|
|
these differences deal with the maximum length of packets that can
|
|
be sent and the address resolution.
|
|
|
|
Maximum Packet Length
|
|
|
|
With NetWare IPX and SPX the maximum packet size that can be sent
|
|
by an application depends on either of two things. If the packet to
|
|
be sent must cross a NetWare bridge, the maximum packet size possible
|
|
is 576 bytes. The bridge will drop any packets that exceed this size.
|
|
|
|
On the other hand, if the packet will not be crossing any bridges,
|
|
the network interface card (NIC) drivers limit the size. While most
|
|
drivers allow packets of 1,024 bytes or larger to be transferred,
|
|
NetWare documentation recommends that the maximum size transferred
|
|
be 576 bytes. This is in case the packet crosses a bridge or the driver
|
|
cannot handle larger packets.
|
|
|
|
NetBIOS allows an application to send packets up to 64KB in size.
|
|
This is possible because the NetBIOS emulator breaks the packet into
|
|
smaller packets for the application and sends them out in sizes that
|
|
can be handled by NetWare IPX and the NIC drivers. While this feature
|
|
is useful, some developers choose to split packets up themselves in
|
|
order to optimize the NetWare IPX bandwidth for their application.
|
|
This may or may not be a factor in different situations.
|
|
|
|
Naming Capabilities
|
|
|
|
The second primary difference is the naming capability supplied with
|
|
NetBIOS. NetBIOS makes it convenient for an application to determine
|
|
the addresses of other nodes on the network. Each workstation identifies
|
|
itself with a particular name. Once any other workstation on the LAN
|
|
knows that name, data can be sent between the two workstations.
|
|
|
|
Novell recognized the need for this easy address resolution when it
|
|
developed NetWare IPX, so the Service Advertising Protocol (SAP) was
|
|
developed. With SAP, a node advertises, or broadcasts to the entire
|
|
network its name and address. This name and address are stored internally
|
|
on all NetWare network file servers. When any other node wants to
|
|
find an address, it queries a NetWare file server and the necessary
|
|
information is returned. There are also other ways of finding an address
|
|
without accessing the NetWare file server, but they are not as common.
|
|
|
|
Both of these methods have advantages and disadvantages. While it
|
|
is probably easier for an application with the naming capability of
|
|
NetBIOS to be developed, using the SAP provided by NetWare does not
|
|
require much more work. The advantage gained by using the SAP is that
|
|
once the address is resolved, the underlying protocol is very fast.
|
|
The SAP is designed for a client-server environment, which means
|
|
that a client always initiates a dialogue with the server. The client
|
|
can always find the server's address through the SAP. Since all packets
|
|
on the network contain the 12-byte address of the node they were
|
|
sent from, the server will know which address to send responses to.
|
|
|
|
Memory Usage
|
|
|
|
When an application runs on a network workstation, particularly in
|
|
the DOS environment, the amount of memory that is free for the application
|
|
to use is often a primary concern. In NetWare the first software to
|
|
load on the network is a terminate-and-stay-resident (TSR)
|
|
program called IPX.COM. This program contains all the interfaces needed
|
|
to run NetWare IPX programs and SPX, and uses about 14KB of workstation
|
|
memory. This is the only piece of NetWare software that needs to be
|
|
run in the workstation if no communications are needed with any file
|
|
servers. If a file server is needed, the TSR NET3.COM is loaded after
|
|
IPX.COM. This program contains all the functions needed by the workstation
|
|
to communicate with any NetWare file server on the LAN. It uses about
|
|
38KB of workstation memory. NetBIOS is an optional TSR like NET3.
|
|
IPX.COM must be loaded first. When NetBIOS is loaded it takes up about
|
|
30KB of workstation memory. Just as NET3 is only used when communications
|
|
are sent to a NetWare file server, NetBIOS is only run if an application
|
|
needs to use the NetBIOS services. Native NetWare does not use NetBIOS
|
|
for any of its communications services.
|
|
|
|
Appendix A lists parameters that have been modified in the recent
|
|
versions of NetBIOS. Because of the differences among versions, they
|
|
will be discussed as they relate to the specific versions.
|
|
|
|
The values listed in Appendix A are approximates. It is not possible
|
|
to state exactly how much memory any of the three protocols will use
|
|
up because they all contain custom parameters that change their sizes
|
|
and configurations. The parameters that alter these configurations
|
|
are located in a file named SHELL.CFG. As IPX.COM or NetBIOS.EXE is
|
|
loaded, it looks for this file in the local directory or a search
|
|
directory. Once it locates SHELL.CFG it searches within the file to
|
|
determine if any of its default parameters have been altered. These
|
|
parameters can be configured from within the SHELL.CFG file. Appendix
|
|
B of the NetWare Supervisor Reference manual also explains
|
|
the parameters.
|
|
|
|
Conclusion
|
|
|
|
While the primary advantage of writing to NetWare IPX is speed, the
|
|
main advantage of writing to NetBIOS is that the application will
|
|
work on other environments in addition to NetWare. This should obviously
|
|
be considered for applications that are marketed on a variety of platforms.
|
|
|
|
Even though different vendors' NetBIOSs can rarely communicate with
|
|
each other, most applications do port well over these vendors'
|
|
implementations.
|
|
|
|
There are a variety of reasons applications are developed to
|
|
one protocol or another. One reason a protocol is chosen is because
|
|
it is perceived as the defacto standard. For many developers, NetBIOS
|
|
is seen as a standard. Applications are developed to that platform
|
|
for reasons of portability to a variety of environments. On the other
|
|
hand, many developers are developing to NetWare IPX because they recognize
|
|
NetWare's large market share and want to reach the greatest market
|
|
possible with the most efficient protocol available.
|
|
|
|
Sometimes, one protocol may be perceived as easier to develop to than
|
|
another. Of course whether one is actually easier than another depends
|
|
entirely on the resources that are available, such as the Novell C
|
|
Interface libraries for NetWare IPX and SPX, the experience of the
|
|
development team or even available documentation and training.
|
|
|
|
Appendix A: SHELL.CFG Parameters
|
|
|
|
******* Note: The appendix (mostly outdated info) has been removed ********
|
|
|