The following forum(s) are migrating to a new home on Microsoft Q&A (Preview): Developing Universal Windows apps!

Ask new questions on Microsoft Q&A (Preview).
Interact with existing posts until December 13, 2019, after which content will be closed to all new and existing posts.

Learn More

 none
[UWP]SocketActivityTrigger and RTC Problems RRS feed

  • Question

  • Hello, I've had cases where SocketActivityInformation.AllSockets.TryGetValue would fail to retrieve a socket that was previously transferred to the socket broker, although it was never closed and remained active the the background. Retrying after a few moments would succeed in reclaiming the socket.

    1. Is this by design, what can cause this to occur, and how should it be handled?

    2. After an app is resumed, can the socket broker still execute the SocketActivityTrigger background task?

    3. At what point does a socket become untriggerable after the app resumes/relaunches? What line of code, in particular, can declare to the broker that the app has reclaimed ownership of the socket?

    4. Is synchronization needed to ensure the background task isn't running after the app resumes (until the app can reclaim ownership, if necessary) or is that handled by the runtime? If so, what should this code look like?

    On a related note, in Windows 8.1, there were hardware slots for background networking based on the lockscreen setup. The first 3? lockscreen app slots had access to real-time communication (RTC), which enhanced these apps' ability to operate sockets in the background. On Windows 10, the limitations of the lockscreen app/hardware slot system have been removed, however, when running 8.1 store apps that took advantage of RTC capabilities, there are now some inconsistencies. Here are the cases I've seen:

    1. On my desktop computer, Windows 10 Home 64-bit (upgrade from Win7) on wired ethernet, the app is RTC enabled and functions as expected, staying connected while suspended, etc.

    2. On my tablet (Venue 8 Pro 5830), Win10 Home 32-bit (upgrade from 8.1) on wireless 11n, the app is RTC disabled and cannot seem to receive data on its connections, despite establishing them. The app worked on 8.1.

    3. On another person's tablet (Asus VivoTab Note 8), Win10 Home 32-bit (from 8.1), wireless, the app is RTC enabled and can connect, but cannot maintain the connection while suspended.

    4. On that other person's desktop, Win10 64-bit, wired ethernet, the app is RTC disabled and, although it can connect, it cannot maintain a connection while suspended.

    The question is, on Windows 10, what determines the RTC capability for 8.1 store apps now that the lockscreen app system (7 apps total had software background slots, first 3 had hardware slots) has been discarded? What is the cause of these 4 variations in behavior for the same app? The app being tested was IRC Explorer 2.2.1. Uninstall/reinstall of the app had no effect on RTC status/connectivity behavior.

    Are the RTC hardware slot/lockscreen app settings migrated from 8.1 to 10 and can they be changed or reset in Windows 10? Registry fixes are acceptable for me.

    Thursday, August 13, 2015 8:29 PM

