2g cut to the wifi, the network seems to still use 2g, very slow

[zhuolaiqiang]

2g cut to the wifi, the network seems to still use 2g, very slow。

You can determine the current state of network status and to establish a network socket connection is the same, if not the same, re-socket connection

[goaway]

Hey @zhuolaiqiang, thanks for opening the issue. This is known problem when hopping networks and is due to a bug in how session re-use occurs. The fix, as you describe, is to drain the currently active session when network reachability status changes to indicate the presence of a potentially faster network and establish a new connection. We need to do some testing though to ensure we're not frequently and unnecessarily draining healthy sessions.

[seivan]

@goaway By sessions, do you mean NSURLSession or a request?

[goaway]

Sorry, to clarify, what I meant was a SPDY session, as encapsulated by the SPDYSession class and described in the protocol draft.

If you have an open SPDY connection (session) to a server via a cellular data connection (WWAN) and a WIFI connection becomes available while the WWAN is also still available, as currently implemented the protocol will continue to dispatch requests over the existing session until it closes. If both the client and the server are configured to allow long-lived connections this could be quite a long time, resulting in the faster network not getting utilized.

As a stopgap measure, you could of course configure the server to timeout the connection after a shorter period, ensuring the user would switch to the faster network sooner, but setting it too short defeats some of the purpose (and performance gains) of SPDY.

If we operate on the premise that a WIFI connection is always better (not necessarily always true from a performance standpoint, but probably a reasonable assumption for now), probably the best case solution would be to open a WIFI SPDY session as soon as WIFI becomes available while attempting to gracefully drain the WWAN session. Another possibility would be to maintain both, but prefer the WIFI session as long as it's open. The disadvantage here is that it potentially complicates the landscape for things like server push.

[zhuolaiqiang]

hi, I have a temporary fix this problem , every time I make a network request , will determine whether the current network status and links to network socket consistent state , and if not , re- socket connection. There is no performance problems found

[zhuolaiqiang]

• (SPDYSession )sessionForURL:(NSURL *)url error:(NSError *)pError
  {
  SPDYOrigin *origin = [[SPDYOrigin alloc] initWithURL:url error:pError];
  NSMutableDictionary *activeSessions = [SPDYSessionManager activeSessions];
  SPDYSession *session = activeSessions[origin];

  BOOL networkChange = NO; //亿刀加
  if (session) //亿刀加
  { //亿刀加
  networkChange = session.currentStatus != session.networkStatus; //亿刀加
  } //亿刀加

  if (!session
  || !session.isOpen
  || networkChange //亿刀加
  )
  {
  session = [[SPDYSession alloc] initWithOrigin:origin
  configuration:currentConfiguration
  error:pError];
  if (session)
  {
  activeSessions[origin] = session;
  }
  }
  return session;
  }

[goaway]

Care to issue a pull request against the develop branch? I think this at least seems like a good starting point, and I'm curious as to how you scheduled your SCNetworkReachability callback (which I'm assuming is what you used to set currentStatus/networkStatus).