iOS - XMPP 빠른 로그인

이전 글에서 XMPP 연결을 구축해야 할 때 총 6개의 데이터 패키지를 Openfire 서버에 보냅니다.먼저 살펴보겠습니다.

17:22:41.357  -[XMPPManager xmppStreamWillConnect:] socket ...

17:22:42.100  -[XMPPManager xmppStream:socketDidConnect:] socket ...

17:22:42.102  ①、SEND: 

17:22:42.103  ②、SEND: 

17:22:43.085  RECV: PLAIN

17:22:43.086  -[XMPPManager xmppStreamDidConnect:] [Line 198] xmpp ,  ......

17:22:43.087  ③、SEND:  APINT4ANBTYg6IJ 
 APINT4ANBTYg6IJ iOS_V1.0

17:22:43.534  RECV: 

17:22:43.534  ④、SEND: 

17:22:43.870  RECV: 

17:22:43.871  ⑤、SEND: iOS_V1.0

17:22:44.261  RECV: [email protected]/iOS_V1.0

17:22:44.262  ⑥、SEND: 

17:22:44.669  RECV: 

17:22:44.670  -[XMPPManager xmppStreamDidAuthenticate:] [Line 208] xmpp 。

이런 데이터 패키지를 봐도 아무런 문제가 발견되지 않지만 제품이 온라인으로 오랫동안 운행된 데다가 사용자 양이 일정한 규모에 이르렀을 때 데이터 모니터링을 통해 XMPP 연결 성공률이 높지 않다는 것을 알 수 있다.그래서 기술부 몇몇 동료들은 회의를 열어 이 지표를 어떻게 향상시킬 것인가를 토론했다.전후단 연결을 통해 연결을 구축할 때 클라이언트가 그렇게 많은 데이터 패키지를 보낼 필요가 없다는 것을 발견했다. 몇 가지 조작은 클라이언트에서 할 필요가 없다. 서버에서 조작하는 것이 더욱 편리할 뿐만 아니라 대역폭을 절약하고 서버의 압력을 낮출 수 있다. 클라이언트가 데이터를 보낼 때마다 서버에 압력을 증가시킨다.
그래서 새로운 명사가 생겼다. 우리는 이번 최적화된 로그인을 빠른 로그인이라고 부른다.주요 방법은 다음과 같습니다.

①을 빼라. 이 패킷은 네트워크를 탐지하기 위한 것일 뿐 아무 소용이 없는 것 같다

②의 stream:stream 패키지는 필수이며, 이전 버전을 구별하기 위해 필드를 하나 더 추가v=‘1.0’

③중의auth는 매우 중요하고 감권에 쓰인다.여기에 수정을 해서 resource 서브노드를 auth 노드의 속성으로 하고 구 버전을 호환하기 위해 이곳의 자원은 구 버전과 다르다. 서버 측은 이것에 따라 신구 버전을 판단하고 리소스의 값을 iOS_로 변경한다.FL_V1.0

④를 빼라

⑤ 및 ⑥ 이 절차는 서버에서만 수행할 수 있음

수정한 후에 전체 로그인된 송수신 패킷은 다음과 같이 보입니다.

11:52:24:022 SEND: 

11:52:24:030 RECV: 

11:52:24:031 RECV: PLAIN

11:52:24:044 SEND: APINT4ANBTYg6IJ

11:52:24:054 RECV: 

클라이언트가 2개의 데이터 패키지만 보내면 빠른 로그인을 할 수 있으니 간결하지 않겠습니까?클라이언트가 많은 패키지를 보내야만 로그인할 수 있다면, 그 동안 네트워크 때문에 패키지가 발송되지 않았거나, 서버가 되돌아온 패키지를 받을 수 없어서 로그인할 수 없을 수도 있습니다.빠른 로그인은 불필요한 데이터 패키지를 줄이고 로그인 성공률을 높이기 위한 것이다.
빠른 로그인을 위해 원본 코드를 수정하는 방법을 설명합니다.물론 가장 중요한 종류XMPPStream는 위의 방법에 따라 한 걸음 한 걸음