All replies

  • For your first issue, could you reproduce it using official SocketActivityStreamSocket sample: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/SocketActivityStreamSocket

    For the second one, should works


    Best Regards,
    Please remember to mark the replies as answers if they help

    Friday, August 14, 2015 6:53 AM
  • The SocketActivityStreamSocket sample is close enough to the test code that it would eventually have the same failure. When you say, "For the second one, should works", I'm not sure what this is in reference to. There were a lot of critically important questions in the first post and, in order to make the most of this platform, devs need clear answers to almost all of these questions, as the documentation is extremely sparse right now. Trial and error is time consuming and may lead to incorrect assumptions about the runtime and implementation.

    The concept of the SocketActivityTrigger is brilliant, however if these questions aren't answered, it will become considered as unreliable tech. For example, generally speaking, the SocketActivityTrigger background task in my test app can keep a socket's connection alive and operational for many hours (possibly indefinitely) while the app is suspended or even closed entirely.

    However, on my Dell Venue 8 Pro 5830 tablet on Windows 10, it will cease background socket activity almost immediately after entering Connected Standby, even when plugged in at 100% battery charge with Battery Saver disabled (this device supports Modern Connected Standby as "Standby (S0 Low Power Idle) Network Connected" from powercfg /a). The powercfg /sleepstudy command confirms that the device enters Connected Standby, but the SocketActivityTrigger background task does not seem to operate (or maybe it begins to operate in an unexpected, undocumented way).

    In a similar way, the Lumia 520 on Windows 10 Mobile build 10512 can keep the socket connected and operational for about 20 minutes to 1 hour in Connected Standby, but it, too, eventually fails. Considering that the socket once dropped on the Lumia 520 moments after displaying an email notification, I'm suspecting that receiving a push notification from WNS may be what causes the SocketActivityTrigger task to cease operating, but I have no way to confirm this.

    The platform devs at Microsoft need to make the reasons for these issues more clear, so devs can fully take advantage of Microsoft's work in implementing these technologies. For SocketActivityTrigger, answers are needed for all of these questions:

    1. When AllSockets.TryGetValue temporarily fails to retrieve a socket that is still alive in the background, is this by design, what can cause this to occur, and how should it be handled?

    2. After an app is resumed, can the socket broker still execute the SocketActivityTrigger background task?

    3. At what point does a socket become untriggerable after the app resumes/relaunches? What line of code, in particular, can declare to the broker that the app has reclaimed ownership of the socket?

    4. Is synchronization needed to ensure the background task isn't running after the app resumes (until the app can reclaim ownership, if necessary) or is that handled by the runtime? If so, what should this code look like?

    5. Is there a timeout for the socket to drop regardless, even when there's essentially no other device activity and the device is plugged in?

    6. In the SocketActivityStreamSocket sample, BackgroundExecutionManager.RequestAccessAsync() is never called. The documentation suggests that Windows 10 still requires this, so why does this sample still operate without it? From the documentation: "On Windows 10, Windows Server Technical Preview, and Windows 10 Mobile, you do not need to add the app to the lock screen before the app registers background tasks, but you still need to call RequestAccessAsync to request background access."

    --------------------------------

    For lockscreen app/RTC issues on Windows 10 for store apps designed for Windows 8.1 (search for "hardware slot" on this page to understand what I'm referencing: https://msdn.microsoft.com/en-us/library/windows/apps/xaml/JJ662741.aspx), answers are required for the following:

    1. On Windows 10, what determines the RTC capability for 8.1 store apps now that the lockscreen app system (7 apps total had software background slots, first 3 had hardware slots) has been discarded?

    2. What is the cause of the 4 variations in behavior for the same app as described in the first post, where RTC is enabled/disabled differently on similar devices? RTC status/connectivity behavior/failure is unchangeable for each system, despite system restarts, updates, battery or plugged in state, wireless or wired, app reinstall, etc.

    3. It seems that, on some devices, only "software slots" are available on Windows 10, while the same apps on the same devices had access to hardware slots on Windows 8.1 when they were placed on the lockscreen. Are the RTC hardware slot/lockscreen app settings migrated from 8.1 to 10 during the upgrade and can they be changed or reset in Windows 10? Can a system reset/clean install correct this issue or a registry/ProgramData/AppData change?

    Please answer all of these questions as thoroughly as possible, so all of the platform work you've done for Windows 10 can be fully understood by devs. Thanks for your time.


    • Edited by Nobody31 Friday, August 14, 2015 10:51 AM
    Friday, August 14, 2015 10:24 AM
  • Adding a new issue, SocketActivityInformation.AllSockets.TryGetValue(socketId, out info) occasionally throws an exception: Element not found. (Excep_FromHResult 0x80070490) in get_AllSockets. What could cause this exception to occur in the AllSockets getter? This is a separate issue from the previous one, where TryGetValue returns false without an exception, even though a socket with a matching id is active with the broker.

    Answers for the 9 numbered questions in the previous post are needed, as well.

    • Edited by Nobody31 Saturday, August 15, 2015 1:47 AM
    Saturday, August 15, 2015 1:03 AM
  • Another question about SocketActivityTrigger:

    7. If multiple sockets are transferred by a single app to the socket broker with a single background task id and activity occurs on more than 1 socket at the same time, would multiple instances of the associated background task be executed to handle the sockets simultaneously/concurrently OR would a single instance of the background task be called for each socket, one by one in sequence?

    Please see the previous questions, as well. I hope this thread can be a useful point of reference for developers on this topic if we can get answers to all of these questions. Thank you for your time.

    Thursday, August 20, 2015 9:16 PM
  • Another set for SocketActivityTrigger:

    8. If a background task instance receives a cancellation event notification at the very start of the Run method (usually BackgroundTaskCancellationReason.ExecutionTimeExceeded in my case), and the task has not yet begun to work with the socket (has not called the getter on SocketActivityInformation.StreamSocket), should the task return as-is, or should the task still get the StreamSocket, call TransferOwnership on it, and then return?

    9. What are the best practices to avoid cancellation in a SocketActivityTrigger background task? For example, when called for SocketActivityTriggerReason.SocketActivity, is it best to use LoadAsync to read and handle as many packets as possible in 20 seconds (staying under the 25+5 second cap) to avoid multiple instances of the task getting executed consecutively, or is it better if the task calls LoadAsync only once per task instance and lets the system run additional task instances if necessary?

    10. In Windows 10, background tasks have no "CPU time" limit, but a real world time limit of 25 seconds + 5 seconds and each task instance gets its own 25+5s quota. Does this apply to SocketActivityTrigger instances or are there special rules? In other words, if each instance takes far less than 1 second to complete (only calls LoadAsync once, handles the data (about 50 bytes each time), and returns), but task instances are created up to 30 times per minute to handle incoming data on the socket, could this lead to cancellation for ExecutionTimeExceeded? What can cause ExecutionTimeExceeded in this scenario, considering the low network usage and low real-world time used by each task instance?

    11. Is a SocketActivityTrigger background task that makes many async calls more likely to get cancelled or less likely? Should async disk writes be preferred over synchronous writes? Should writes (both disk and socket) be flushed within the task? Is there a disk read/write quota? Which quotas are not reset per task instance?

    12. If a task instance is cancelled at the start, before the StreamSocket getter, and it was providing an important notification like SocketActivityTriggerReason.SocketClosed, would the socket broker retry or would the SocketClosed notification be permanently lost? In the same sense, if a SocketActivityTriggerReason.SocketActivity instance had to be cancelled before LoadAsync was executed, would the broker retry this in a few moments or would it wait until new data was available on the socket?

    13. The powershell cmdlet get-appbackgroundtask with -includeresourceusage does not show resource stats for my SocketActivityTrigger background task (and some other unrelated apps' background tasks in the list). Why is this and what should I do to enable it?

    Thanks!

    Sunday, August 23, 2015 1:04 AM