Background Connections

[AzureKitsune]

Hello rymate1234.

I saw that you updated your application to use background connections via ExtendedExecutionSessions. I think that it would be way better to use the SocketActivityTrigger instead. Basically, you use a background task to keep the socket alive.

With the (Redstone 1/Anniversary) Update, you can use background tasks from inside of your application so you wouldn't have to worry about writing code to communicate from your foreground app to your background task.

There are some code samples available on GitHub provided by Microsoft that showcase this functionality:

• Single-process Background Tasks
• Socket Activity Trigger

[jmurth1234]

Yeah, I found that a while back but couldn't figure out how to implement the communication between the background socket and the main app, so I gave up on it. Wasn't aware of it working in the single process background tasks, so I'll take another look at it.

[jmurth1234]

Latest commit adds an initial implementation of a single-process background task to hold sockets whilst suspended.

Since it's using the single process model, which was introduced in build 14393, the app will fall back to the ExtendedExecutionSession if single process background tasks aren't supported.

[jmurth1234]

Quick update on the progress of background sockets.

10 days ago, I was testing the feature again whilst fixing something relating to connecting to irc.esper.net and it wasn't backgrounding, which is why this issue was reopened. It seems to be working just fine today, so whether there was something preventing the background socket from being executed I dunno.

As far as I can tell, background sockets work just fine on my laptop when only one server is connected. Pings come through normally, the client stays connected, and when the app is resumed the socket returns to being processed by IrcSocket.cs rather than the socket broker.

When a client is connected to multiple servers, and the app suspends, both sockets fail to be transferred, and thus upon resuming both connections are broken. Until I fix this bug when multiple sockets are transferred, I will not be releasing a new version of WinIRC.

[AzureKitsune]

Is the app running out time when transferring the sockets when it is suspending?

[jmurth1234]

I'm specifically getting these two errors when transferring two sockets:

Exception thrown: 'System.Exception' in WinIRC.exe
'WinIRC.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\Users\Ryan\Documents\Visual Studio 2015\Projects\WinIRC\WinIRC\bin\x86\Debug\AppX\NotificationsExtensions.Win10.dll'. Cannot find or open the PDB file.
Element not found. (Exception from HRESULT: 0x80070490)
   at Windows.Networking.Sockets.StreamSocket.TransferOwnership(String socketId)
   at WinIRC.Net.IrcSocket.<SocketTransfer>d__9.MoveNext()
Exception thrown: 'System.InvalidOperationException' in WinIRC.exe
The thread 0x34fc has exited with code 0 (0x0).
A method was called at an unexpected time. (Exception from HRESULT: 0x8000000E)
   at Windows.Networking.Sockets.StreamSocket.TransferOwnership(String socketId)
   at WinIRC.Net.IrcSocket.<SocketTransfer>d__9.MoveNext()

I don't think the app is running out of time

[jmurth1234]

A rather unfortunate progress report

The next update will likely not have background sockets. Although it's a feature I would like to add, the difficulties I've faced in adding it means has massively reduced my motivation to work on WinIRC.

Instead, as a stop-gap I'll be implementing better handling of disconnects from the server.

This issue will stay open however - I do want to eventually implement this still.

[AzureKitsune]

@rymate1234 Its been a while. Have you tried activating Extended Execution before the app suspends (as in while the app is running normally)? Activating it while the app is running, instead of when its suspending, causes it to behave differently. It essentially prevents the app from suspending at all, thus allowing you to stay connected to the servers without using the socket broker. Its actually intended behavior, iirc.

I found this out while implementing a bus tracker app. I had to send a http request to a server every 5 minutes (which is far less than the TimerTrigger allows) and my app functioned as if it was in the foreground.

EDIT:

Even the official samples state it:

This sample demonstrates the following:

• Creating an extended execution session to extend suspending time and complete saving data.
• Creating an extended execution session to extend foreground time and continue location tracking.
• Creating an extended execution session to extend foreground time and continue an unspecified task.

[jmurth1234]

I'll have to give that a shot, thanks for the heads up!

[jmurth1234]

It appears as if using the Extended Execution session is mostly working, at least for now.

I'll be continuing to work on better recovery from situations where it doesn't work, e.g. app eventually suspending or being killed,

[AzureKitsune]

Any idea of when an update with this functionality will be pushed to the store?

[jmurth1234]

I'm reopening this, gonna have another go at implementing proper background sockets

[Supded]

Cool, thanks! I can't wait to get uwp opensource irc client with background support!