none
Multicast issue when migrating from win8 to win8.1

    Question

  • hello,

    I have a windows 8 store app that is working fine in VS2012. Now i try to migrate the store app to VS2013 and it seems something changed in using multicast feature.

    The app like a chatting room, it would join a multicast group and keep listening when initializing, and it could send message to this multicast group when running.

           the following is the code snippet.

           join multicast group and listen :

    multicastsocket = new DatagramSocket();
    multicastsocket.MessageReceived += multicastsocket_MessageReceived;
    
    Hostname multicastGroup = new Hostname("230.1.2.3");
    multicastsocket.BindServiceNameAsync("1234");
    mmulticastsocket.joinMulticastGroup(multicastGroup);
    

         send multicast message :

    var socket = new DatagramSocket();
    Hostname multicastGroup = new Hostname("230.1.2.3");
    
    using(var oStream = socket.GetOutputStreamAsync(multicastGroup, "1234"))
    {
        using(var writer = new DataWriter(oStream))
        {
            writer.WriteString("Hello Test");
            await writer.StoreAsync();
        }
    }

    When i try to send message it always get the exception of "No such host is know.(Exception from HRESULT: 0x80072AF9)" after migrating.

    But the send message function will work fine if i comment out the function of "joinMulticatGroup".

    It seems like a new limitation?

    How do i modify to let my app work in VS2013, thanks.

    Monday, September 23, 2013 12:13 PM

Answers

  • Hi All,

    I have had a chance to investigate this issue in detail, understand the root cause and suggest a code workaround for you all.

    Firstly, the issue happens because an unused (either disabled or not currently used) network interface is returned back to the application over which to send the multicast packet and since the interface is not the right interface to send the packet on, you get the error.

    The code workaround that I am suggesting is to first select/retrieve an active network adapter by calling GetInternetConnectionProfile() and then reference the NetworkAdapter parameter of the returned information while calling BindServiceNameAsync.

    The BindServiceNameAsync function overload which has 2 parameters: http://msdn.microsoft.com/en-us/library/windows/apps/dn279145.aspx is only available in Windows 8.1, so you’ll need to retarget your app to Windows 8.1.

    With this workaround, I have been able to successfully send the MDNS packet over the chosen interface and I would like you to test the same and let me know if it works for your or not.

    Here's the code in C# and C++.

    XAML:
    ==========================
    ==========================
    
        <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
            <TextBlock x:Name="txtOutput" HorizontalAlignment="Left" Margin="59,103,0,0" TextWrapping="Wrap" Text="TextBlock" VerticalAlignment="Top" Height="398" Width="932"/>
            <TextBox x:Name="txtIP" HorizontalAlignment="Left" Margin="59,29,0,0" TextWrapping="Wrap" Text="224.0.0.251" VerticalAlignment="Top" Width="170"/>
            <TextBox x:Name="txtPort" HorizontalAlignment="Left" Margin="259,29,0,0" TextWrapping="Wrap" Text="5353" VerticalAlignment="Top"/>
            <Button x:Name="btnWorkaround" Content="Perform MDNS - with Workaround" HorizontalAlignment="Left" Margin="590,29,0,0" VerticalAlignment="Top" Click="btnWorkaround_Click"/>
        </Grid>
    
    C++ code:
    ==========================
    ==========================
    
    void TestMCApp::MainPage::btnWorkaround_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
    {
    	DatagramSocket^ socket = ref new DatagramSocket();
    
    	auto dispatcher = CoreWindow::GetForCurrentThread()->Dispatcher;
    
    	auto ipAddress = txtIP->Text;	// 224.0.0.251
    	auto port = txtPort->Text;		// 5353	
    	
    	///
    	///	retrieve the best network adapter to use
    	///
    	ConnectionProfile^ connectionProfile = NetworkInformation::GetInternetConnectionProfile();
    	
    	dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    		this->txtOutput->Text = "Button Clicked: ";
    	}));
    	
    	///
    	///	call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
    	///
    	task<void>(socket->BindServiceNameAsync("", connectionProfile->NetworkAdapter)).then([this, socket, dispatcher, ipAddress, port](task<void> previousTask)
    	{
    		try
    		{
    			dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    				this->txtOutput->Text = "Bind ServiceName successful: ";
    			}));
    			previousTask.get();
    			socket->JoinMulticastGroup(ref new HostName(ipAddress));
    
    			IAsyncOperation<IOutputStream^> ^op = socket->GetOutputStreamAsync(ref new HostName(ipAddress), port);
    
    			op->Completed = ref new AsyncOperationCompletedHandler<IOutputStream^>
    				([this, dispatcher](IAsyncOperation<IOutputStream^> ^op, Windows::Foundation::AsyncStatus status)
    			{
    				dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    					this->txtOutput->Text = "GetOutputstreamAsync successful: ";
    				}));
    
    				auto ec = op->ErrorCode;
    
    				if (ec.Value == S_OK) {
    					IOutputStream ^ostream = op->GetResults();
    
    					DataWriter	^writer = ref new DataWriter(ostream);
    
    					writer->WriteString(L"Protocol message");
    					writer->StoreAsync();
    
    					dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this, ec]() {
    						this->txtOutput->Text = "The MDNS Query was sent successfully!";
    					}));
    				}
    				else {
    					// Display the error
    					dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this, ec]() {
    						this->txtOutput->Text = "Error code: " + ec.Value;
    					}));
    				}
    			});
    		}
    		catch (Exception^ ex)
    		{
    			std::wstring error = ex->Message->Data();
    			OutputDebugString(error.c_str());
    			this->txtOutput->Text = "Exception: " + ex->Message;
    		}
    	});
    }
    
    
    C# code:
    ==========================
    ==========================
     
           private async void btnWorkaround_Click(object sender, RoutedEventArgs e)
            {
                try
                {
                    DatagramSocket socket = new DatagramSocket();
                    String ipAddress = txtIP.Text;
                    String port = txtPort.Text;
    
                    ///
                    ///	retrieve the best network adapter to use
                    ///
                    ConnectionProfile connectionProfile = NetworkInformation.GetInternetConnectionProfile();
    
                    ///
                    ///	call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
                    ///	Don't specify a local port unless you have some type of dependency on that local port. 
                    ///	If the local port is being used by some other app, you'll get an exception
                    ///
                    await socket.BindServiceNameAsync("", connectionProfile.NetworkAdapter); 
    
                    socket.JoinMulticastGroup(new HostName(ipAddress));
                    IOutputStream outputStream = await socket.GetOutputStreamAsync(new HostName(ipAddress), port);
                    byte[] buffer = Encoding.UTF8.GetBytes("Protocol message");
                    await outputStream.WriteAsync(buffer.AsBuffer());
                    await outputStream.FlushAsync();
                    txtOutput.Text = "The multicast message was sent successfully";
                }
                catch (Exception oEx)
                {
                    txtOutput.Text = "Exception: " + oEx.Message;
                }
            }

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, November 05, 2013 8:09 PM

