NWLink SPX Ignores Allocation Number Sent By Peer (151677)
The information in this article applies to:
- Microsoft Windows NT Server 4.0 Terminal Server Edition
- Microsoft Windows NT Workstation 4.0 SP3
- Microsoft Windows NT Server 4.0 SP3
This article was previously published under Q151677 SYMPTOMS
Under certain conditions, computers that connect to a process on a Windows
NT computer may fail. For example, the computer may time-out, applications
may stop responding, or the computer may disconnect. On the network you may
also see increased retransmissions.
This has been observed with SQL Server where clients access the database
using ODBC over SPX but it may happen with any SPX-based communication.
CAUSE
The SQL server numbers the frames (for example, 23) when it sends data to
the client. The client indicates that it has received the frame and
specifies with an Allocation Number if it can receive another frame (for
example, 24).
If the client-side SPX protocol cannot receive another frame because the
process did not copy the data and gave it another buffer, it does not
increment its Allocation Number (for example, send 23). This is especially
true for database applications as they may perform a considerable amount of
work locally.
The sending station should refrain from sending frames until it receives
another frame with an updated Allocation Number. The problem introduced in
Service Pack 2 is that Windows NT NWLink SPX ignores the Allocation Number
field and continues to send frames. After this happens, one of the stations
eventually decides that the session is out of synch and disconnects.
When the connection starts over the two stations are likely to run into the
same problem again.
RESOLUTIONTo resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the
Microsoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack
STATUSMicrosoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.
| Modification Type: | Minor | Last Reviewed: | 9/23/2005 |
|---|
| Keywords: | kbHotfixServer kbQFE kbbug kbfix kbnetwork KB151677 |
|---|
|