이 방법의 실현을 찾아

if (![self didStartNegotiation])

{//TCP connection was just opened - We need to include the opening XML stanza NSString*s1 = @ ";

  NSData *outgoingData = [s1 dataUsingEncoding:NSUTF8StringEncoding];
  
  XMPPLogSend(@"SEND: %@", s1);
  numberOfBytesSent += [outgoingData length];
  
  [asyncSocket writeData:outgoingData
             withTimeout:TIMEOUT_XMPP_WRITE
                     tag:TAG_XMPP_WRITE_START];
  
  [self setDidStartNegotiation:YES];
}

이 코드 주석.

동일- (void)sendOpeningNegotiation; 이 방법, if(myJID_setByClient) {//수정여기s2 = [NSStringstringWithFormat:"", xmlns, xmlns_stream, [myJID_setByClient domain]]];}else if ([hostName length] > 0) { temp = @""; s2 = [NSString stringWithFormat:temp, xmlns, xmlns_stream, hostName]; } else { temp = @""; s2 = [NSString stringWithFormat:temp, xmlns, xmlns_stream]; }

수정- (void)sendOpeningNegotiation; 패키지의 내용은 약간 복잡하다. auth 연결이 되면 Socket 이 에이전트 리셋에서 - (void)xmppStreamDidConnect:(XMPPStream *)sender; 모니터링 로그인을 한다.이 방법을 따라 들어가면 저희 앱에서 로그인하면 - (BOOL)authenticateWithPassword:(NSString *)inPassword error:(NSError **)errPtr;, else if ([self supportsPlainAuthentication]) 클래스에 들어가서 XMPPPlainAuthentication 패키지의 내용을 수정해야 합니다. auth 이 방법을 찾으면 다음과 같이 수정할 수 있습니다.NSXMLElement *auth = [NSXMLElement elementWithName:@"auth"xmlns:@"urn:ietf:params:xml:ns:xmpp-sasl"]; [auth addAttributeWithName:@"mechanism"stringValue:@"PLAIN"]; [auth addAttributeWithName:@"res"stringValue:@"iOS_FL_V1.0"]; [auth setStringValue:base64]; ......

클라이언트가 - (BOOL)start:(NSError **)errPtr; 패키지를 보낸 후에 성공하면 서버 측은 auth 패키지를 되돌려 success 클래스XMPPStream에서 처리합니다.이 방법의 실현은 좀 이상하다. 분명히 감권에 성공했는데 왜 가방- (void)handleAuth:(NSXMLElement *)authResponse;을 보내야 하는지 백엔드와 연결을 통해 재발급할 필요가 없다는 것을 발견하고 판단을 내렸다. stream 이 변수를 shouldRenegotiate로 쓰면 된다. 그러면 발송하지 않을 것이다

빠른 로그인을 통해 클라이언트와 서버 간의 데이터 패키지 전송 수량이 줄어들었다. 우리 온라인 수백만 명의 사용자의 사용 상황을 보면 효과가 뚜렷하고 아무런 문제가 발생하지 않아 로그인 성공률을 크게 향상시켰다.NO 연결 로그인은 지금까지 갱도가 비교적 많아서 사용자 수가 일정한 규모에 도달해야만 나타날 수 있다. 일부 사람들을 면접한 적이 있다. 그들도 XMPP에 대해 알고 관련 프로젝트를 한 적이 있지만 연결에 관한 질문을 할 때 기본적으로 어떤 문제도 만나지 않았다고 한다.이것은 사실 그들의 문제가 아니다.IM 제품으로서 정상적인 채팅을 할 수 없다면 어떻게 IM이라고 말할 수 있겠는가.
점심 먹었는데...