|
1.) Orderly release was found not to work in previous versions of spxs.nlm ,this version now has this functionality built in.
2.) Tirpc was discovered to have more problems with spxs.nlm , the remaining issues have been fixed. Tirpc is no longer supported by Novell .
3) An abend with the error message : Free detected modified memory beyond end of the cell being returned. Has been fixed.
4.) An page fault was occuring because , spxs was corrupting the ecb because read write pointers were pointing to the same data block.
5.)There were also several abends involving spx II negotiation of packet sizes unrelating to the above issues that were fixed.
6.) Server abends on spxs.nlm in large environments where over a 1000 SPXS connections are possible . This problem is encountered when the system calls for a number of sessions over the configured limit. Setting the Maximum concurrent sessions to 2000 in spxconfg was a work around for this problem until this fix.
7.) For a loop back SPXS connection , Congestion Window implementation had a problem. This would particularly affect backup programs like Sbackup, and Cheyenne's Arcserve. This was fixed in this version.
8.) SPXS would not send a T_DISCON_IND message up when its read queue is full. Hence, if we make an SPX connection, transfer data and bring one end point down, the other end point will never close the connection.
9.) When DISCON_REQ and DISCON_IND are received simultaneously, queue is flushed leaving other pending DISCON up and hung. This was changed to notify the application that it was done.
10.) Corrected bugs in the error recovery algorithms.
a. Removed the doubling of srtt (mean rtt) during exponential back off.
b. Calculation of rtt for retried packets removed.
c. Packets are time stamped just before they are passed to IPX.
d. An upper limit on rtt value imposed.
The above corrections improved the performance of SPXS over WAN links. This also fixed problems with remote backup applications. This fix is major and obsoletes ALL other versions of SPXS.
11.) Whenever an ECB is copied and sent to SPXS, free the original ECB by calling LSLFastSendComplete.
Fixes: LSL Receive ECBs were lost with Managewise on 3.12 servers.
12.) A new function has been added to check the validity of ECBs received by SPXS. This checks the resource tag signature before accepting ECBs. Call to SendAcknowledge is done in interrupt mask.
Fixes: LSL Bad Resource Tag abend. (This problem seen with NW for SAA and other applications.)
13.) Hop count is reset to zero before sending out a packet.
14.) Removed the artificial delay in incrementing the round trip time when packets are getting lost.
Fixes: The Fast retransmit problem reported at a few sites.
15.) Added a check before freeing a data object.
Fixes: load spxs followed by junk input would abend a 3.12 server.
16.) Fixed the ManageWise-Win95 problem. SPXS now processes End Of Connection Acknowledge packets from a Win-95 workstation. (This would hang Netexplorer discovery.)
17.) Improved the congestion control mechanism in SPXS by introducing congestion window and slow start mechanisms.
18.) SPXS.NLM sends NAK packets when lost packets are detected. This fixes the streams queue runner problem to a great extent.
19.) Fixed the Managewise corruption problem that occurs after 2-3 hours in NXPIPX.
20.) Fixed problems with RPCBIND in NW3.12 environments that Affect TIRPC, SQL, and other applications.
21.) High utilization 98% and slowness during QA Testing .
22.) Abend: Page Fault Processor Exception., LSLFastSendComplete is returning an ECB who's address is in Streams.nlm alloc memory pool.
23.) Page fault in SPXS with running process SPXS Packet Queue, same problem as above.
22.) An abend was fixed in the SERVER.NLM|LSLSchedulelAESEventRTag..area the problem was actually in spxs.nlm.
23.) In an attempt to fix a serious problem at a site , a change was made that inadvertently affected a large number of users, the connection type on a server to server connection was always thought to be spxII type , it was found that there are certain applications that are true spx I type end-points requesting server to server connections. The spxs was changed to default to an spxs I type connection only in a server-server scenario (unless the calling app requested spxs II explicitly ). This logic proved faulty as many people had already taken advantage of the fact that they didnt have to call spx II , but knowing that a call to spx I automatically would result in a spx II connection in a server to server scenario. FOR NOW THE DEFAULT IS SPX II , This may be changed again , but by using a switch on the command line to allow the default to change. Client to server connections are NOT IMPACTED. The public will be informed once more changes are made.
24.) New fixes in this release are the following : ( as of 3/2/99)
a.) SPXS can send up to a maximum of 16 packets before getting any ACKs (windowing ) It's doing more than 16 in the case that it is trapping the server. The current send table is a circular list of 16 slots; the extra sends are causing entries to be overwritten and lost and also causes the last message in the send list to get freed into two different lists (its returned back to
streams and also put into an internal list in SPXS for later reuse).The remote connection says it can receive more than 16 packets, and SPXS does not limit itself. In all the coredumps this problem is occuring when the sequence numbers are crossing sequence 0. For example, in one coredump the remote station says SPXS can send from sequence FFFD -> 0010; another says from
sequence FFFC -> 000D. Even if the remote station allows a larger send window SPXS still needs to limit itself. This was fixed so that it would never accept more than 16 packets for a window EVER.
b.) When negotiating a spxs connection with a 3.x server, the packet size would always become 576 bytes. It was
found that a call to getRouteToDestination was not getting the proper packet size information. This was fixed.
c.) Because of the above two fixes it is even more critical to have the same version on all servers more than ever before.
25. ) The 3.1x verison of IPXS.NLM was changed to the correct verison number , The latest one now shows 3.12b instead of 3.11a.
RELEASE NOTES:
1.) Please note that if you are experiencing problems with spxs not accepting connection requests from client stations (i.e, connection request packet is denoted by 65535 in the destination connection i.d. field) meaning no response from the server to this packet, you may need to increase the maximum service processes available to the server. This is done via the SERVMAN utility. On NW 4.X, go to Miscellaneous, then to Maximum service processes. Set the number from its default value (10 ) to an appropriate value , say 30 to 40. This is changed on NW 3.x servers via the "set " command.
2.) Connections to AS400 systems via NW3.12 using spxs.nlm version "K" and later. This affects only those users who have configured the load and bind parameters in the autoexec.ncf. If you have configured the load and bind parameters through MPR(using the inetcfg utility) or have the enhanced IPX patch loaded, this issue will not affect you .
When loading Netware for SAA you will see the as400pcs console screen come up blank and connection requests to the as400 are refused. The current work around is to install the latest ipx patch. This patch can be found on the support connection web site under the minimum patch list, currently in ipx660.exe
3.) Please note that SPXS uses either an "explicit" or "default" route when trying to accept a connection request from a client. If the route information is not available, then spxs will not respond to the connection request. This may be a problem if the server happens to stop sapping. This may very well be caused by an old bug in IPXRTR.NLM, where the DEFAULT LSP size is set to 512.
On large networks, this is an issue. It is imperative that you load the latest version of ipxXXX.exe and make sure that the LSP size is set to 1024.IPXCON is also a good tool to use in order to see if the source Network can be seen from the target spxs server console. If not, then spx connections will NOT be serviced to that network.
4.) When using spxs for backup applications please use the same VERSION of SPXS on all of the servers that are involved in the backup. The fixes implemented here will NOT work if the versions are different. To identify the symptoms, load monitor, go to resource utilization, then to LSL Packet Receive buffers. You will see the lsl buffer count increase quickly to the maximum configured limit. You also may see the "Streams Q Runner" buffer climb to 100% utilization. This will result in the server running out of cache memory. The backup will be very slow or it will hang during operation.
Similar symptoms may occur when using fast Ethernet hardware configured for Full Duplex when not capable of it. See notes below.
5.) When a server runs out of spx connections the server simply refuses new connections. There is no error message stating this. The maximum configurable limit is 2000 sessions per server. Trying to exceed this limit will cause unpredictable results. Remember this has NO bearing on NetWare licensed connections.
6.) The SPXCONFG utility affects the timing in Native SPX (spx I protocol built into the server.exe file, used for many applications including Netware printing , Btrieve , and others) . BUT two are used for SPXS.NLM. These are the "Default Retry Count" and the "Maximum Concurrent SPX sessions". The other parameters DO NOT affect the SPXS NLM !!
7.) When configuring the SpxConfg utility , there are several places from which to permanently set the parameters for spxs. They are Servman, Autoexec.ncf, and the INETCFG utility. Setting the parameters in more than one place will cause unpredictable results. It is best just to use servman or inetcfg .
8.) Just a short note to discuss some of the differences between Native SPX and SPXS.NLM. Native SPX is what is known as SPX I. This version has limited functionality. To name a few, window of one packet (outstanding unacknowledged packets) and set packet size (576 byte packets only). This is an ECB-based program. Some of the applications that use this are Netware Printing , Rconsole, Pervasive Database software (formerly Btrieve) , Soft Solutions products, and NOVIX IPX >IP Gateway product, to name a few. The clients that use these products make an spx connection to the server on which they want to run the application, using the internal spx program built into the server.exe file (NATIVE SPX).
The Netware patches that are available, have patch files in them that refer to spx. These are specifically for Native SPX mentioned above. The spxconfg program will adjust the timeout values required for Native spx to function properly. These values are explained in detail in the Netware Client Dos/Windows Technical reference. Even though they relate to the client side , they still have the same meaning on the server side. Please remember that the values adjustable for Native SPX in spxconfg on the server are for server CLEANUP of sessions that are in "limbo", for whatever reason . It is highly unlikely that adjusting those values will impact a client disconnect problem.
It is up to the CLIENT to make sure that it's connection stays up. " Watchdogging" on the client side is for this purpose. Watchdogging on the server side, is to basically cleanup sessions already dead, by verifying the workstations are indeed unreachable by that particular connection I.D.
9.) The spxS.nlm (S for streams) is a streams-based application. It has the capability to run either spx I ( actually emulate spx I ) , and or spxs II type protocol , which supports windowing of up to 16 packets (unacknowledged packets outstanding), packet size negotiation (up to what the topology AND the particular network environment will bear ), and enhanced error recovery to name a few. As stated above, in note #6, spxconfg adjusts two parameters that impact this nlm . Applications that use this program are many (backup applications and NWSAA applications to name just a few). There are several public TIDS that describe Native spx and the spxs.nlm in more detail. The use of spx I and or spx II is up to the Client application and is hard coded. The spxs.nlm on the server "detects" whether the spx II bit is set or not and communication proceeds accordingly .
10.) The following explains the spxs.nlm watchdog process:
The Spxs.nlm watchdog timers are internal only and are NOT configurable on the server console . The default Watchdog time_out is set to 60 Seconds. If this timer kicks in , the connection has obviously long since run into trouble and was already retried numerous times by the client . As a matter of fact the client already may have RE-established the connection via a new connection I.D.
Therefore, the spxs.nlm Watchdog mechanism is strictly for connection cleanup and the user need not be concerned with this mechanism other than for informational purposes only. The client's Net.cfg or client 32 settings are the major concern for successful communication. These are only changed from default after it has been determined that the communication problem is spx related .
The following describes in detail , the timeouts and how they function:
a.) Verify Timeout - Interval between last packet sent and first watchdog packet. Expires after 3 seconds of no activity. An acknowledgment is not requested at this time. These are also known as watchdog packets, keep alive packets, etc. This has the SYS bit set in the packet. If a packet is received during this interval , the timer is reset. If there is still no answer, then proceed to the next step :
b.) Listen Timeout - This timer expires after 6 seconds of no activity. Once enabled, the packets will have the SYS and the ACK bit set. If still no response, then retry alternate routes. And, if still no answer, continue to the next step:
c.) Abort Timeout - This timer Expires after 30 seconds of no activity and of course the session is aborted if there is no response from the other end-point. The above Timer values here are "default" values and can be changed per the documentation . Be aware that they are cascaded, i.e, the verify, listen , and abort timeouts, have to be in ascending order, with the verify timeout being the lowest , and the abort timeout being the highest.
11.) Fast Ethernet (100 Mbps) requires some special attention. It is necessary to note that before setting the network adapters to "full duplex" that you verify the hubs are full duplex switching hubs. This allows the adapter to send and receive packets at the same time. Furthermore, if you have auto-negotiation capabilities on your hub, you can set the adapter to auto. If the hub does not have auto-negotiation built in, and the adapter is set to auto, it will run at half duplex. Even if you are running at 100 Mbps and half duplex, the bandwidth potential is higher than if you run at 10 Mbps and full duplex. If you experience problems running with spxs at full duplex, the problem may be that the hub does not support full duplex, set the adapter(s) to half duplex, to see if the condition persists.
12. ) On " bursty " networks, i.e, where the Round trip time continuously varies, please be aware that spxs.nlm calculates this value for each and every connection on the server. If the Round trip time changes on the next packet received, spxs.nlm now bases what it expects to be a reasonable time for a reply from the other endpoint on the previous round trip time (RTT ) it calculated. This may result in another packet being resent immediately by spxs.nlm if it doesnt get an ack back. This is normal behavior and is not a bug. Trace analysis tools may label these packets as "Fast Retransmits".
13 .) Orderly release is not in this release of spxs.nlm. Informed disconnect is the method of disconnecting a connection. Orderly release is available in the next version. Orderly release allows data transmission to finish gracefully before disconnecting the connection .
14.) There have been some reports on Netware 3.12 servers using applications that require spxs.nlm. When loaded manually (through autoexec.ncf ) sometimes the short term memory will be quickly used up by streams. It was found that by letting the application desiring spxs services autoload the spxs.nlm from this release, it resolves this issue.
15.) SPXWDOG.NLM is used to disable the SPX watchdog mechanism . This is a work around to solve problems with spoofing SPX Watchdogs in remote access products like Netware Connect. SPX Watchdogs are not labeled and hence it becomes difficult to spoof them. Loading SPXWDOG.NLM will add the following file server set parameter. This does not disable the file server watchdog for NCP connections. In most cases spx watchdos should be set to ON.
"set spx watchdogs=ON/OFF" The default is ON.
This program runs on 3x and 4x servers. To fully disable watchdogs, the remote client/server should also disable the watchdogs. IPXODI v3.02 and IPX.NLM (32 bit IPX for the client) support a NET.CFG parameter (Syntax: "spx watchdogs on | off" Default: On) to disable SPX watchdogs. Patchman is not required for this NLM since this program runs on all versions of the NW OS.
|
