Checking IPX communication and obtaining node addresses

Download demo project - 61 Kb

In a recent project that uses an IPX protocol for communication between multiple Windows NT stations and multiple DOS stations, I needed to find out the IPX node address of the local computer as well as the node addresses of all computers on the network (running under Windows or DOS). So, I designed 2 programs (one 32 bit for Windows and the second 16 bit for DOS) that support the same custom packet type. The final result is an application that shows the node address of each computer in a network that is running either one of the programs together with the local time on each computer.

On DOS side, I am using a direct interrupt call to IPX/SPX driver installed on a DOS machine. On Windows side, I am using Winsock 2 API for IPX communication. Setting up initial communication was a bit complicated but the final code is very simple.

The idea is the following: Each application is running under a timer. When timer expires (1 second), the application broadcasts a packet with its local time and its user defined name. This broadcast packet is catched by all stations (including the sending station) and is displayed in a list. If it already exists in a list, the list item is updated. Since this is a connectionless communication, technique for obtaining the sender's IPX node address is different for DOS and Windows. DOS code directly takes the sender's node address from the IPX packet. However, since Windows application is using Winsock 2, access to packet structure is not available. Within a Winsock window message handler, application executes a recvfrom() function call that returns a node address of the sender.

These 2 applications proved to be very useful since one can obtain all the node addresses but also (and this is very important) can check whether the support for IPX communication is installed on the machine (either Windows or DOS) and check whether the IPX communication is running correctly (even if all is ok, stations may be invisible to each other if an Ethernet frame type is not the same). So, these 2 applications are also a good diagnostic tools.

I plan to work on the same application (only Windows version) that supports the TCP/IP protocol (actually only IP since it is going to work using an UDP protocol). You can check for the latest info on www.scasoftware.com.