Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 374
  • Last Modified:

DOS IPX Header different than NLM IPX

I am trying to write a program with a DOS client and a Netware server NLM. The problem is that the DOS IPX and ECB headers are totally different than that of the Netware NLM IPX and ECB headers. Should I use the DOS headers with the NLM? Will this crash the server or will the Netware automatically add the rest of the DOS packet to form a Netware packet?
0
Claude050897
Asked:
Claude050897
  • 3
  • 2
1 Solution
 
bkcCommented:
The IPX packet format is the same across all platforms. The ECB structure is platform dependant.

You can not use the DOS ECB header in an NLM because pointer formats are different and the completion routine types are different.

I suggest you examine using TLI on the NLM side. We have implemented several SPX/IPX based DOS TSR's that communicate with
NLMs based on TLI for IPX and SPX.

Although I dislike TLI for TCP apps, for IPX and SPX its a better way to go as it allows you to treat IPX and SPX connections as
data streams.

Also, you must use TLI to take advantage of SPX II in an NLM.

Check out the developer NLM examples for server-side TLI IPX and
SPX programs.

0
 
Claude050897Author Commented:
Thanks, this will help very much. I have compiled and tested the SDK example for tli /dev/nspx but I get connection failed each time. Do you perhaps know how RSPX work with RConsole and if there is a SDK available for RSPX?
0
 
bkcCommented:
Are you trying to write on own rconsole?

The tli /dev/nspx examples require that you have spxs.nlm loaded
(and tli.nlm, streams.nlm), do you have these loaded?

If you have Netware 3.12 without patches, look for strtli4.exe patch (or a later one) that updates streams, spxs and tli.

Also, you can't run the client-side tli example without also having the server-side example running, otherwise there isn't an
spx socket listening for a connection.


0
 
Claude050897Author Commented:
I actually just got it going. The problem was that the address required to connect should be the INTERNAL node and network address of the server and not that of the actual network adpater which can be found with the CONFIG command. And no, I'm not trying to write my own rconsole, but just thought that RSPX might work the same as SPXS and IPXS. So all of this means that I now have to have a DOS client also working with TLI and that has to know the internal node and network address of the server it want to communicate with...
0
 
bkcCommented:
Your DOS client can use standard old IPX and ECB stuff, that's what we use. TLI is too big on DOS, in my opinion.

Its true that the server-side endpoint address will be based on the internal network number of your server.

If you use AdvertiseService() in your NLM, your DOS program can use SAP services to obtain the correct IPX address, you don't have to hard code it.

You can obtain a block of SAP codes and known sockets from Novell for use by your application. just request this through devsup. This way you can be assured you won't be colliding with any other
application. Using a fixed SAP type, and optionally a fixed SPX/IPX socket number makes it much easier for your DOS program
to locate the IPX address of the server via the Sap functions.

We use QueryServices on the DOS side to locate the NLM's IPX
address and socket number based on a pre-determined SAP type.

0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now