locked
UDP communication between Intel and ARM devices RRS feed

  • Question

  • Hi fellow devs,

    I’ve got a problem with UDP communication between two instances of my Windows Store application – one running on my old HP Intel notebook with Windows 8 Enterprise (x64) installed, the other running on my new Asus VivoTab RT with Windows RT installed. The problem is that the app instance running on the Windows RT device never receives UDP packets sent by the notebook app instance (the other way around, it works just fine, i. e. the notebook instance happily receives UDP packets sent by the Windows RT app instance).

    I’ve created a simple test application demonstrating the behavior (the app declares all the capabilities required – privateNetworkClientServer, internetClientServer and

    internetClient). When the test app starts, it creates a long running background task for receiving UDP packets with the following code (logging and error handling omitted – for full source please see the attached Vs2012 Solution):

    using (var receiverSocket = new DatagramSocket())

    {

      receiverSocket.MessageReceived += this.OnMessageReceived;

      receiverSocket.BindServiceNameAsync(this._port).AsTask().Wait();

      receiverSocket.JoinMulticastGroup(new HostName(this._multicastGroupAddress));

      while (true)

      {

        Task.Delay(100).Wait();

      }

    }

    The code creates a new instance of the DatagramSocket class, attaches a MessageReceived event handler, binds to a predefined local port (hardcoded to 50102) and joins a multicast group for either IPv4 (239.255.12.132 – IANA organization-local) or IPv6 (ff02::158 – INA link-local) based on user choice. It then enters an infinite loop waiting for UDP datagrams to come over the network.

    The code for sending datagrams is also very simple:

    using (var socket = new DatagramSocket())

    {

      using(var stream = await socket.GetOutputStreamAsync(new HostName(this._multicastGroupAddress), this._port))

      {

        var random = new Random();

        var bytes = new byte[100 + random.Next(1000)];

        random.NextBytes(bytes);

        uint bytesSent = await stream.WriteAsync(bytes.AsBuffer());

        await stream.FlushAsync();

        await Task.Delay(1000);

      }

    }

    After creating a DatagramSocket instance, we acquire the output stream for the predefined multicast group address and port. Next we create a small, randomly initialized buffer, send it over the network and wait 1 second before closing the stream and the socket.

    Let me restate the problem with this code: UDP packets sent by the Intel device never reach the RT device, although packets sent by the RT device are received by the Intel device. I’ve observed the same behavior on IPv4 as well as IPv6 networks.

    What’s interesting is that the app running on the Intel device doesn’t receive loopback UDP packets until it receives at least one UDP packet sent over the network. From that point on, it receives also the packets sent by itself...

    As you’ve probably guessed already, I’m not a networking expert and I suspect that I’m missing something obvious. Please help.

    Sorry for the long post and thank you for your patience,

    Best regards,

    Palo

    PS: The testing solution contains also a Windows Phone 8 application that (interestingly enough) behaves just like the desktop app – it receives UDP packets sent from the desktop app, but the desktop app never receives packets sent from the phone app…

    Palo Mraz



    • Edited by Palo Mraz Wednesday, January 2, 2013 9:50 PM corrected title - ARM instead of AMD
    Wednesday, January 2, 2013 1:00 PM

Answers

  • Hi Palo,

    The issue you are experiencing is because the Acer Windows RT device you have is using a Broadcom network driver that is incorrectly dealing with these UDP Multicast messages.  We have contacted Broadcom and hope to have a resolution that will be pushed via Windows Update as soon as possible (I have no dates for you unfortunately).

    -Jeff


    Jeff Sanders (MSFT)

    Tuesday, January 22, 2013 9:19 PM
    Moderator

All replies

  • This post seems to be related to this one...

    Palo Mraz

    Wednesday, January 2, 2013 9:52 PM
  • Hi Palo,

    The issue you are experiencing is because the Acer Windows RT device you have is using a Broadcom network driver that is incorrectly dealing with these UDP Multicast messages.  We have contacted Broadcom and hope to have a resolution that will be pushed via Windows Update as soon as possible (I have no dates for you unfortunately).

    -Jeff


    Jeff Sanders (MSFT)

    Tuesday, January 22, 2013 9:19 PM
    Moderator
  • This is also a known issue with the Surface Windows RT device.

    The problem is the same like Jeff has mentioned. Surface uses Marvell drivers and like the other case, this is an issue with the hardware network device driver.

    We have contacted the vendor for Surface device as well and hope to have a resolution that will be pushed via Windows Update as soon as possible (I have no dates to share unfortunately).

     

    Thanks,

    Prashant.

    Wednesday, February 6, 2013 8:49 PM
    Moderator
  • My 2 cents:

    From what I have experienced so far, Connected standby is not well implemented on broadcom driver stack and incoming traffic (not only UDP for me) does not wakeup the network interface.

    The easy tests is to run ping 192.168.X.X -t  command from tablet in background to maintain interface alive. Then all UDP packets should reach your DatagramSocket.MessageReceived.


    Edward



    Wednesday, February 6, 2013 10:30 PM
  • @Edward: The problem is not connected standby - UDP doesn't work in "normal" device operation mode (not locked, screen on, user interacting with the device - don't know the correct term for that:-).

    Regards,

    Palo


    Palo Mraz

    Friday, February 15, 2013 7:49 AM