Microsoft KB Archive/177282

{|
 * width="100%"|

INFO: 16-bit IPX Sequencing on Windows NT

 * }

Q177282

-

The information in this article applies to:


 * Microsoft Windows NT Server versions 3.5, 3.51, 4.0
 * Microsoft Windows NT Workstation versions 3.5, 3.51, 4.0

-

SUMMARY
Windows NT provides support for 16-bit applications that use the ECB IPX interface if you have installed Microsoft's Client Services For NetWare. Most applications that use this interface work under Windows NT, but there are some characteristics that cause it to act differently and that might cause application problems. In particular, applications that use IPX (this is not a problem for SPX applications) might receive packets out of order more frequently than on other implementations. Also, when your application receives a steady stream of IPX packets, the IPX packets may appear to your application in bursts.

MORE INFORMATION
Under 16-bit Windows and Windows 95, IPX packets are delivered to IPX applications during interrupt time since you are basically communicating directly with the IPX VXD when you use the interface. As a result, applications that closely monitor when packets arrive (when the ECB InUse field is zero) "see" the arrivals occur one packet at a time.

Due to the way 16-bit applications run under Windows NT, this direct access to the driver is impossible. As a result, if you receive several packets in succession, they may appear to complete at basically the same time. In addition, when Windows NT copies the IPX packets into the buffers allocated by the submitted ECBs and if it has a handful of ECBs completing at the same time, it may copy them into the ECB buffers in the reverse order of how the ECBs were posted.

For example, if your application posted ECB1, ECB2, ECB3, and ECB4 for data receipt in that order and packets P1, P2, P3, and P4 were received in close succession, there is a good chance that P1 will be placed in ECB4, P2 in ECB3, P3 in ECB2, and P4 in ECB1.

Technically IPX does not guarantee packet sequence order since it is a connectionless protocol. Therefore there is nothing wrong with Windows NT placing the packets in the ECBs in a different order. However, problems might occur if your application relies on a particular order of the received packets. Even if you design your application to be aware of the fact that you cannot guarantee the IPX order and you include code that accounts for out of sequence packets, your application probably does not have experience with the number of out of sequence packets that occur under Windows NT. Hopefully, this will not be a problem, but the end result is that Windows NT will potentially stress a path in the code that would probably not be sustained under a Win16 system.

Most applications that depend on sequence order use SPX instead of IPX. SPX guarantees the order of the packets delivered to the application so this would not be a problem for SPX applications. However there are a number of legitimate circumstances where you might want or need your application to use IPX and you might have to re-sequence the application's packets.

Additional query words: ECB IpxListenForPacket WOW

Keywords : kbnetwork kbAPI kbOSWinNT350 kbOSWinNT351 kbOSWinNT400 kbSDKPlatform kbGrpDSNet

Issue type : kbinfo

Technology : kbWinNTsearch kbWinNTWsearch kbWinNTW400 kbWinNTW400search kbWinNT351xsearch kbWinNT350xsearch kbWinNT400xsearch kbWinNTW350 kbWinNTW350xsearch kbWinNTW351xsearch kbWinNTW351 kbWinNTSsearch kbWinNTS400xsearch kbWinNTS400 kbWinNTS351 kbWinNTS350 kbWinNTS351xsearch kbWinNTS350xsearch