Thursday, September 01, 2011 10:11 AMHi,
since I installed the IPv6 stack on Windows XP machines (both 32 and 64 bit versions) I face the problem that the IWMWriterNetworkSink interface on these machines only binds to the IPv6, but not to the IPv4 interface any more. Therefore applications relying on IPv4 stop working. Is there a way to get around this behavior?
On Windows Vista and 7 IWMWriterNetworkSink binds to both IPv4 and IPv6, so there is no problem.
Sunday, April 29, 2012 7:17 PM
in the mean time I had the same problem on a Windows 7 machine, so I had to analyse the situation in more detail.
The problem occurs on an IPv6 enabled machine when port 80 is in use. When port 80 is available, IWMWriterNetworkSink::Open(&dwPortNum) with dwPortNum set to 0 binds to port 80 an everything works as expected. When port 80 is in use, however, IWMWriterNetworkSink::Open selects another port and returns it as dwPortNum. The problem is, that in this case the network sink binds to different ports for IPv4 and IPv6. The returned dwPortNum is correct for IPv6, for IPv4 the port number is (dwPortNum - 1) - as far as I observed in my test environment.
Therefore a simple workaround is to decrement the port number and retry to connect, when the first attempt has failed. This works for all my test cases. Of course I do not want to use this for production code as long as I do not know exactly what is going on.
Is there any documentation on this behavior? How should I handle this situation?