Hi Huw,
It seems odd to store these as strings and then resolve them. Couldn't they just be stored direclty as addresses?
Yes, I guess we could populate a sockaddr_in's in_addr.S_addr with htonl(0xEFFFFFFA), and a sockaddr_in6's s6_addr with { 0xFF, 0x02, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0x0C };
We will need the resolve_address function in a later patch however (not submitted with this patchset) for listening for incoming messages. Basically the same code as:
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/wsdapi/tests/discover...
I can take it out of this patch and add it into the later patch if you think that's better though.
Are these things really supposed to go off semi-randomly?
Yes - the SOAP over UDP specification supplies an algorithm to be used, including random delays to try to avoid collisions:
http://specs.xmlsoap.org/ws/2004/09/soap-over-udp/soap-over-udp.pdf (section 4.4, plus Appendix I)
and the WS-Discovery specification provides for a message-specific randomised initial delay:
http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf (section 2.4)
Thanks for your other comments, I appreciate your time spent reviewing this.
Cheers,
Owen