INFO: 16-bit IPX Sequencing on Windows NT
ID: Q177282
|
The information in this article applies to:
-
Microsoft Windows NT 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 kbNTOS350 kbNTOS351 kbNTOS400 kbSDKPlatform kbGrpNet
Version : winnt:3.5,3.51,4.0
Platform : winnt
Issue type : kbinfo