Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ServerSentEvents Transport fails to timeout on reconnect #300

Open
1 task
joeldart opened this issue Nov 28, 2018 · 1 comment
Open
1 task

ServerSentEvents Transport fails to timeout on reconnect #300

joeldart opened this issue Nov 28, 2018 · 1 comment

Comments

@joeldart
Copy link
Member

Description

Once you have a connection set up for ServerSentEvents, if that connection is aborted/completed, by design, we reconnect. The current design relies on the stream open event https://github.com/DyKnow/SignalR-ObjC/blob/feature-dev/SignalR.Client/Transports/ServerSentEvents/SREventSourceStreamReader.m#L84 which then communicates up to the connection's didReconnect. At that point, the reconnect timeout is satisfied and we move over to connected.

The 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;
		}
  1. Start connection and verify it uses ServerSentEvents
  2. Turn on fiddler rule
  3. in fiddler, find the serversentevents connect, right click, terminate
  4. see how it continuously reconnects and never hits a reconnect timeout

Dev Requirements

  • figure out how to call opened after inspecting headers/

Fixed In

Testing

joeldart added a commit that referenced this issue Nov 28, 2018
- 503 errors or firewall software, etc will hit the
NSStreamEventOpenCompleted and thus the onOpened callback. But we do
not want to trigger didReconnect here or else we’ll never timeout our
reconnect. Instead, process the initialized message that is sent down.
joeldart added a commit that referenced this issue Dec 12, 2018
- left out an important change for 300: moving the reconnect logic
exclusively to the message + initialized loop. prior code didn’t
actually change anything
joeldart added a commit that referenced this issue Dec 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@joeldart and others