KR101404280B1

KR101404280B1 - 연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법 및 장치

Info

Publication number: KR101404280B1
Application number: KR1020120057916A
Authority: KR
Inventors: 김진영
Original assignee: 삼성에스디에스 주식회사
Priority date: 2012-05-31
Filing date: 2012-05-31
Publication date: 2014-06-05
Also published as: KR20130134425A

Abstract

본 발명적 개념의 일 실시예에 따르면, 연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법에 있어서, 상기 서버가, 세션을 유지하고 있는 클라이언트로부터 소정 주기 내에 주기적 전송 패킷을 수신하였는지 판단하는 단계; 상기 주기적 전송 패킷을 수신하였다면, 상기 주기적 전송 패킷에서 상기 클라이언트가 새로운 주소를 할당 받았는지 확인하는 단계; 및 상기 새로운 주소를 할당 받았으면, 기존 주소를 상기 새로운 주소로 변경하여 상기 세션을 유지하는 단계;를 포함하는 방법 및 이를 구현하는 장치가 개시된다.

Description

연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법 및 장치 {Method and apparatus for keeping client-server connection using periodic transmission packet in connection-persistence-type service}

본 발명은 연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법 및 장치에 관한 것으로, 보다 상세하게는, 연결 지속형 서비스에서 클라이언트가 이동함에 따라 클라이언트의 IP 주소가 변경되더라도 클라이언트와 서버 사이의 연결을 유지할 수 있는 클라이언트-서버간 연결 유지 방법 및 장치에 관한 것이다.

최근 보다 지능화된 통신 서비스를 위해 푸쉬 서비스(Push Service)가 널리 사용되고 있다. 푸쉬 서비스는 서버에 의해 능동적으로 클라이언트에게 데이터를 전송하는 서비스로서, 특정 정보나 뉴스, 통지 등을 실시간으로 사용자 단말로 제공함으로써 사용자 편의성을 높이고 있다.
예를 들면, 푸쉬 서비스에 대한 기술이 기재된 종래의 기술문헌들은 다음과 같다.
한국공개특허공보 10-2010-0043685호 "무선망환경에서 동적 IP 기반의 양방향 푸시 서비스 시스템"(씽크엠)
한국공개특허공보 10-2011-0110456호 "모바일 단말, 올웨이즈 온 기반의 데이터 푸쉬 방법 및 시스템"(엘지유플러스)

이러한 푸쉬 서비스는 그 특성상 연결이 끊어지지 않는 것이 중요하다. 그러나 클라이언트가 모바일 디바이스와 같은 휴대용 장치인 경우 클라이언트가 이동함에 따라 클라이언트의 IP 주소가 계속하여 변경되므로, 기존의 클라이언트-서버간 연결(세션)이 끊어지고 새로운 연결을 생성해야 한다. 기존 연결이 해지되고 신규 연결이 생성되기까지의 시간 동안 서버 측은 상황을 알 수 없고 클라이언트는 새로운 IP 주소를 할당받아 서버에 다시 연결하기까지 시간이 소요된다.

그러므로, 클라이언트의 이동에 따른 주소 변경에도 불구하고 클라이언트-서버간 연결을 유지함으로써 서비스의 지속적 제공을 받을 수 있는 방법에 대한 필요성이 제기되고 있다.

본 발명적 개념의 일 실시예에 따르면, 클라이언트의 이동에 따라 IP 주소가 변경되더라도 클라이언트-서버간 연결을 유지함으로써 서비스를 지속적으로 제공할 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.

본 발명적 개념의 일 실시예에 따르면, 클라이언트-서버간 연결 유지 방법을 클라이언트와 서버의 응용계층에서 관리할 수 있는 방법 및 장치를 제공하는 것을 목적으로 한다.

본 발명적 개념의 일 실시예에 따르면, 연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법에 있어서, 상기 서버가, 세션을 유지하고 있는 클라이언트로부터 소정 주기 내에 주기적 전송 패킷을 수신하였는지 판단하는 단계; 상기 주기적 전송 패킷을 수신하였다면, 상기 주기적 전송 패킷에서 상기 클라이언트가 새로운 주소를 할당 받았는지 확인하는 단계; 및 상기 새로운 주소를 할당 받았으면, 기존 주소를 상기 새로운 주소로 변경하여 상기 세션을 유지하는 단계;를 포함하는 방법이 제공된다.

본 발명적 개념의 다른 실시예에 따르면, 클라이언트에게 연결 지속형 서비스를 제공하고 상기 클라이언트로부터 소정 주기마다 주기적 전송 패킷을 수신하는 서버 장치에 있어서, 하나 이상의 클라이언트에게 연결 지속형 서비스를 제공하는 애플리케이션부; 상기 클라이언트의 IP 주소를 저장하는 저장부; 및 상기 클라이언트와 통신하기 위해 데이터를 송수신하는 통신부;를 포함하고, 상기 애플리케이션부가, 상기 클라이언트로부터 수신한 주기적 전송 패킷으로부터 상기 클라이언트가 새로운 주소를 할당 받았는지 여부를 확인하고, 클라이언트가 새로운 주소를 할당 받았으면, 상기 클라이언트와의 연결(세션)에 사용된 기존 주소를 상기 새로운 주소로 변경하여 상기 세션을 유지하는 서버 장치가 제공된다.

본 발명적 개념의 다른 실시예에 따르면, 상기 클라이언트-서버간 연결을 유지하는 방법을 컴퓨터에서 실행시키기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체가 제공된다.

