none
Network Communications in the Background

    Question

  • hello

    reference Network communications in the background

    the following code works without issues

    _tcpListener = new StreamSocketListener();
    _tcpListener.EnableTransferOwnership(_task.TaskId, SocketActivityConnectedStandbyAction.Wake);
    _tcpListener.ConnectionReceived += _tcpListener_ConnectionReceived;
    await _tcpListener.BindEndpointAsync(new HostName("172.16.0.105"), "80");

    but as soon as i try to use the StreamSocketListener in combination with a Background Task with this code

    var builder = new BackgroundTaskBuilder();
    
    builder.Name = TaskNameSocketActivity;
    builder.TaskEntryPoint = "BackgroundTasks.SocketActivity";
    builder.SetTrigger(new SocketActivityTrigger());
    BackgroundTaskRegistration _task = builder.Register();
    
    _tcpListener = new StreamSocketListener();
    _tcpListener.EnableTransferOwnership(_task.TaskId, SocketActivityConnectedStandbyAction.Wake);
    _tcpListener.ConnectionReceived += _tcpListener_ConnectionReceived;
    //await _tcpListener.BindServiceNameAsync("80");
    await _tcpListener.BindEndpointAsync(new HostName("172.16.0.105"), "80");

    so the only change is the EnableTransferOwnership

    await _tcpListener.BindServiceNameAsync("80");

    raise

    An exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.ni.dll but was not handled in user code
    WinRT information: A wildcard address cannot be used with a specific port when the Wake standby action is set. Try using BindEndpointAsync with a non-null localHostName.

    even if this should work based on the documentation

    and if i do what he want

    await _tcpListener.BindEndpointAsync(new HostName("172.16.0.105"), "80");

    raise

    An exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.ni.dll but was not handled in user code
    WinRT information: The attempted operation is not supported for the type of object referenced.

    the ip is the right one, i could also use the real hostname or fqdn the exception is always the same

    i use it on Windows 10 Pro Insider Preview, Build 14986.rs_prerelease.161202-1928 and target Windows 10 Anniversary Edition

    i appreciate any help

    thank you

    Andre


    Thursday, January 05, 2017 10:50 PM

Answers

