LongPolling transport fails to timeout on reconnect

[joeldart]

Description

Once you have a connection set up for LongPolling, if we error out, we attempt to reconnect by design. The challenge with longPolling is that to determine we reconnected, we have no initialized indication like in serverSentEvents. This leads to 3 places you would evaluate "reconnected": connection succeeded, connection failed, connection still running. https://github.com/DyKnow/SignalR-ObjC/blob/feature-dev/SignalR.Client/Transports/SRLongPollingTransport.m#L99 currently is designed to handle connection still running, but the current passed-around nsnumber is not accurately updating. Instead, we should store this callback and cancel it on connection succceeded and connection failed.

The current problem is if the connection is immediately terminated or has an error, Signalr-ObjC will continue on in this retry loop as if it was simply intermittent communication issues. This does not happen in other clients.

Replication Steps

Note: you will have to setup fiddler on your mac or setup a network proxy to run through fiddler on a pc

1. Create but do not initialize a fiddler rule to either terminate connection or return 503:

	public static RulesOption("Kill websocket")
	BindPref("fiddlerscript.rules.KillWS")
	var m_KillWS: boolean = false;
		
	public static RulesOption("Kill ServerSentEvents")
	BindPref("fiddlerscript.rules.KillSSE")
	var m_KillSSE: boolean = false;
		
	public static RulesOption("Kill LongPolling")
	BindPref("fiddlerscript.rules.KillLP")
	var m_KillLP: boolean = false;
...
	if (((m_KillWS && oSession.RequestHeaders.RequestPath.IndexOf("transport=webSockets") !== -1) ||
			(m_KillSSE && oSession.RequestHeaders.RequestPath.IndexOf("transport=serverSentEvents") !== -1) ||
			(m_KillLP && oSession.RequestHeaders.RequestPath.IndexOf("transport=longPolling") !== -1)) &&
			oSession.RequestHeaders.RequestPath.IndexOf("negotiate") === -1 //let negotiates through
		){
                 //note you cannot have both of these
		//	oSession.oRequest.pipeClient.EndWithRST();//<-- will kill connection
			oSession.oRequest.FailSession(503, "503", "This was a 503");<-- will sent a 503
			return;
		}

2. Start connection and verify it uses longPolling (note, you might want to turn on KillSSE to force this)
3. Turn on fiddler rule to kill long polling
4. in fiddler, find the longPolling connect (or poll, depending), right click, terminate
5. see how it continuously reconnects and never hits a reconnect timeout

Dev Requirements

• use an nsblockoperation and the same incremental timeout strategy used in js client

Fixed In

Testing