본 발명적 개념의 일 실시예에 따르면, 클라이언트의 이동에 따라 IP 주소가 변경되더라도 클라이언트-서버간 연결을 유지함으로써 서비스를 지속적으로 제공할 수 있는 이점이 있다.

본 발명적 개념의 일 실시예에 따르면, 클라이언트-서버간 연결 유지 방법을 클라이언트와 서버의 응용계층에서 관리함으로써, 하위 계층의 동작에 관계없이 각 연결 지속형 서비스에 대한 세션을 관리할 수 있는 이점이 있다.

도1은 예시적 일 실시예에 따른 클라이언트-서버간 연결 유지 방법을 설명하기 위한 블록도,
도2a 및 도2b는 예시적 일 실시예에 따른 주기적 전송 패킷을 설명하기 위한 블록도,
도3은 예시적 일 실시예에 따른 클라이언트-서버간 연결을 유지하는 장치를 설명하기 위한 블록도,
도4는 제1 실시예에 따라 클라이언트-서버간 연결을 유지하는 방법을 나타내는 흐름도,
도5는 제2 실시예에 따라 클라이언트-서버간 연결을 유지하는 방법을 나타내는 흐름도,
도6은 도4 또는 도5에서 단계(S403)를 실행하는 예시적 방법을 나타내는 흐름도이다.

이상의 본 발명의 목적들, 다른 목적들, 특징들 및 이점들은 첨부된 도면과 관련된 이하의 바람직한 실시예들을 통해서 쉽게 이해될 것이다. 그러나 본 발명은 여기서 설명되는 실시예들에 한정되지 않고 다른 형태로 구체화될 수도 있다. 오히려, 여기서 소개되는 실시예들은 개시된 내용이 철저하고 완전해질 수 있도록 그리고 당업자에게 본 발명의 사상이 충분히 전달될 수 있도록 하기 위해 제공되는 것이다.

본 명세서에서, 어떤 구성요소가 다른 구성요소 상에 있다고 언급되는 경우에 그것은 다른 구성요소 상에 직접 형성될 수 있거나 또는 그들 사이에 제 3의 구성요소가 개재될 수도 있다는 것을 의미한다.

본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 '포함한다' 및/또는 '포함하는'은 언급된 구성요소는 하나 이상의 다른 구성요소의 존재 또는 추가를 배제하지 않는다.

이하, 도면을 참조하여 본 발명을 상세히 설명하도록 한다. 아래의 특정 실시예들을 기술하는데 있어서, 여러 가지의 특정적인 내용들은 발명을 더 구체적으로 설명하고 이해를 돕기 위해 작성되었다. 하지만 본 발명을 이해할 수 있을 정도로 이 분야의 지식을 갖고 있는 독자는 이러한 여러 가지의 특정적인 내용들이 없어도 사용될 수 있다는 것을 인지할 수 있다. 어떤 경우에는, 발명을 기술하는 데 있어서 흔히 알려졌으면서 발명과 크게 관련 없는 부분들은 본 발명을 설명하는 데 있어 혼돈이 오는 것을 막기 위해 기술하지 않음을 미리 언급해 둔다.