All replies

  • Hello Andre,

    Please try set the code to DonotWake since we have worked by setting it before:

    SocketActivityConnectedStandbyAction.DoNotWake

    Then try the

    await _tcpListener.BindServiceNameAsync("80");

    I haven't tested for this yet but if you still cannot works please let me know

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.




    Friday, January 06, 2017 7:39 AM
    Moderator
  • DoNotWake means "The app should not receive packets when the system goes to stand by" but I need packets always even if the app is in stand by ?
    Friday, January 06, 2017 12:46 PM
  • your solution does not work as i only receive connections after the app resumed and miss every connection in suspended state

    Friday, January 06, 2017 4:38 PM
  • Hello cyberh0me,

    Sorry a little late. So the behavior is that Donotwake just receives info when your application is running, sounds like the right behavior for the "Donotwake". I think we still need to go to the original question. When write the code together it will raise the error. And here are some possible key points that I can find:

    1. Here you are trying to use the server to write a backgroundtask. Is it required that you should do this in your server side? (And sorry if I want to clarify some more details. Does "the following code works without issues" means you will not register backgroundtask in your code? Or just put the register code to some other place?)

    2. Your OS build is 14986 and I think this is not the problem. When we reproduce this issue we are on some old builds. So I believe this is not related to OS build

    3. The official sample code is using Client to register the backgroundtask. Have you ever checked it?

    http://go.microsoft.com/fwlink/p/?LinkId=620606

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, January 13, 2017 10:49 AM
    Moderator
  • hello

    why have you recommended if you know its the wrong setting?

    1. "is it required that you should do this on the server side" i develop a server so yes it is required to do this on the server side because a client must be able to connect even if the app is not in foreground

    "following code works without issues" i think its pretty easy to understand

    await _tcpListener.BindEndpointAsync(new HostName("172.16.0.105"), "80"); raise an exception but only in combination with _tcpListener.EnableTransferOwnership(_task.TaskId, SocketActivityConnectedStandbyAction.Wake);

    2. ok

    3. i am aware of the sample as its the same as described in my reference "Network communications in the background" BUT i develop a server NOT a client

    br
    Andre


    Friday, January 13, 2017 1:36 PM
  • Wednesday, January 18, 2017 9:40 PM
  • @Andre,

    >>why have you recommended if you know its the wrong setting?

    It is because in an old case we set up the server like this and it works from our side:

    You can see the story from here.

    And the final problem is that I'm not so sure whether Wake works for a server since we will get errors when using it for our server. I know that you want to use it in a Server client however it seems I cannot find any settings which can make it works when setting to "wake".

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, January 20, 2017 3:13 AM
    Moderator
  • so it is not possible with UWP to have a working listener if the App is in suspend lifecycle?
    Friday, January 20, 2017 2:04 PM
  • @cyberh0me,

    I've reported this from my internal channel. Please wait for the update about this.

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, January 25, 2017 1:28 AM
    Moderator
  • ????
    Thursday, February 02, 2017 1:52 PM
  • common guys i need a solution !!!
    Wednesday, February 08, 2017 5:09 PM
  • thank you for ignoring me!

    great support

    Wednesday, February 15, 2017 11:14 PM
  • @cyberh0me,

    I've sent the strike email at 2/10 but I haven't got response yet. I will check it for you again. 

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, February 16, 2017 8:10 AM
    Moderator
  • now i am waiting more than a month for valuable reply!
    Tuesday, February 28, 2017 9:19 PM
  • Hi cyberh0me,

    Sorry for the delay.

    > await _tcpListener.BindServiceNameAsync("80"); // raise an exception of type 'System.Runtime.InteropServices.COMException' occurred in mscorlib.ni.dll but was not handled in user code
    WinRT information: A wildcard address cannot be used with a specific port when the Wake standby action is set. Try using BindEndpointAsync with a non-null localHostName.

    This is by design. You need to specify the address if you want to bind to a specific port.

    > await _tcpListener.BindEndpointAsync(new HostName("172.16.0.105"), "80"); raises an exception but only in combination with _tcpListener.EnableTransferOwnership(_task.TaskId, SocketActivityConnectedStandbyAction.Wake);

    We fount it worked fine on WiFi, but using the USB Ethernet adapter, we see the same failure. It indicates that the adapter doesn't support plumbing the wake pattern, so the fact that it doesn't work is by design.

    The fact that we throw an exception rather than having some better mechanism in the API surface is unfortunate, but it can be worked around using an try/catch.

    > DoNotWake means "The app should not receive packets when the system goes to stand by" but I need packets always even if the app is in stand by ?
    > So the behavior is that Donotwake just receives info when your application is running, sounds like the right behavior for the "Donotwake"

    Actually DoNotWake is specifically about the machine going into standby (i.e. Connected Standby), not the app. Using DoNotWake will still trigger the background task even when the app is not running, but if the machine goes to sleep, there is no wake pattern plumbed to wake the machine up when packets are trying to be sent to that socket.

    So the conclusion is,

    If we actually needs the machine to wake up when possible try using Wake, and if it fails, fall back to using DoNotWake for interfaces that don't support Wake.

    If we doesn't need the machine to wake up, just use DoNotWake.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, March 01, 2017 7:27 AM
    Owner
  • hello

    "This is by design. You need to specify the address if you want to bind to a specific port."

    that does not make sense, what if i have more network adapters and the server should listen on every adapter at the same port?

    the server must be reachable even if the server is not the foreground app or paused or whatever!

    this is a base function of every server, reachable for client connections every time...

    DoNotWake did not worked as i have lost client connections (as its DoNotWake and not Wake) !

    Wake did not worked based on the error messages!

    so i cant use DoNotWake and i cant use Wake!

    "We fount it worked fine on WiFi, but using the USB Ethernet adapter, we see the same failure. It indicates that the adapter doesn't support plumbing the wake pattern, so the fact that it doesn't work is by design."

    so you tell me the Windows PC network adapter and the Windows IoT Core devices have all driver issues?

    br
    Andre

    Wednesday, March 01, 2017 4:22 PM
  • it does not make sense to waste more time with uwp and windows iot core
    Monday, March 20, 2017 10:41 PM