Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / NOVELL / AN008B.ZIP / AN008B.TXT

Wrap

Text File | 1991-01-29 | 25.4 KB | 525 lines

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 Version 2.0a NetWare IPX Sockets Sockets are typically used by NetWare IPX to determine which process within a given node is to receive a packet. For any process to receive an NetWare IPX packet, it must first open a socket and then "post" a listen on that socket. When NetWare IPX receives a packet, it checks the destination socket number and delivers the packet to the process that is listening on that socket. The default number of sockets that can be opened in one workstation is 20. This can be altered to include any value from 10 to 150. NET3 uses up a few NetWare IPX sockets when it is loaded, but even with those included, rarely than more than 20 sockets will be needed at one time. NetWare IPX Retry Count This parameter deals with SPX, NET3 and NetBIOS. When any one of these modules fails to transfer an NetWare IPX packet, the transfer is automatically repeated. The number of times it retries is based on the value set in this parameter. The default is 20, but the value can be set from 0 to 255. Obviously, either of these extremes is not advisable. If the value is too low, connections will constantly timeout. If the value is too high, workstations will take a long time detecting broken connections. SPX Connections This option controls the maximum number of SPX connections that can be used at any given time. The default value is 15, while the minimums and maximums are 5 and 150 respectively. In a client-server type environment the default will be sufficient for the client side, but the server side may require the maximum to be increased, depending on how many clients exist at any one time. Before this value is arbitrarily raised it should be recognized that by increasing the number of SPX connections in the SHELL.CFG file, IPX.COM will use up more of the workstation memory. For each SPX connection that is configured SPX will use 54 bytes of RAM. SPX Listen Timeout SPX uses what are called watchdog packets to ensure that sessions between workstations remain active when no other activity is occurring on the session. SPX listen timeout, along with the following two parameters, is used to signal to SPX when a watchdog packet should be sent or when one should have been received from the other workstation. If SPX has not heard from the workstation on the other side within the time specified by SPX listen timeout, it will send a watchdog packet asking the other side to respond. The time is indicated in clock ticks. The default is 108 ticks (about 6 seconds). The minimum and maximums range from 0 to 64KB, although setting the value greater than SPX abort timeout (see next entry) will have no improved affect. SPX Abort Timeout SPX abort timeout controls how long an SPX connection has waited to hear from the other side and determines the other side is no longer communicating. If it is necessary to have a session timeout faster than normal, this option can be modified. The default value is 540 ticks (about 30 seconds), and the minimum and maximum values are the same as in the previous option. SPX Verify Timeout This option determines how often packets should be sent to the other side, to indicate. The default is 54 clock ticks (about 3 seconds), and the minimum and maximum values range from 0 to 64KB. Ipatch This option allows the user to patch any location within the NetWare IPX data segment with any value desired. Npatch This option allows the user to patch any location within the NetBIOS segment with any value desired. NetBIOS Session This option is used in the same way as the SPX connections option. The minimum value that can be set is four and the maximum is 250. The emulator uses 88 bytes of RAM for each NetBIOS session configured. NetBIOS Commands When an application makes any request of NetBIOS, a command is issued. By default, 12 commands can be outstanding within NetBIOS. In other words, if 12 requests have been made to NetBIOS, NetBIOS must respond to at least one of the requests before more requests can be made. This parameter allows a user to configure the number of outstanding commands to any value between 4 and 250. For each NetBIOS command that is configured, the emulator will use 64 bytes of workstation memory. NetBIOS Send Buffers When an application requests NetBIOS to send a packet, control information must be initialized for each packet sent. NetBIOS allocates space for as many control buffers as are configured by NetBIOS send buffers. NetBIOS is a Stop-and-Wait protocol. This means that if an application hands two packets to NetBIOS to send, the second will not be sent until the first has successfully arrived at its destination. NetBIOS requires some buffering space for this second packet. That space is essentially accommodated by this configuration parameter. The default value for this option is six. The minimum and maximum values are four and 20, respectively. Sixty two bytes of RAM are used by the emulator for each send buffer that is configured. NetBIOS Receive Buffers This option is similar to the previous option, except that it relates to the number of receives that can arrive at a workstation. Most applications have the ability to receive a number of packets at a time. For example, five requests may be made to NetBIOS to listen for arriving packets. As NetBIOS receives packets, it puts the control information pertaining to those packets in the space allocated by NetBIOS. If a second packet arrives while NetBIOS is still processing the first packet, there must be space to buffer that packet until NetBIOS is able to finish processing the first packet. The configurable values are the same for this option as for the previous one. Under most circumstances the default values should suffice. Under extreme conditions, however, they may need to be bumped. If many sessions are sending data to NetBIOS, increasing this value may improve throughput. As with the send buffers, the emulator uses 62 bytes of RAM for each receive buffer that is configured. NetBIOS Listen Timeout This option and the next two function in exactly the same in NetBIOS as do the corresponding options in SPX. NetBIOS Abort Timeout See SPX abort timeout. NetBIOS Verify Timeout See SPX verify timeout. Version 2.1 NetBIOS Retry Delay When an application registers a unique name with NetBIOS, NetBIOS broadcasts the name to every other NetBIOS workstation on the network. If any other workstation has the name already registered, it sends a response packet to the workstation trying to add the name. This indicates that the name has already been registered elsewhere. For this scenario to work properly, the workstation adding the name must wait to hear from all others on the network. On large networks with many bridges this can take much longer than on small networks. This parameter is used in conjunction with the NetWare IPX retry count to determine the time the workstation will wait when registering a NetBIOS name. The node attempting to register the name sends out as many packets as are specified by NetWare IPX retry count. The time between each send is given in NetBIOS retry delay. If both of these values are decreased, the time it takes to add a name will also be decreased. The options are also used when a node is trying to determine the address of another node on the network. The first time a packet is sent to another node, NetBIOS sends a broadcast on the network asking for the workstation that has the name registered to please send a packet indicating its address. Once this packet is received the node knows where to send the packet. This process requires the requesting workstation to give every node on the LAN the chance to respond. In addition to the naming functions, this parameter is used for session maintenance within NetBIOS. When communicating on a session in NetBIOS (or SPX) an acknowledgment (ACK) is sent for every packet that is initiated on the session. For example, if station A sends a packet to station B, the NetBIOS emulator in station B will send an ACK to A. If A never receives the ACK, it will assume the packet was lost and will re-send the packet. NetBIOS retry delay is used to determine the time a station will wait for an ACK before it assumes the packet was lost. NetWare IPX retry count is also used to determine how many times the station will re-send the packet before determining the transmission is hopeless. Version 2.15B NetBIOS Retry Count In this version of the emulator, this parameter replaces NetWare IPX retry count for determining how long NetBIOS should wait when adding a name or querying the network for the address of a name. It also replaces NetWare IPX retry count when determining how many times to re-send lost packets before determining that a session is no longer functional. Version 3.01 In this version of the emulator, the naming functions and the session maintenance functions are separated into four different parameters. NetBIOS Retry Delay This parameter now deals exclusively with session maintenance within NetBIOS. NetBIOS Retry Count This parameter is also used entirely for session maintenance in this version of the emulator. NetBIOS Broadcast Delay This parameter deals entirely with name resolution in NetBIOS. NetBIOS Broadcast Count This parameter also deals exclusively with name resolution. NetBIOS Internet If NetBIOS will be used over LAN bridges, this value should be set to on. This indicates that packets are going to take longer to traverse the entire internetwork. In such a case, the values for NetBIOS retry count, NetBIOS broadcast count, and NetBIOS broadcast delay are by default 20, 4 and 38 respectively. If NetBIOS internet is set to off (all communication will be done on one network), the default values are 10, 2 and 18. If any of these parameters is set within SHELL.CFG, the defaults presented by this parameter will not be used. As can be seen by the options that can be configured with these protocols, there are many timing issues involved with them. Any time a connection service is offered, timing becomes a key issue. Timing also plays a key role in the naming functionality associated with NetBIOS. It is mostly for this reason that NetBIOS is not considered to be a useful protocol for wide area communications. Much of NetBIOS deals with waiting for workstation responses. Operation of the NetBIOS protocol would be prohibitively slow if it also had to wait for responses from networks or nodes connected over slow link lines. It is for this reason that Novell says its NetBIOS emulator is not supported over lines slower than 1 Mbit/s.