도1은 예시적 일 실시예에 따른 클라이언트-서버간 연결 유지 방법을 설명하기 위한 블록도이고, 모바일 노드(MN,MN')(100)가 서버(200)와 통신하는 것을 나타낸다.

도1을 참조하면, 모바일 노드(100)는 클라이언트-서버 모델에서 클라이언트의 일 예시이고, 예를 들어 스마트폰, 태블릿 PC, 노트북 컴퓨터 등 이동 가능한 휴대용 모바일 디바이스 중 임의의 디바이스일 수 있다.

모바일 노드(100)는 유선 및/또는 무선 네트워크(도시 생략)를 통해 서버(200)와 통신한다. 모바일 노드(100)가 이동중일 때는 예컨대 이동통신망 또는 무선 인터넷망 등의 네트워크를 통해 서버(200)와 통신할 수 있다.

도1에서 서버(200)는 예컨대 임의의 푸쉬 서비스를 제공하는 서버일 수 있다. 서버(200)는 푸쉬 서비스에 따른 임의의 정보나 뉴스, 통지 등의 데이터를 모바일 노드(100)에 전송한다. 도1에서는 하나의 모바일 노드(100)만을 도시하였지만 서버(200)가 다수의 모바일 노드들에 푸쉬 서비스용 데이터를 전송할 수 있음은 물론이다.

그리고 도1의 서버(200)는 임의의 "연결 지속형 서비스"를 제공하는 서버가 될 수도 있다. 여기서 "연결 지속형 서비스"는 예컨대 인스턴트 메신저나 푸쉬 이메일 서비스 등과 같이, 해당 서비스를 현 시점에서 사용하지 않을지라도 해당 서비스를 제공하는 서버와 모바일 노드 사이의 연결을 계속 유지해야 하는 서비스를 통칭한 것이다. 따라서 이하의 본 명세서에서 서버(200)를 푸쉬 서비스 제공 서버로 예시하여 설명하지만 서버(200)는 푸쉬 서비스를 비롯한 임의의 연결 지속형 서비스 중 하나 이상의 서비스를 제공할 수 있는 임의의 애플리케이션 서버일 수 있다.

이러한 구성에서, 모바일 노드(100)와 서버(200)의 연결을 유지하기 위해 모바일 노드(100)는 주기적으로 소정의 킵-얼라이브(keep-alive) 패킷을 서버(200)에 전송한다. 일 실시예에서 이러한 킵-얼라이브 패킷을 하트비트(heartbeat) 라고 부르기도 한다.

이에 따라, 도1에 도시한 바와 같이 모바일 노드(MN)(100)가 이동 전의 위치에서 소정 간격으로 주기적 전송 패킷(하트비트)을 서버(200)로 전송하고, 모바일 노드가 이동하더라도 이동 후의 모바일 노드(MN')(100)는 계속하여 주기적 전송 패킷을 서버(200)로 전송함으로써 모바일 노드(100)와 서버(200)와의 연결을 유지하고 있다.

바람직한 일 실시예에 따라 모바일 노드(100)는 주기적 전송 패킷 내에 해당 모바일 노드(100)의 IP 주소에 관한 정보를 포함시켜 서버(200)로 전송한다. 따라서, 모바일 노드(100)가 이동함에 따라 모바일 노드(100)의 IP 주소가 변경되더라도, IP 주소 정보를 주기적으로 수신하는 서버(200)는 모바일 노드(100)의 주소 변경 여부를 모니터링 할 수 있고, 모바일 노드(100)의 이동에 상관없이 모바일 노드와의 연결을 지속적으로 유지할 수 있다.

이 때 본 발명의 바람직한 실시예에 의하면, 모바일 노드(100)에서 주기적 전송 패킷 내에 IP 주소 정보를 포함시켜서 서버(200)로 전송하는 기능 및 서버(200)에서 주기적 전송 패킷 내의 IP 주소 정보를 판독하여 모바일 노드의 연결을 지속적으로 유지하는 기능은 각각 모바일 노드(100)와 서버(200)의 응용계층(즉 L5 이상의 계층)에서 수행될 수 있다. 그러므로 종래 L3(IP 계층) 또는 L4(TCP/UDP 계층)에서의 네트워크 제어에 관계없이, 푸쉬 서비스를 제공하는 각 애플리케이션 레벨에서 각 푸쉬 서비스에 대한 세션을 관리할 수 있는 이점이 있다.

본 발명의 일 실시에에서 따른 상기 주소 정보를 포함하는 주기적 전송 패킷의 일 예를 도2를 참조하여 설명하기로 한다.

도2a 및 도2b는 예시적 일 실시예에 따른 주기적 전송 패킷을 설명하기 위한 블록도이다. 이하에서 상기 주기적 전송 패킷을 "하트비트"로 칭하기로 한다. 그러나 이 용어는 예시적인 것일 뿐 본 발명을 제한하지 않으며, 본 발명이 클라이언트-서버간 전송되는 임의의 주기적 전송 패킷에 적용될 수 있음은 물론이다.

도2a를 참조하면, 일 실시예에 따른 주기적 전송 패킷(하트비트)(300)은 헤더(310)와 페이로드(payload)(320) 영역으로 구분된다.

바람직한 일 실시예에서 헤더(310)는 주소정보 플래그(311)를 포함한다. 주소정보 플래그(311)는 모바일 노드(100)의 주소정보에 관한 플래그로서, 페이로드(320)의 주소정보 페이로드(321) 영역에 데이터가 존재하는지 여부를 표시한다. 예를 들어 플래그(311)가 1비트 크기를 가질 수 있고, 이 때 플래그(311)가 1이면 주소정보 페이로드(321)에 데이터가 존재하고 플래그(311)가 0이면 주소정보 페이로드(321)에 데이터가 존재하지 않음을 표시하도록 설정될 수 있다.

헤더(310)의 나머지 영역은 기존에 사용되는 하트비트의 헤더 영역과 동일 또는 유사한 용도로 사용될 수 있다.

페이로드(320)는 하트비트의 데이터 영역으로, 바람직한 일 실시예에서 주소정보 페이로드(321)를 포함한다. 주소정보 페이로드(321)는 모바일 노드의 주소정보를 포함하는 영역으로, 예를 들어 모바일 노드의 IP 주소를 포함할 수 있다. 일 실시예에서, 모바일 노드(100)가 이동함에 따라 새로운 IP 주소를 할당받는 경우 주소정보 페이로드(321)에 이 새로운 IP 주소가 포함될 수 있다.

한편 도2b는 바람직한 일 실시에에 따른 주기적 전송 패킷(하트비트)의 대안적인 실시예를 나타낸다. 이 대안적인 실시예에서 하트비트(400)는 모바일 노드(100)를 다른 모바일 노드와 식별하기 위한 인증 정보를 더 포함할 수 있다.

하트비트(400)가 인증 정보를 포함하는 경우로는 예컨대 하드 핸드오버(hard handover) 상황을 가정할 수 있다. 하드 핸드오버에서는 모바일 노드(100)가 기존의 주소값으로 하트비트를 전송할 수 없으므로, 이러한 경우 다른 주소(예컨대 새로 할당받은 주소)를 소스 IP로 하여 하트비트를 전송하되, 서버(200)는 기존 주소값으로 전송된 하트비트와 이 새로운 주소값으로 전송된 하트비트가 동일 모바일 노드에서 전송된 것임을 알 수 있어야 한다. 따라서 서버에서 이러한 모바일 노드의 동일성을 신뢰할 수 있도록 하기 위해 하트비트(400)에 인증 정보를 추가로 포함시키는 것이다.

도2b를 참조하면, 하트비트(400)가 이러한 인증 정보를 더 포함하는 실시예에서 헤더(410)는 인증 정보에 대한 플래그(411)를 더 포함하고 페이로드(420)는 인증정보 페이로드(421)를 더 포함할 수 있다.

이 실시예에서 인증정보 플래그(411)는 인증 정보에 대한 1비트 크기의 플래그일 수 있고, 플래그(411)가 1이면 페이로드(420)의 인증정보 페이로드(421)에 데이터가 존재함을 나타내고 플래그(411)가 0이면 인증정보 페이로드(421)에 데이터가 존재하지 않음을 나타내도록 설정될 수 있다.

인증 정보에 사용되는 정보는 특별히 한정되지 않으며 모바일 노드를 다른 모바일 노드와 구별할 수 있는 정보이면 어떠한 정보도 무방하다. 실시 형태에 따라 예를 들어 모바일 노드의 MAC(Media Access Control) 주소가 인증 정보로 사용될 수 있고, 모바일 노드가 휴대폰 기능을 포함하는 경우 전화번호가 인증 정보로 사용될 수도 있다.

이러한 구성에서, 예를 들어 모바일 노드(100)가 이동하지 않는 경우, 모바일 노드(100)는 소정의 IP 주소를 계속 사용하고 있고 모바일 노드(100)에서 서버(200)로 주기적으로 전송되는 하트비트(300,400)가 새로운 IP 주소에 대한 정보를 포함할 필요가 없다. 따라서 하트비트(300,400)는 통상의 일반적 하트비트와 같이 소정의 헤더와 페이로드로 구성된 하트비트를 서버(200)로 전송하면 된다. 즉 이 경우 주소정보 페이로드(321,422)에 데이터가 존재하지 않고 주소정보 플래그(311,412)는 주소정보 페이로드(321,422)에 데이터가 없음을 나타내는 비트값(예컨대 '0')을 가진다.

만일 모바일 노드(100)가 이동함에 따라 새로운 IP 주소를 할당받은 경우, IP 주소가 변경되었으므로 모바일 노드(100)는 이 변경 사실을 하트비트(300,400)를 이용하여 서버(200)에 알린다. 즉 주소정보 플래그(311,412)에 예컨대 '1'의 비트값을 넣음으로써 주소정보 페이로드(321,422)에 주소정보가 존재함을 표시하고, 주소정보 페이로드(321,422)에는 새로 할당받은 IP 주소를 포함시킬 수 있다. 이러한 주소정보를 포함한 하트비트를 수신받은 서버(200)는 모바일 노드(100)의 주소 변경 여부를 알 수 있고, 이에 따라 모바일 노드(100)가 이동하더라도 모바일 노드와의 연결(세션)을 지속적으로 유지할 수 있다.

실시 형태에 따라, 상기 새로 할당받은 IP 주소는 이 주소를 할당받은 직후의 첫번째 하트비트에만 포함될 수도 있고, 주소를 할당받은 직후 소정 횟수나 소정 시간 동안 전송되는 하트비트들에 포함될 수도 있다.

또한 모바일 노드(100)는 하트비트를 미리 설정된 주기마다 서버(200)로 전송하는 것이 바람직하다. 대안적인 실시예에서, 모바일 노드(100)가 기본적으로 하트비트를 주기마다 전송하되, 소정 이벤트가 발생하면 상기 주기에 상관없이 이 이벤트 발생시 즉시 하트비트를 전송하고, 이 때로부터 상기 소정 주기를 카운트하여 이 주기마다 하트비트를 전송할 수도 있다.

구체적 일 실시예에서 상기 이벤트는 모바일 노드(100)의 이동에 의해 새로운 IP 주소를 할당받는 것일 수 있고, 이에 따라, 모바일 노드(100)가 새로운 주소를 할당받은 즉시 하트비트를 서버(200)로 전송하고 이 전송시점부터 상기 주기 간격으로 하트비트를 전송할 수 있다.

도3은 예시적 일 실시예에 따른 클라이언트-서버간 연결을 유지하는 장치를 설명하기 위한 블록도이다.

도3을 참조하면, 모바일 노드(100)는 애플리케이션(110), 저장부(120), 및 통신부(130)를 포함한다.

애플리케이션(110)은 임의의 푸쉬 서비스를 서버(200)로부터 제공받아 사용자에게 디스플레이 하기 위한 애플리케이션이다. 바람직한 실시예에서 애플리케이션(110)은 모바일 노드(100)의 IP 주소를 모니터링하고 IP 주소가 변경되면 이 변경된 정보를 서버(200)에 전송하는 기능을 더 포함할 수 있다.

그리고 실시 형태에 따라 모바일 노드(100)가 복수개의 IP 주소를 할당받을 수 있는데, 이 경우 애플리케이션(110)은 새로운 사용가능한 주소를 추가로 할당받거나 기존의 주소를 삭제할 수 있고, 이 때 이러한 주소의 추가 및/또는 삭제에 대한 주소 변경 정보를 서버(200)에 전송하는 기능도 더 포함할 수 있다.

도시된 일 실시예에서 애플리케이션(110)은 하트비트 생성부(111)를 포함할 수 있다. 하트비트 생성부(111)는 도2a 또는 도2b에 도시된 바와 같은 하트비트(300,400)를 생성할 수 있다. 대안적인 실시예에서 애플리케이션(110)과 하트비트 생성부(111)가 모바일 노드(100) 내에 별개로 존재하는 소프트웨어 및/또는 하드웨어일 수 있고 따라서 각기 별개로 실행될 수도 있다.

저장부(120)는 하드디스크 드라이브(HDD)나 플래시 메모리 등의 비휘발성 메모리이다. 일 실시예에서 저장부(120)는 애플리케이션(110)의 실행파일을 저장하고 있을 수 있다.

저장부(120)는 모바일 노드(100)의 IP 주소를 저장할 수 있다. 이 때 저장부(120)는 모바일 노드(100)의 이동에 의해 새로운 IP 주소를 할당받을 때마다 IP 주소를 업데이트하여 저장한다. 또한 대안적인 실시예에서 저장부(120)는 모바일 노드(100)의 인증 정보를 추가로 저장할 수 있다.

통신부(130)는 서버(200)와 통신하기 위해 데이터를 송수신하는 기능부이다. 통신부(130)는 하트비트(300,400)를 하트비트 생성부(111)로부터 전달받아 서버(200)로 송신할 수 있고, 서버(200)로부터 푸쉬 서비스 관련 데이터를 수신하여 애플리케이션(110)으로 전달할 수 있다.

도시된 일 실시예에서 서버(200)는 애플리케이션(210), 인증부(220), 저장부(230), 및 통신부(240)를 포함한다.

애플리케이션(210)은 임의의 푸쉬 서비스를 다수의 모바일 노드(100)에 제공하기 위한 애플리케이션이다.

바람직한 실시예에서 애플리케이션(210)은 모바일 노드(100)별로 IP 주소를 관리하고 주소의 변경이 있는 경우 기존 세션 생성시의 주소를 새로운 주소로 변경하는 기능을 포함할 수 있다.

또한 대안적인 실시예에서 애플리케이션(210)은 하나의 모바일 노드(100)에 대해 복수개의 IP 주소값을 지원할 수도 있다. 즉 하나의 모바일 노드에 대해 복수개의 주소값을 저장부(230)에 저장하고 관리할 수 있고, 임의의 패킷이 해당 복수개의 주소 중 어느 주소로 전송되어 오더라도 동일 모바일 노드에서 전송된 것임을 확인하고 세션을 계속 유지할 수 있도록 한다.

인증부(220)는 모바일 노드(100)에서 전송된 하트비트(400)에 인증 정보가 포함되어 있을 경우 이 인증 정보로부터 상기 모바일 노드(100)를 인증하는 기능부이다. 이를 위해 인증부(220)는 각 모바일 노드별로 인증 정보를 저장부(230)에 저장하여 관리할 수 있고, 하트비트(400)에 포함된 인증 정보를 수신하면 저장부(230)에 저장된 정보와 비교하여 해당 모바일 노드의 동일성을 인증할 수 있다.

저장부(230)는 각 모바일 노드별로 하나 이상의 주소를 저장하는 저장장치이다. 대안적인 실시예에서 저장부(230)는 각 모바일 노드별로 인증정보를 추가로 저장할 수 있다. 일 실시예에서 저장부(230)는 하드디스크 드라이브(HDD)나 플래시 메모리 등의 비휘발성 메모리로 구현가능하다.

통신부(240)는 모바일 노드(100)와 통신하기 위해 데이터를 송수신하는 기능부이다. 통신부(240)는 모바일 노드(100)로부터 하트비트(300,400)를 수신하여 애플리케이션(210) 및/또는 인증부(220)로 전달할 수 있고, 푸쉬 서비스 관련 데이터를 모바일 노드(100)로 전송할 수 있다.

한편 도3에 도시된 블록도에서 예컨대 애플리케이션(110,210)은 예를 들어 HDD나 플래시 메모리와 같은 비휘발성 저장장치인 저장부(120,230)에 저장되어 있다가 RAM과 같은 주기억장치에 로딩되어 실행되는 소프트웨어로 구현될 수 있다. 또한 통신부(130,240)는 클라이언트-서버 간의 네트워크 통신을 가능하게 하는 소프트웨어 및/또는 하드웨어로 구현될 수 있다.

따라서 당업자는 도시된 블록도가 모바일 노드(100)나 서버(200)의 구성요소들이 하드웨어와 소프트웨어의 구분없이 본 발명을 기능적으로 설명하기 위해 도시되었음을 이해할 것이다. 실시 형태에 따라 각 구성요소는 하드웨어, 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있으며, 당업자는 다양한 방식에 의해 각 구성요소들의 기능을 수행하는 소프트웨어 및/또는 하드웨어를 구현할 수 있고 본 발명적 개념은 이러한 구체적 구현 방식에 제한되지 않음을 이해할 것이다.

이하에서 도4 내지 도6을 참조하여 클라이언트-서버간 연결을 유지하는 예시적인 방법을 설명하기로 한다.

도4는 제1 실시예에 따라 클라이언트-서버간 연결을 유지하는 방법을 나타내는 흐름도로서, 푸쉬 서비스를 제공하는 서버(200)측의 동작을 나타낸다.

도4를 참조하면, 단계(S401)에서 서버(200)가 푸쉬 서비스를 제공받는 클라이언트, 즉 모바일 노드(100)와 연결되어 세션이 생성된 후 단계(S402)에서 세션이 계속 유지되고 있다. 이 상태에서 모바일 노드(100)는 서버(200)에 소정 주기마다 하트비트를 전송한다. 하트비트는 예컨대 도2a에 도시한 구성을 갖는 하트비트(300)일 수 있다.

세션이 유지되는 동안 단계(S403)에서 서버(200)는 하트비트를 수신할 때마다 해당 하트비트가 미리 설정된 소정 주기 내에 수신되었는지를 판단한다. 하트비트를 수신받지 못했거나 하트비트를 수신했더라도 이 소정 주기 내에 수신한 것이 아니라면, 단계(S404)로 진행하여 서버(200)는 상기 모바일 노드(100)와의 세션을 종료하기 위한 작업을 한 뒤 단계(S405)에서 세션을 종료한다.

그러나 만약 단계(S403)에서 상기 소정 주기 내에 하트비트를 수신했다고 판단하면 단계(S406)로 진행하고, 단계(S406)에서 서버(200)는 하트비트 내에 주소정보가 포함되어 있는지 판단한다. 이 때 만일 도2a에 도시한 구성의 하트비트(300)를 수신받았다고 가정하면, 서버(200)는 우선 헤더(310)의 주소정보 플래그(311)를 확인할 수 있고, 이 주소정보 플래그(311)의 값에 따라 주소정보 페이로드(321)에 주소정보가 있는지 여부를 확인할 수 있다.

만일 단계(S406)의 판단결과 하트비트 내에 주소정보가 포함되어 있지 않다면 단계(S408)로 진행하여 주기 시간을 초기화할 수 있다. 즉 상기 하트비트를 수신한 시점에서 상기 소정 주기 시간을 카운트하도록 초기화한다. 그 후 단계(S402)로 다시 진행하여 다음 하트비트를 수신할 때까지 세션을 계속 유지한다. 그러나 대안적인 실시예에서, 단계(S406)에서 주소정보가 포함되지 않았다고 판단하면, 주기시간을 초기화하는 단계(S408)를 거치지 않고 바로 그 다음 하트비트를 기다리며 세션을 유지하는 단계(S402)로 바로 진행할 수도 있다.

만일 단계(S406)에서 주소정보가 포함되어 있다고 판단하면, 서버(200)는 하트비트의 주소정보 페이로드(321) 영역을 판독하여 모바일 노드(100)의 주소의 변경, 추가, 삭제 여부를 확인하고, 주소의 변경, 추가, 또는 삭제 중 하나 이상이 발생하였다면 주소정보를 업데이트한다. 즉 만일 현재 세션의 유지에 적용된 모바일 노드의 주소가 모바일 노드의 이동으로 인해 새로운 주소로 변경되었다면, 기존 주소값을 이 새로운 주소값으로 변경하여 세션을 계속 유지시킨다. 그리고 이 변경된 주소를 서버(200) 내의 저장부(230)에 저장할 수 있다.

그 후 단계(S408)로 진행하여 주기시간을 초기화하고 단계(S402)로 다시 진행하여 그 다음 하트비트를 수신할 때까지 세션을 유지한다. 이 때에도, 대안적인 실시예의 경우 주기시간의 초기화 단계(S408)를 거치지 않고 바로 단계(S402)로 진행할 수 있음은 물론이다.

또한 다른 대안적인 실시예에서, 모바일 노드(100)가 복수개의 IP 주소를 할당받은 상황에서 새로운 사용가능한 주소를 추가로 할당받거나 기존의 주소를 삭제하는 상황도 발생할 수 있다. 이 경우 하트비트는 주소의 추가 및/또는 삭제에 대한 주소정보를 포함할 수 있고, 서버(200)는 단계(S407)에서, 세션 유지를 위한 주소 변경은 하지 않고 단지 저장부(230) 내에 해당 모바일 노드(100)의 주소에 대해 추가 및/또는 삭제의 업데이트만을 행하면 된다.

도5는 제2 실시예에 따라 클라이언트-서버간 연결을 유지하는 방법을 나타내는 흐름도로서, 푸쉬 서비스를 제공하는 서버(200)측의 동작을 나타낸다.

도5의 흐름도는 도4와 유사하고 다만 모바일 노드(100)가 새로운 주소를 추가로 할당받은 경우 미리 설정된 소정 주기 시간을 증가시키기 위한 단계들을 더 포함하는 점에서 도4와 상이하다.

도5에서 단계(S401~S403, S406~S408)는 도4의 각 대응하는 단계들과 동일 또는 유사한 절차를 수행하므로 설명을 생략한다.

도5를 참조하면, 단계(S403)에서 소정 주기 내에 하트비트를 수신하지 못하였다고 판단하면 단계(S411)로 진행한다. 이 단계(S411)에서 서버(200)는 모바일 노드(100)에 할당된 추가 주소가 있는지 여부를 판단한다. 이 판단을 위한 구체적 예로서, 예컨대 서버(200)는 하트비트 내에 주소정보 플래그(311) 및 주소정보 페이로드(321)를 판독하여 추가 주소가 있는지 여부를 알 수 있다.

단계(S411)에서, 만일 플래그(311)로부터 주소정보가 없다는 것을 확인했거나, 플래그(311)가 주소정보가 있다고 표시되어 있지만 페이로드(321)가 주소 추가에 관한 정보를 포함하고 있지 않다면, 단계(S414)로 진행하여 서버(200)는 모바일 노드와의 세션을 종료하기 위한 작업을 한 뒤 단계(S415)에서 세션을 종료한다.

만일 단계(S411)에서 페이로드(321)에 주소 추가에 관한 정보가 있음을 확인했다면, 단계(S412)로 진행하여 주기 시간을 증가한다. 즉 주기 시간 경과로 인해 타임아웃이 되는 시간을 증가시킨다.

그 후 단계(S413)에서 이 증가된 시간이 반영된 새로운 주기 시간 내에 하트비트가 수신되는지를 판단하고, 만일 이 증가된 주기 내에도 하트비트를 수신하지 못하였다면 단계(S414)로 진행하여 세션을 종료하기 위한 작업을 하고 단계(S415)에서 세션을 종료하고, 만일 증가된 주기 내에 하트비트를 수신하였다면 단계(S402)로 진행할 수 있다.

실시 형태에 따라, 주소 추가가 있는 경우 주기를 증가시키는 상술한 방법으로부터 흐름도를 변형하여 다양한 대안적 실시예를 구현할 수 있다. 예컨대 대안적인 실시예에서, 주소 추가시 주기를 증가시키기 위한 단계(S411 내지 S415)는 단계(S403)가 아닌 다른 단계 이후에 진행되도록 도5의 흐름도를 변형할 수 있다. 예를 들어 주기를 증가시키기 위한 단계(S411 내지 S415)가 주소정보 업데이트 단계(S407) 이후에 진행되도록 설정할 수도 있다.

이제 도6을 참조하여 도4 또는 도5에서의 단계(S403)에 대해 설명하기로 한다.

도6은 주기 내에 하트비트를 수신하였는지 판단하는 단계(S403)를 실행하는 예시적 방법을 나타내는 흐름도로서, 하드 핸드오버 상황에서와 같이 인증절차가 필요한 경우 단계(S403)의 동작을 예시하고 있다.

예를 들어 하드 핸드오버의 상황에서는 이동 후 할당받은 주소가 모바일 노드의 소스 IP 주소로 설정되어 하트비트가 서버(200)로 전송된다. 따라서 서버(200)는, 모바일 노드의 이동 전후로 다른 IP 주소로부터 하트비트가 서버(200)로 전송되었다 하더라도 서버(200)는 이 하트비트들이 동일 모바일 노드에서 온 것임을 알 수 있어야 하고, 일 실시예에 따르면, 이러한 동일성 확인 절차는 소정 주기 내에 하트비트가 수신되었는지 판단하는 단계(도4 또는 도5의 S403)에서 수행될 수 있다.

도6을 참조하면, 우선 단계(S601)에서 서버(200)가 하트비트를 수신한다. 이 때의 하트비트는 예컨대 도2b에 도시한 하트비트(400)일 수 있다.

그 후 서버(200)는 단계(S602)에서 하트비트의 IP 주소가 서버(200)에 등록된 주소 내에 있는지를 판단한다. 예를 들어, 서버(200)가 하트비트의 IP 헤더를 판독하여 하트비트의 소스 IP를 알 수 있고, 이 소스 IP가 해당 모바일 노드(100)에 대해 서버(200)에 등록된 복수개의 주소 중 하나인지 여부를 확인함으로써 단계(S602)를 수행할 수 있다.

단계(S602)의 판단결과 하트비트의 IP 주소가 등록 주소 내에 있다고 판단되면, 이것은 단계(S403)에서 서버(200)가 해당 모바일 노드로부터 소정 주기 내에 하트비트를 수신한 것이 된다.

만일 단계(S602)의 판단결과 하트비트의 IP 주소가 등록 주소 내에 없다고 하면, 단계(S603)로 진행하여 서버(200)가 하트비트(400)의 헤더 부분의 인증정보 플래그(411)를 판독하여 인증정보가 있는지 여부를 판단할 수 있다. 만일 플래그(411)가 인증정보가 없음을 나타내면, 이것은 단계(S403)에서 해당 모바일 노드로부터 소정 주기 내에 하트비트를 수신하지 못한 것을 의미한다.

만일 단계(S603)에서 플래그(411)의 판독 결과 인증정보가 있다고 판단되면 단계(S604)로 진행하여 인증 작업을 수행한다. 일 실시예에서 서버(200)는 페이로드(420)의 인증정보 페이로드(421)에서 인증 정보를 판독하여 저장부(230)에 저장된 인증정보와 비교함으로써 인증 작업을 수행할 수 있다.

단계(S604)의 인증 결과 만약 인증에 통과하면, 이것은 모바일 노드의 이동 전후로 모바일 노드의 동일성을 확인한 것이 되므로, 단계(S403)에서 해당 모바일 노드로부터 소정 주기 내에 하트비트를 수신한 것을 의미한다. 그러나 만약 인증에 통과하지 못하였다면 모바일 노드의 동일성이 없는 것이므로, 이것은 단계(S403)에서 해당 모바일 노드로부터 소정 주기 내에 하트비트를 수신하지 못한 것을 의미한다.

이상과 같이 도4 또는 도5의 단계(S403)를 구현하는 예시적인 방법을 도6을 참조하여 설명하였으나 이것은 일 예시에 불과하고 다른 다양한 방법으로 상기 단계를 구현할 수 있음을 당업자는 이해할 것이다.

이상 설명한 본 발명에 따른 실시예들은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 또한 컴퓨터가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다.

상기와 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다. 그러므로, 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

100: 모바일 노드 110: 애플리케이션
120: 저장부 130: 통신부
200: 서버 210: 애플리케이션
220: 인증부 230: 저장부
240: 통신부 300,400: 하트비트

Claims

연결 지속형 서비스에서 주기적 전송 패킷을 이용한 클라이언트-서버간 연결 유지 방법에 있어서, 상기 서버가,
세션을 유지하고 있는 클라이언트로부터 소정 주기 내에 주기적 전송 패킷을 수신하였는지 판단하는 단계;
상기 주기적 전송 패킷을 수신하였다면, 상기 주기적 전송 패킷에서 상기 클라이언트가 새로운 주소를 할당 받았는지 확인하는 단계; 및
상기 새로운 주소를 할당 받았으면, 기존 주소를 상기 새로운 주소로 변경하여 상기 세션을 유지하는 단계;를 포함하며,
상기 주기적 전송 패킷은, 상기 클라이언트의 주소정보를 포함하는 주소정보 페이로드를 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 세션 유지하는 단계는, 변경된 주소를 저장부에 저장하여 업데이트하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 주기적 전송 패킷은 헤더를 더 포함하고,
상기 헤더는 상기 주소정보 페이로드에 데이터가 존재하는지 여부를 표시하는 주소정보 플래그를 포함하는 것을 특징으로 하는 방법.
제 3 항에 있어서, 상기 클라이언트가 새로운 주소를 할당 받았는지 확인하는 단계는,
상기 주소정보 플래그를 확인하는 단계; 및
상기 주소정보 플래그의 값에 따라, 상기 주소정보 페이로드를 확인하는 단계;를 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서,
상기 세션을 유지하는 단계 이후에, 상기 주기적 전송 패킷을 수신한 시점에서 상기 소정 주기를 카운트하도록 초기화하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 단계들이 연결 지속형 서비스를 제공하는 응용계층에서 수행되는 것을 특징으로 하는 방법.
제 1 항에 있어서, 상기 소정 주기 내에 주기적 전송 패킷을 수신하였는지 판단하는 단계 이후에,
클라이언트에 할당된 주소의 추가가 있는지 판단하는 단계; 및
주소 추가가 있다면, 상기 소정 주기의 시간을 증가하는 단계;를 포함하는 것을 특징으로 하는 방법.
제 7 항에 있어서, 상기 소정 주기의 시간을 증가하는 단계 이후에, 증가된 주기 내에 주기적 전송 패킷이 수신되었는지 판단하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 3 항에 있어서,
상기 페이로드가 상기 클라이언트의 인증정보를 포함하는 인증정보 페이로드를 더 포함하고, 상기 헤더는 상기 인증정보 페이로드에 데이터가 존재하는지 여부를 표시하는 인증정보 플래그를 더 포함하는 것을 특징으로 하는 방법.
제 9 항에 있어서, 상기 소정 주기 내에 주기적 전송 패킷을 수신하였는지 판단하는 단계는,
상기 주기적 전송 패킷의 소스 IP 주소가 상기 서버에 등록된 주소인지 판단하는 단계;
상기 소스 IP 주소가 상기 서버에 등록된 주소가 아닌 경우, 상기 주기적 전송 패킷에서 상기 클라이언트의 인증정보가 있는지 확인하는 단계; 및
상기 인증정보가 있다면, 상기 클라이언트에 대한 인증 작업을 수행하는 단계;를 포함하는 것을 특징으로 하는 방법.
클라이언트에게 연결 지속형 서비스를 제공하고 상기 클라이언트로부터 소정 주기마다 주기적 전송 패킷을 수신하는 서버 장치에 있어서,
하나 이상의 클라이언트에게 연결 지속형 서비스를 제공하는 애플리케이션부;
상기 클라이언트의 IP 주소를 저장하는 저장부; 및
상기 클라이언트와 통신하기 위해 데이터를 송수신하는 통신부;를 포함하고,
상기 애플리케이션부가, 상기 클라이언트로부터 수신한 주기적 전송 패킷으로부터 상기 클라이언트가 새로운 주소를 할당 받았는지 여부를 확인하고, 클라이언트가 새로운 주소를 할당 받았으면, 상기 클라이언트와의 연결(세션)에 사용된 기존 주소를 상기 새로운 주소로 변경하여 상기 세션을 유지하며,
상기 주기적 전송 패킷은, 상기 클라이언트의 주소정보를 포함하는 주소정보 페이로드를 포함하는 것을 특징으로 하는 서버 장치.
제 11 항에 있어서,
상기 주기적 전송 패킷은 헤더를 더 포함하고,
상기 헤더는 상기 주소정보 페이로드에 데이터가 존재하는지 여부를 표시하는 주소정보 플래그를 포함하는 것을 특징으로 하는 서버 장치.
제 12 항에 있어서,
상기 서버 장치가, 상기 주소정보 플래그를 확인하고 이 주소정보 플래그의 값에 따라 상기 주소정보 페이로드에서 클라이언트의 주소를 판독하는 것을 특징으로 하는 서버 장치.
제 12 항에 있어서,
상기 페이로드가 상기 클라이언트의 인증정보를 포함하는 인증정보 페이로드를 더 포함하고, 상기 헤더는 상기 인증정보 페이로드에 데이터가 존재하는지 여부를 표시하는 인증정보 플래그를 더 포함하는 것을 특징으로 하는 서버 장치.
제 14 항에 있어서,
상기 주기적 전송 패킷에 포함된 인증정보로부터 클라이언트를 인증하는 인증부를 더 포함하는 것을 특징으로 하는 서버 장치.
제 11 항에 있어서,
상기 서버 장치가, 클라이언트에 할당된 주소의 추가가 있는 경우, 상기 소정 주기의 시간을 증가하는 것을 특징으로 하는 서버 장치.
제 1 항 내지 제 10 항 중 어느 한 항에 기재된 방법을 컴퓨터에서 실행시키기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록매체.