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