WIP UDP manual section 6.3.5. The wip_setOpts Function

6.3.5. The wip_setOpts Function
The options supported by the wip_setOpts function, applied to a UDP are:

// The following documented option doesn’t work - using it causes - ERRLOG …/src/ch_udp.c:386: returned WIP_CERR_INVALID
WIP_COPT_PEER_ADDR wip_in_addr_t Address of the peer socket, as a 32 bits integer. default:0
// this option should be removed from the table - or give us the WIP source code so that we can figure out what options are valid :smiley:

// the following option works fine:

WIP_COPT_PEER_STRADDR ascii* Address of the peer socket. If set to NULL on a pseudo connected UDP socket, remove the connection. default:0

// Thinking about the NULL functionality option of the string version precludes use of wip_in_addr_t (u32)

Please refer to sample udp_server for usage of WIP_COPT_PEER_ADDR.

Why preclude?
Thx

WIP_COPT_PEER_ADDR doesn’t have NULL or equivalent or at least it’s not documented.

Why have 2 ways of doing the same thing?

WIP_COPT_PEER_ADDR doesn’t work all the time - my code sets WIP_COPT_PEER_ADDR using wip_setOpts on the fly - in this use case using WIP_COPT_PEER_STRADDR works and WIP_COPT_PEER_ADDR doesn’t.

It’s either a WIP bug or documentation bug - for me I’d remove WIP_COPT_PEER_ADDR and change the doc

I’m just trying to save other poor developer an hours debugging - it’s bad (slow) enough debugging my own code using DS with out this kind issue cropping up

In some programming language, developer has to convert the ASCII representation into required data type everytime before calling, like:
c++ - long using inet_addr()
java - InetAddress using getByName()

OpenAT instead allow developer to use directly both u32 and string type for the address…

Same for C# that UdpClient.Connect() can be called by three way.
http://msdn.microsoft.com/en-us/library/system.net.sockets.udpclient.connect(v=vs.85).aspx

  • UdpClient.Connect (IPEndPoint)
  • UdpClient.Connect (IPAddress, Int32)
  • UdpClient.Connect (String, Int32)

Personally, I think it is flexible and convenience than giving trouble…

Hi Iotam

Ok I give up - you keep WIP_COPT_PEER_ADDR in the UDP documentation

Maybe you could test it / find the bug and fix the bug instead

or add a warning in the documentation not use WIP_COPT_PEER_ADDR with UDP -> wip_setOpts as it will fail if you use it in certain instances

Hi Edward,

I just want to discuss and share my understanding…
Apologize if that cause any bad feeling…

Lets wait and see comments from other experts on the forum.

For the bug, maybe you can create another thread and show how you use WIP_COPT_PEER_ADDR and found not working?

Thx

Hi Iotam

I apologise - I took some time out to revisit my testing on WIP_COPT_PEER_ADDR.

This issue was to do with pointers in my application - it was a confusing issue because the code ran most of the time and crashed occasionally.

I’m still not convinced that 2 methods to do the same thing is good practice

The bug was difficult to spot because the Key Value pair / variable argument list implementation used for wip options makes it hard to spot bugs.