All replies

  • Do you have a complete sample that reproduces this issue? Where are you running your Multicast client & server? Does your client side network interface support multicasting?

    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Monday, September 23, 2013 9:12 PM
  • I also have an application that uses UdpClient.JoinMulticastGroup that works on Windows 8 (and all previous versions) but not on Windows 8.1 (RTM). I've found a number of differences with networking since I upgraded from Windows 8 to Windows 8.1. I think there must be quite a few changes to the network stack. I have not found a solution yet. Please let me know if you work out what the problem is.

    Andrew

    Tuesday, October 08, 2013 6:50 PM
  • @AndrewJones123543, did you get your app working? Can you provide more details regarding what it does, what machine type does it fail on etc, provide some sample code or any error codes that you are receiving?  Are you receiving the same 0x80072AF9 error as well when using Multicast?

    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz


    Thursday, October 10, 2013 1:08 AM
  • My code works fine on Windows 7, Windows 8 but not on Windows 8.1. Let me explain the problem...The Windows 8.1 machine is ok sending data using UDP Multicast but it does not receive anything sent to the Multicast address. I've tried disabling the firewall but that does not help. If I send to the specific IP address of the Windows 8.1 machine the message is received ok. It's almost as though the Windows 8.1 machine is not joining the Multicast group successfully. I wonder if I can get any debug information from my router to see what multicast groups are active.

    Andrew

    Thursday, October 10, 2013 11:51 AM
  • Hi Andrew,

    When you say: "The Windows 8.1 machine is ok sending data using UDP Multicast but it does not receive anything sent to the Multicast address", do you mean that the following code logic works for you?

    1. Create a DatagramSocket
    2. Call DatagramSocket.JoinMulticastGroup
    3. Call DatagramSocket.GetOutputStreamAsync
    4. If successful, send data over the stream

    If so, then I believe your problem is different from the one reported above, since in the above case, Step 3 fails with 0x80072AF9.

    The problem reported above by the original poster is very much similar to another thread that I am working with another customer: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/461445a8-a5ba-4cab-9762-22e8232e0bbf/problem-with-udp-broadcast-on-arm?forum=winappswithnativecode

    Can you tell me the code logic you are using that is apparently failing on Windows 8.1?

    Thanks,
    Prashant


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Friday, October 11, 2013 7:02 PM
  • I'm having the exact same problem starting with Windows 8.1. Same code was working fine under Windows 8.

    GetOutputStreamAsync fails with 0x80072AF9 on a socket after JoinMulticastGroup.

    The multicast group is joined and I can receive messages from the group, send messages directly to peers, but attempting to send to the multicast group address (broadcast to the group), it fails with 'No such host is known'.

    This is obviously a big problem, because in order to do discovery, you need to be able to broadcast to the group.

    Monday, October 21, 2013 3:58 PM
  • Update: I was able to overcome this issue by having a second socket used specifically to broadcast. Basically, I created a separate UDP socket that does NOT join the multicast group, but sends to the multicast address, and that works fine.

    Monday, October 21, 2013 4:42 PM
  • Hi ECorvi,

    Thanks for reporting the issue. Right now, the issue is still under investigation from Windows 8.1 standpoint.

    To understand and make your workaround clear and helpful to others, are you using this logic for doing the send and receive?

    - Create SocketA

    - Call SocketA.JoinMulticastGroup.

    - Use this socket to receive information

    - Create SocketB.

    - Do not call SocketB.JoinMulticastGroup.

    - Use SocketB to send packets to the Multicast address.

    - SocketA will now receive the data that was sent through SocketB.

    Does this sound right?

    Thanks,

    Prashant.


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Monday, October 21, 2013 5:19 PM
  • That is correct.

    I also ran Wireshark on a separate machine on the network and verified that the buffer sent through the broadcasting socket (SocketB) does appear on the network with source IP = <sending machine IP> and destination IP = <multicast address, multicast port>

    Notice that this workaround might not work for people trying to reply directly to a peer address/port (the address is obviously correct, but the port will likely be random, and not correct). It works in my case because all replies are sent to the multicast address/port, so every member of the multicast group will get the response.

    A real fix will have to come from Microsoft addressing why the socket cannot send to the multicast address after joining the group, something that was working fine in Windows 8. I also noticed that when running Windows 8.1 under VMWare, the 0x80072AF9 exception does not happen and everything works ok. So perhaps this is related to certain network drivers? The machine exhibiting the problem is a Samsung Series 7 slate, but we also had customers with other configurations reporting the same problem.

    FWIW, I'm using the mDNS/Zeroconf multicast address. IPv4: 224.0.0.251, IPv6: ff02::fb and port 5353.

    Monday, October 21, 2013 6:58 PM
  • Thanks for the clarification ECorvi.

    When you mentioned that the problem happens with Samsung Series 7 slate, can you tell me the model number? Is it a 700T that was provided during the Build conference?http://www.samsung.com/global/windowspreview/data/1_Using_the_Samsung_Series_7_Slate_Windows_8_Consumer_Preview.pdf ?


    Windows Store Developer Solutions #WSDevSol || Want more solutions? See our blog, http://aka.ms/t4vuvz

    Monday, October 21, 2013 10:13 PM
  • It's a Samsung 700T1A-A04

    Tuesday, October 22, 2013 9:21 PM
  • OK, is this Samsung 700T1A-A04 running Windows 8.1 RTM/GA? Can you repro the problem with a clean install of Windows 8.1?

    On a similar note, does this same problem happen on another type of machine or is this just Samsung specific?

    I have tried creating a simple app that:

    - Create SocketA (new DatagramSocket)

    - Call SocketA.BindServiceNameAsync(localPort)

    - Call SocketA.JoinMulticastGroup(224.0.0.251)

    - Call SocketA.GetOutputStreamAsync(224.0.0.251, 5353)

    - Check the error code and write to the stream if there is no error.

    The app runs fine on my Surface RT with Windows RT 8.1.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, October 22, 2013 10:18 PM
  • I'm getting the problem on a Toshiba laptop (Network card is a Realtek PCIe GBE Family Controller) that I upgraded from 8 to 8.1 RTM.
    Wednesday, October 23, 2013 8:03 AM
  • I have the same issue. Actually what is described here as the workaround (with two sockets) is the standard situation in my app, and I still get the No Such Host exception when sending to the multicast address. But.. after some random time (in the order of minutes) the exceptions disappear and everything starts working.

    This issue occurs on my development laptop HP Pavillion g7 but not on my Samsung Tablet, both with Windows 8.1.  I believe the difference may be linked to my development laptop running with Hyper-V installed (because of running the WP8 simulator), while the Samsung Tablet does not have Hyper-V activated.


    Edit: this issue was not present in the Windows 8.1 Preview
    Thursday, October 24, 2013 10:37 AM
  • OK, is this Samsung 700T1A-A04 running Windows 8.1 RTM/GA? Can you repro the problem with a clean install of Windows 8.1?

    On a similar note, does this same problem happen on another type of machine or is this just Samsung specific?

    I have tried creating a simple app that:

    - Create SocketA (new DatagramSocket)

    - Call SocketA.BindServiceNameAsync(localPort)

    - Call SocketA.JoinMulticastGroup(224.0.0.251)

    - Call SocketA.GetOutputStreamAsync(224.0.0.251, 5353)

    - Check the error code and write to the stream if there is no error.

    The app runs fine on my Surface RT with Windows RT 8.1.



    The Samsung is running Windows 8.1 as downloaded from the App Store (final release?)

    This is basically my code setup:

    class BonjourManager
    {
    	private DatagramSocket socket = null;
    	private Windows.Networking.HostName ipv4Group = new Windows.Networking.HostName("224.0.0.251");
    	private Windows.Networking.HostName ipv6Group = new Windows.Networking.HostName("ff02::fb");
    
    	private async Task createUDPSocketAsync()
    	{
    		try
    		{
    			socket = new DatagramSocket();
    			socket.MessageReceived += socket_MessageReceived;
    
    			await socket.BindEndpointAsync(null, "5353");
    
    			socket.JoinMulticastGroup(ipv4Group);
    			socket.JoinMulticastGroup(ipv6Group);
    		}
    		catch(Exception)
    		{
    			socket = null;
    		}
    	}
    
    	private async void sendBuffer(byte[] buffer)
    	{
    		try
    		{
    			using (var output = await socket.GetOutputStreamAsync(ipv4Group, "5353"))
    			{
    				using (var writer = new DataWriter(output))
    				{
    					writer.WriteBytes(buffer);
    					await writer.StoreAsync();
    					await writer.FlushAsync();
    					writer.DetachStream();					}
    				}
    			}
    		catch
    		{
    		}
    	}
    }


    I even tried to dispatch the sendbuffer on the main thread to see if this was some sort of threading issue, but it didn't make a difference.

    Obviously this broke our app, and a couple of customers reported encountering the issue, so this is definitely happening in other boxes too.

    • Edited by ECorvi Thursday, October 24, 2013 4:21 PM
    Thursday, October 24, 2013 4:18 PM
  • Hello,

    Unfortunately there is no "fix" to this issue yet and we are still investigating the root cause.

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, October 29, 2013 1:34 AM
  • I'm seeing the same error, identical, here's a thread I started yesterday: (with code you can copy to repro it)

    http://social.msdn.microsoft.com/Forums/windowsapps/en-US/52b103be-cde8-41f8-9774-a3e4514db45f/no-such-host-is-known-when-using-a-datagramsocket-on-win-81?forum=winappswithcsharp#331038ee-6dbb-4cae-af68-483148a7ec41

    I'm building a UPnP controller API, and this was working very well on Windows 8.0, since the "upgrade" to 8.1 it is unusable.

    I'm using the API to create a Sonos controller App for Surface but testing on a physical device has now been halted which is a major holdup for me.

    Microsoft want us to write Apps for their store, well I did but now it's screwed.

    Frankly I'm growing very tired of the comedy of errors that Microsoft are becoming, its beginning to waste my time.

    Having said all this, please note: The code runs without errors on my desktop PC. I can run my app under debug in VS 2013 using the 'simulator' debugging option and I never see this exception.

    That PC is wired. If I debug the same App but use 'Remote Machine' to a Surface Pro I get this exception, the Surface uses WiFi.

    Therefore it could be that this multicast bug is confined to WiFi and does not occur on wired networks...

    Each machine is running Windows 8.1 and I'm developing/debugging with VS 2013.

    Neither machine has ever had any prior builds of 8.1 or VS 2013 installed.

    Cap'n





    Wednesday, October 30, 2013 5:28 AM
  • Hello,

    Unfortunately there is no "fix" to this issue yet and we are still investigating the root cause.

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Hi Prashant;

    May I ask, is there a need for one of us to formally report this as a bug or have you done that already?

    Cap'n

    Wednesday, October 30, 2013 4:36 PM
  • Hello Captain,

    I have already opened a bug for this issue, but there's no ETA yet. If anyone else in the community is running into this issue, please report it here. We have already have multiple customer reports on this issue and I would encourage anyone else running into this issue to report it here.

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Wednesday, October 30, 2013 5:06 PM
  • Update: My proposed dual socket workaround brakes when using wi-fi (uffff), so that's not a solution either.

    I reverted to my Win 8 code (single socket), and we're basically awaiting a fix from Microsoft on this issue. I can confirm this issue happens much more often when using Wi-Fi, and it's a big problem for our customers using Surface and Surface 2 tablets.

    Wednesday, October 30, 2013 6:23 PM
  • Update: My proposed dual socket workaround brakes when using wi-fi (uffff), so that's not a solution either.

    I reverted to my Win 8 code (single socket), and we're basically awaiting a fix from Microsoft on this issue. I can confirm this issue happens much more often when using Wi-Fi, and it's a big problem for our customers using Surface and Surface 2 tablets.

    I get this consistently on a physical Surface tablet using WiFi but I never get it on my desktop which is on a wired LAN here on my network.

    I have suspected (and your post reinforces this) that the bug is either confined to WiFi scenarios or much more prevalent in a WiFi setting.

    What's worse is that I cannot see a workaround, the DatagramSocket offers just a few operations and for sending data we only have this one method (which fails in the presence of this bug).

    I wonder if it's possible to use a basic Socket here to send datagrams to a multicast address?

    Cap'n


    Thursday, October 31, 2013 3:36 PM
  • This consistently fails as a Store App on a WiFi connected Surface Pro running Windows 8.1:

    using System;
    using System.Runtime.InteropServices.WindowsRuntime;
    using System.Text;
    using Windows.Networking;
    using Windows.Networking.Sockets;
    using Windows.Storage.Streams;
    using Windows.UI.Xaml;
    using Windows.UI.Xaml.Controls;
    
    // The Blank Page item template is documented at http://go.microsoft.com/fwlink/?LinkId=234238
    
    namespace DatagramSocketBug
    {
        /// <summary>
        /// An empty page that can be used on its own or navigated to within a Frame.
        /// </summary>
        public sealed partial class MainPage : Page
        {
            public MainPage()
            {
                this.InitializeComponent();
    
            }
    
            async private void Button_Click(object sender, RoutedEventArgs e)
            {
                HostName host = new HostName("239.255.255.250");
                DatagramSocket send_socket = new DatagramSocket();
                DatagramSocket recv_socket = new DatagramSocket();
                await send_socket.BindEndpointAsync(null, String.Empty);
                await recv_socket.BindEndpointAsync(null, "1900");
                recv_socket.JoinMulticastGroup(host);
                IOutputStream op = await send_socket.GetOutputStreamAsync(host, "1900");
                Byte[] buffer = Encoding.UTF8.GetBytes("Msearch");
    
                await op.WriteAsync(buffer.AsBuffer());
                await op.FlushAsync();
    
            }
        }
    }


    This captures all of the essentials of my actual application.

    Note: When run on my wired LAN Windows 8.1 desktop using VS 2013 and debugging as "Simulator" this works. When run on the Surface by debugging on the desktop using the debug option "Remote Machine" it fails.

    Comment out the code referring to recv_socket and it works, clearly the bind or join on one socket seriously impacts the ability to do a multicast send on a completely different socket from a machine connected to a WiFi network.

    Cap'n

    PS: In fact if you simply comment out the "join" statement the exception goes away, its the join that's leading to the problem it seems.



    Tuesday, November 05, 2013 4:24 PM
  • Hi All,

    I have had a chance to investigate this issue in detail, understand the root cause and suggest a code workaround for you all.

    Firstly, the issue happens because an unused (either disabled or not currently used) network interface is returned back to the application over which to send the multicast packet and since the interface is not the right interface to send the packet on, you get the error.

    The code workaround that I am suggesting is to first select/retrieve an active network adapter by calling GetInternetConnectionProfile() and then reference the NetworkAdapter parameter of the returned information while calling BindServiceNameAsync.

    The BindServiceNameAsync function overload which has 2 parameters: http://msdn.microsoft.com/en-us/library/windows/apps/dn279145.aspx is only available in Windows 8.1, so you’ll need to retarget your app to Windows 8.1.

    With this workaround, I have been able to successfully send the MDNS packet over the chosen interface and I would like you to test the same and let me know if it works for your or not.

    Here's the code in C# and C++.

    XAML:
    ==========================
    ==========================
    
        <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
            <TextBlock x:Name="txtOutput" HorizontalAlignment="Left" Margin="59,103,0,0" TextWrapping="Wrap" Text="TextBlock" VerticalAlignment="Top" Height="398" Width="932"/>
            <TextBox x:Name="txtIP" HorizontalAlignment="Left" Margin="59,29,0,0" TextWrapping="Wrap" Text="224.0.0.251" VerticalAlignment="Top" Width="170"/>
            <TextBox x:Name="txtPort" HorizontalAlignment="Left" Margin="259,29,0,0" TextWrapping="Wrap" Text="5353" VerticalAlignment="Top"/>
            <Button x:Name="btnWorkaround" Content="Perform MDNS - with Workaround" HorizontalAlignment="Left" Margin="590,29,0,0" VerticalAlignment="Top" Click="btnWorkaround_Click"/>
        </Grid>
    
    C++ code:
    ==========================
    ==========================
    
    void TestMCApp::MainPage::btnWorkaround_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
    {
    	DatagramSocket^ socket = ref new DatagramSocket();
    
    	auto dispatcher = CoreWindow::GetForCurrentThread()->Dispatcher;
    
    	auto ipAddress = txtIP->Text;	// 224.0.0.251
    	auto port = txtPort->Text;		// 5353	
    	
    	///
    	///	retrieve the best network adapter to use
    	///
    	ConnectionProfile^ connectionProfile = NetworkInformation::GetInternetConnectionProfile();
    	
    	dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    		this->txtOutput->Text = "Button Clicked: ";
    	}));
    	
    	///
    	///	call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
    	///
    	task<void>(socket->BindServiceNameAsync("", connectionProfile->NetworkAdapter)).then([this, socket, dispatcher, ipAddress, port](task<void> previousTask)
    	{
    		try
    		{
    			dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    				this->txtOutput->Text = "Bind ServiceName successful: ";
    			}));
    			previousTask.get();
    			socket->JoinMulticastGroup(ref new HostName(ipAddress));
    
    			IAsyncOperation<IOutputStream^> ^op = socket->GetOutputStreamAsync(ref new HostName(ipAddress), port);
    
    			op->Completed = ref new AsyncOperationCompletedHandler<IOutputStream^>
    				([this, dispatcher](IAsyncOperation<IOutputStream^> ^op, Windows::Foundation::AsyncStatus status)
    			{
    				dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this]() {
    					this->txtOutput->Text = "GetOutputstreamAsync successful: ";
    				}));
    
    				auto ec = op->ErrorCode;
    
    				if (ec.Value == S_OK) {
    					IOutputStream ^ostream = op->GetResults();
    
    					DataWriter	^writer = ref new DataWriter(ostream);
    
    					writer->WriteString(L"Protocol message");
    					writer->StoreAsync();
    
    					dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this, ec]() {
    						this->txtOutput->Text = "The MDNS Query was sent successfully!";
    					}));
    				}
    				else {
    					// Display the error
    					dispatcher->RunAsync(CoreDispatcherPriority::Normal, ref new DispatchedHandler([this, ec]() {
    						this->txtOutput->Text = "Error code: " + ec.Value;
    					}));
    				}
    			});
    		}
    		catch (Exception^ ex)
    		{
    			std::wstring error = ex->Message->Data();
    			OutputDebugString(error.c_str());
    			this->txtOutput->Text = "Exception: " + ex->Message;
    		}
    	});
    }
    
    
    C# code:
    ==========================
    ==========================
     
           private async void btnWorkaround_Click(object sender, RoutedEventArgs e)
            {
                try
                {
                    DatagramSocket socket = new DatagramSocket();
                    String ipAddress = txtIP.Text;
                    String port = txtPort.Text;
    
                    ///
                    ///	retrieve the best network adapter to use
                    ///
                    ConnectionProfile connectionProfile = NetworkInformation.GetInternetConnectionProfile();
    
                    ///
                    ///	call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
                    ///	Don't specify a local port unless you have some type of dependency on that local port. 
                    ///	If the local port is being used by some other app, you'll get an exception
                    ///
                    await socket.BindServiceNameAsync("", connectionProfile.NetworkAdapter); 
    
                    socket.JoinMulticastGroup(new HostName(ipAddress));
                    IOutputStream outputStream = await socket.GetOutputStreamAsync(new HostName(ipAddress), port);
                    byte[] buffer = Encoding.UTF8.GetBytes("Protocol message");
                    await outputStream.WriteAsync(buffer.AsBuffer());
                    await outputStream.FlushAsync();
                    txtOutput.Text = "The multicast message was sent successfully";
                }
                catch (Exception oEx)
                {
                    txtOutput.Text = "Exception: " + oEx.Message;
                }
            }

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Tuesday, November 05, 2013 8:09 PM
  • Very helpful, I'll implement your suggestion tomorrow and report back. May I ask, is it clear to you why we all only get this error on Windows 8.1? none of us having any problem before that release.

    Thanks.

    Cap'n

    Wednesday, November 06, 2013 1:59 AM
  • Hi Captain,

    There was a change in multicast route selection logic during GA, where it’s possible that some customers will be broken post-GA that weren’t broken at RTM. These newly broken machines have a loopback adapter that is the lowest by LUID (locally unique identifier) joined to the group, and the next highest joined interface on the machine does not have a valid source address.

    It is quite possible to hit this issue on Windows 8 as well, but it depends on how each machine has its interface LUIDs assigned, which is somewhat unpredictable.

    This scenario is more common on mobile devices than workstations due to the higher chance of having disconnected network interfaces.

    Thanks,

    Prashant


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Wednesday, November 06, 2013 2:10 AM
  • public async void SendFromHostName (HostName hostname)
    {
          try
                {
                    DatagramSocket socket = new DatagramSocket();
                    String ipAddress = txtIP.Text;
                    String port = txtPort.Text;
    
                    ///
                    ///	retrieve the network adapter to use
                    ///
                    NetworkAdapter adapter = hostname.IPInformation.NetworkAdapter;
    
                    ///
                    ///	call BindServiceNameAsync overload with 2 parameters. This overload is ONLY available on Windows 8.1
                    ///	Don't specify a local port unless you have some type of dependency on that local port. 
                    ///	If the local port is being used by some other app, you'll get an exception
                    ///
                    await socket.BindServiceNameAsync("", adapter); 
    
                    socket.JoinMulticastGroup(new HostName(ipAddress));
                    IOutputStream outputStream = await socket.GetOutputStreamAsync(new HostName(ipAddress), port);
                    byte[] buffer = Encoding.UTF8.GetBytes("Protocol message");
                    await outputStream.WriteAsync(buffer.AsBuffer());
                    await outputStream.FlushAsync();
                    txtOutput.Text = "The multicast message was sent successfully";
                }
                catch (Exception oEx)
                {
                    txtOutput.Text = "Exception: " + oEx.Message;
                }
    }

    The workaround as proposed by Prashant works for me. Key is to use the NetworkAdapter that belongs to the connected network on which you wish to send. If you know the local HostName of your computer from which you want to send, you can use the above modification of Prashant's code.

    Wednesday, November 06, 2013 11:54 AM
  • The workaround appears to work for me too but some clarifications may be needed here.

    Firstly its my understanding that JoinMulticastGroup is only relevant when one wants to receive multicasts sent to the multicast address by other nodes on the network.

    Calling this has no bearing on the sending (multicasting) of data to other listening nodes - you could I believe remove that line in the test code above and see that messages can still be sent (I left it in because it is the step that leads to the failure later when we tried to send).

    Although its the send operation that was failing before, this was due to the issue addressed by Prashant, the issue associated with joining the group on another socket in order to receive multicasts.

    So in my case I do need to pass "1900" into BindServiceNameAsync in addition to joining the multicast group in order to receive multicasts from other nodes - when I do this everything now works fine it seems.

    Finally that overload of BindServiceNameAsync is not specific to Windows 8.1 as such but to the Windows Store classes on Windows 8.1. A desktop Windows 8.1 app using .Net 4.51 does not see this overload so cannot use it.

    So for Phone 8 and Desktop with .Net 4.51 on Windows 8.1 I'm using the original code (I need to test desktop usage rather than Store to make sure that isn't also seeing this bug and so might be in need of a different workaround).

    Overall this is progress - thanks Prashant.

    Cap'n


    Wednesday, November 06, 2013 8:38 PM
  • @Captain:

    Regarding this comment: "Finally that overload of BindServiceNameAsync is not specific to Windows 8.1 as such but to the Windows Store classes on Windows 8.1. A desktop Windows 8.1 app using .Net 4.51 does not see this overload so cannot use it."

    That's not completely true...If have been using the following link that talks about how to use Windows Runtime from desktop apps: http://msdn.microsoft.com/en-us/library/windows/apps/jj856306.aspx, it sure does mention about adding the <TargetPlatformVersion> property and set it to 8.0. However, since the function overload is only available in Windows 8.1, you will need to set the <TargetPlatformVersion> to 8.1. That way you should see both the overloads.

    For Windows Phone 8, you only have one function. There's no 2 parameter version of BindServiceNameAsync. The Phone kernel is different than Windows, so you may not even run into this same issue with the phone. If you do, please open up a new thread on the Windows Phone forum (dev.windowsphone.com/community).

    Thanks,

    Prashant


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Wednesday, November 06, 2013 11:16 PM
  • @Captain:

    Regarding this comment: "Finally that overload of BindServiceNameAsync is not specific to Windows 8.1 as such but to the Windows Store classes on Windows 8.1. A desktop Windows 8.1 app using .Net 4.51 does not see this overload so cannot use it."

    That's not completely true...If have been using the following link that talks about how to use Windows Runtime from desktop apps: http://msdn.microsoft.com/en-us/library/windows/apps/jj856306.aspx, it sure does mention about adding the <TargetPlatformVersion> property and set it to 8.0. However, since the function overload is only available in Windows 8.1, you will need to set the <TargetPlatformVersion> to 8.1. That way you should see both the overloads.

    For Windows Phone 8, you only have one function. There's no 2 parameter version of BindServiceNameAsync. The Phone kernel is different than Windows, so you may not even run into this same issue with the phone. If you do, please open up a new thread on the Windows Phone forum (dev.windowsphone.com/community).

    Thanks,

    Prashant


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Thanks Prashant, I did look at this beforehand but the code is a class library and doesn't offer that option, all I was able to select was the framework version (4.51).

    I'll double check tomorrow and report back.

    Again thanks for your professionalism and assistance with all this.

    Cap'n

    PS: That URL is bogus...
    Thursday, November 07, 2013 12:46 AM
  • Just checked Prashant, for a conventional Class Library .Net project in VS 2013 there is no option for selecting a target platform (like 8.1) all I can choose is the .Net Framework version - I've already selected 4.51 for that.

    Am I doing something wrong?

    Cap'n

    Thursday, November 07, 2013 12:55 AM
  • Hi Cap'n,

    The Windows.Networking.Sockets namespace is part of the Windows Runtime, not .NET framework. Your traditional desktop project will specifically need to add support for using the Windows Runtime.

    When you create a traditional desktop class library project in Visual Studio 2013 using File -> New Project -> Templates -> Visual C# -> Windows -> Class Library, you do not see the option to use the Windows Runtime by default. You will explicitly need to add support for the Windows Runtime by adding the following lines in your .csproj file:

      <PropertyGroup> 
        <TargetPlatformVersion>8.1</TargetPlatformVersion>
      </PropertyGroup>

    Open your .csproj file in notepad, and add the above 3 lines anywhere under the <Project> node.

    Once you do that, go back to your Visual Studio project (you will get a prompt asking for reload, so go ahead and reload) and then under the References node, "Add Reference" and in the Add reference window you will notice a node called "Windows". If you select that, you should be able to add the Windows reference (notice that when you choose the Windows node, the window says "Targeting: Windows 8.1"). When you add the reference, you should be able to use the BindServiceNameAsync(localServiceName, adapter) overload.

    Thanks,

    Prashant.


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Thursday, November 07, 2013 1:21 AM
  • Thank you Prashant, I'll explore this tomorrow and it does raise a few questions so I need to understand it some more, for example doing this would tie the class library to Windows 8.1 (i.e. it couldn't run on Windows 7 for example).

    Does tying code to Windows 8.1 or "Windows Runtime" effectively make it "Store" code? If not then whats the difference between a Windows Store class library targeting Win 8.1 and a conventional class library whose project file is modified as you describe above?

    This is off topic though, but thanks for helping out.

    Cap'n

    Thursday, November 07, 2013 3:27 AM
  • Thanks Prashant for the workaround. I have not updated my code to target the 8.1 API yet.

    Couldn't we instead just use:

    DatagramSocket.BindEndpointAsync(HostName hostname, string localServiceName)

    passing the hostname for the current active interface? Wouldn't that accomplish the same thing and be compatible also with Windows 8?


    Friday, November 08, 2013 10:24 PM
  • No, using BindEndpointAsync(hostname, localServiceName) won't work. We already investigated using this and it does not work that way.

    The only workaround is the one I specified above. Are you experiencing the problem on Windows 8?


    Windows Store Developer Solutions, follow us on Twitter: @WSDevSol|| Want more solutions? See our blog

    Friday, November 08, 2013 10:53 PM
  • Thanks Prashant. I can confirm it doesn't work with DatagramSocket.BindEndpointAsync.

    No problem in Windows 8, I just haven't updated our project to VS2013 yet, and was hoping there was a solution that didn't involve migrating.

    I'll probably spend next week branching and moving the code over.

    Thanks again.

    Friday, November 08, 2013 11:07 PM
  • I've updated my code to Win 8.1, and there's still an issue lurking there somewhere...

    It now properly sends out the multicast packets, wether in wifi or wired, but under wifi only, I cannot receive multicast packets from the group. I do receive the packets I send locally, but it's like I don't see the rest of the network. I have another two machines on the wired side talking to each other, but I cannot see their packets from the wifi device. The other machines do see the multicast packets from the wifi machine.

    I verified:

    - The wifi interface has internet access and it's on the same subnet as the wired machines

    - The wifi network is configured as "Private"

    - The socket binds successfully to the wifi interface

    - The socket is marked to don't fragment

    The wifi machine is the same Samsung mentioned above.

    Plugging in the ethernet makes everything work properly. This was all working fine under Windows 8 :\

    Anybody experiencing the same problem?

    Friday, November 15, 2013 6:24 PM
  • Well, while I was writing the post above and looking for related posts, all of a sudden (after about 10 mins since switching from wired to wifi), the wifi interface started to receive multicast packets from the network.

    This is crazy. I can't tell my customers to wait 10 mins to do a simple device discovery. I've also seemingly no way to tell what's happening.

    Any advice on this would be welcome.

    Friday, November 15, 2013 6:51 PM
  • hi,

    that solves my problem

    thanks


    Cordialement / Best Regards Eric

    Sunday, November 24, 2013 9:04 PM
  • The Workaround works like a charm on my Desktop Windows 8.1.

    I've a similar problem on my Surface 2. I can send out multicast packets to a group which were received from several non ARM devices. The Surface 2 receives the Messages only sometimes but I can't figure out why the device doesn't always receives the packets??

    Monday, November 25, 2013 7:28 AM
  • The Workaround works like a charm on my Desktop Windows 8.1.

    I've a similar problem on my Surface 2. I can send out multicast packets to a group which were received from several non ARM devices. The Surface 2 receives the Messages only sometimes but I can't figure out why the device doesn't always receives the packets??

    Hi,

    I got a similar problem on my Surface too. I want to send a mDns Query packet to multicast group to get list of devices and I don't want to limit the packet in only one adapter. Hance, that workaround solution might not fit my situation if I didn't misunderstand. Also, the answer proposed by Prashant didn't explain why this situation only happens on Win8.1 RT tablet but not on Win8.1 on my NB or PC or on Win8 RT. Does anyone has the same problem as me?



    Friday, January 24, 2014 3:48 AM
  • Hello,

    I had the exact same issue which I solved by disabling (temporarily) network interfaces that's not needed by the app.

    If that can help other...

    My setup :

    - windows 8.1 with VS 2012 so I cannot use the propose workaround (overload of BindServiceNameAsync)

    - My code looks exact like the one explained here http://blogs.msdn.com/b/wsdevsol/archive/2013/12/19/datagramsocket-multicast-functionality-on-windows-8-1-throws-an-error-0x80072af9-wsahost-not-found.aspx

    I disabled the interfaces the following interfaces:

    Thursday, March 27, 2014 9:50 PM