TCP/IP UNAPI standard discrepancy - what to do?

By Eugeny_Brychkov

Paragon (1169)

Eugeny_Brychkov's picture

20-05-2019, 17:46

If you look at this document you can see that UDP_STATE and RAW_STATE have registers confused:

4.4.3. TCPIP_UDP_STATE: Get the state of a UDP connection
Input: A = 10
B = Connection number
Output: A = Error code
HL = Local port number
B = Number of pending incoming datagrams
DE = Size of oldest pending incoming datagram (data part only)
4.6.3. TCPIP_RAW_STATE: Get the state of a raw IP connection
Input: A = 22
B = Connection number
Output: A = Error code
B = Associated protocol code
HL = Number of pending incoming datagrams
DE = Size of the oldest pending incoming datagram

IMHO the RAW_STATE must have

L = Associated protocol code
B = Number of pending incoming datagrams

the same as UDP_STATE.

I asked Nestor about it, and he says that he sees not problem in it. I am in a deep in networking/packet/protocol stuff, and believe this register confusion is systemically wrong.

I have several ways to go:

  1. use Nestor's API 1.0;
  2. fork new API 1.1 with corrected register input (and some other changes like references to IP addresses and configuration logic).

I have no major problems with other parts of the standard, but the IPRAW part seems to be unfinished. Does anyone use it / coded for IPRAW?

Any advice on how to proceed?

Login or register to post comments

By Grauw

Ascended (9343)

Grauw's picture

20-05-2019, 19:56

I understand Nestor's refusal to introduce a breaking API change. I think whether two somewhat similar methods on a different OSI layer (protocol code (8-bit) != port number (16-bit)) use similar registers does not show any systemic wrongness. TCP_STATE isn’t similar either, so why should UDP_STATE be.

If the API compatibility is broken, there are deployed implementations and applications to consider, which would all need to be updated, as well as bringing those updates to all users. This creates a big hassle for developers and users, and Nestor would be doing us a disservice if he made such an unstable standard.

Additionally, as a developer it's no problem to receive data in maybe slightly inconsistent registers, which one typically wouldn't even encounter. While it’s a big hassle to deal with incompatible APIs, requiring me to call different signatures depending on the version, and of course to know about this in the first place (or receive bug reports from users and needing to own the affected hardware). UNAPI is meant to unify, you'd be introducing fragmentation by making a new-standard-similar-to-but-not-UNAPI, and of course GR8NET has its own API as well.

My very strong advice is just to accept this small imperfection in the UNAPI standard. If there would be a fundamental issue things might be different, but this sounds far from it.

By Eugeny_Brychkov

Paragon (1169)

Eugeny_Brychkov's picture

21-05-2019, 12:08

Agreed. Finally the issue is not worth the damn. My apologies for disturbing you and Nestor. It is always good to ask people out there what they think about crazy and stupid ideas and inexistent issues Smile

By konamiman

Paragon (1084)

konamiman's picture

21-05-2019, 13:18

You know what they say, the only stupid ideas are those that are never asked. And crazy ideas sometimes change the world. Wink