KR20060007732A

KR20060007732A - 소켓 연결 관리 시스템 및 그 소켓 연결 상태 체크 방법

Info

Publication number: KR20060007732A
Application number: KR1020040056963A
Authority: KR
Inventors: 백승학
Original assignee: 삼성전자주식회사
Priority date: 2004-07-21
Filing date: 2004-07-21
Publication date: 2006-01-26
Also published as: EP1619855B1; EP1619855A1; US20060020705A1; CN1725757A; JP2006031685A; KR100560752B1

Abstract

본 발명은 서버 또는 클라이언트의 통신을 위해 필요한 소켓을 생성하고, 해당 소켓의 연결상태를 체크하기 위해 정의된 API(Application Programmable Interface)를 호출하여 그 생성된 소켓을 관리하는 적어도 하나 이상의 응용 프로그램 모듈과, 응용 프로그램 모듈로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈과, 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성되어 응용 프로그램 모듈에 의해 생성된 소켓의 연결상태를 주기적으로 체크하는 소켓체크 실행모듈을 포함하는 소켓 관리 시스템을 제공한다.

본 발명에 의하면, TCP와 같은 연결지향 프로토콜의 구현에서 기본적으로 제공하지 못하는 부분인 연결상태 체크, 상대의 전원 오프시 연결해제 및 재연결 기능을 공통 라이브러리 형태로 구현하여 여러 응용 프로그램들이 하나의 모듈의 인터페이스 함수만을 이용하여 해당 기능을 제공받을 수 있다.

소켓, 헬스 체크, 서버, 클라이언트, 호출, 라이브러리 함수

Description

소켓 연결 관리 시스템 및 그 소켓 연결 상태 체크 방법{SYSTEM FOR MANAGING SOCKET CONNECTION AND METHOD FOR CHECKING OF SOCKET CONNECTION STATE}

도 1은 종래의 연결 지향 소켓 이용시의 오류를 나타내는 흐름도.

도 2는 본 발명의 일실시예에 따른 소켓 관리 시스템을 적용하는 서버 - 클라이언트의 구성도.

도 3은 본 발명의 일실시예에 따른 서버에 동작하는 소켓 관리 시스템의 구성도.

도 4는 본 발명의 일실시예에 따른 클라이언트에서 동작하는 소켓 관리 시스템의 구성도.

도 5는 본 발명의 일실시예에 따른 소켓 연결 상태 체크를 위한 메시지(HC 메시지)의 구성도.

도 6은 클라이언트의 상태도.

도 7은 본 발명의 일실시예에 따른 소켓 관리 시스템을 적용하여 서버에서 소켓을 관리하는 흐름도.

도 8은 본 발명의 일실시예에 의한 서버에서 소켓 체크 모듈의 동작 흐름도.

도 9는 본 발명의 일실시예에 따른 서버의 소켓 체크 모듈이 등록된 소켓의 연결상태를 주기적으로 체크하는 상세한 동작 흐름도.

도 10은 본 발명에 따른 클라이언트의 소켓 체크 모듈이 소켓의 체크시 수행하는 동작 흐름도.

도 11은 본 발명의 일실시예에 따른 서버와 클라이언트간의 헬스 체크 메시지의 전송 흐름도.

도 12는 본 발명에 의한 헬스 체크 메시지를 이용한 클라이언트 장애 발견 및 처리 흐름도.

도 13은 본 발명에 의한 헬스 체크 메시지를 이용한 서버의 장애 발견 및 처리 흐름도.

본 발명은 서버와 클라이언트간의 소켓 관리에 관한 것으로, 상세하게는 BSD, 유닉스(Unix), 리눅스(Linux) 계열의 운용체제를 가지는 서버 혹은 장비들간의 연결상태를 관리하고 연결의 비정상적 문제 발생시 연결을 끊거나 재연결하는 소켓 연결 관리 시스템 및 소켓 연결 상태 체크 방법에 관한 것이다.

BSD, 유닉스, 리눅스 계열의 운용체제(Operating System)를 가지는 서버 또는 장비에는 여러 가지 응용프로그램들이 실행된다. 이러한 응용프로그램들이 서로 통신을 수행할 때는 TCP(Transmission Control Protocol)와 같은 연결지향 규약을 사용하는 경우가 많다. TCP는 신뢰성 있고, 전-이중, 연속 바이트를 제공하는 연결 지향 규약으로 전송되는 데이터의 신뢰성을 위해 기본적으로 에러체크 및 재전송, 흐름 제어 기능을 제공하여 준다. 따라서 서버 또는 장비에서 실행되는 응용프로그램들은 TCP 규약에 따라 연결상태를 알 수 있고 이를 이용하여 서로간의 주요 메시지를 주고받는다.

대부분의 운용체제는 연결지향 규약을 위한 인터페이스로 소켓(socket)을 사용하고 있으며 각각의 응용프로그램들은 각자 연결에 필요한 소켓들을 관리한다.

종래의 연결지향 소켓의 구현방식은 정상적인 상태에서 서버와 클라이언트간의 연결 혹은 해제가 가능하고, 상대의 상태가 끊어지면 해제할 수 있도록 되어 있다. 그러나, 서버쪽이든 클라이언트쪽이든 상대의 전원이 끊어지거나 탈/실장 가능한 슬롯으로 구성된 장비에서 연결 상대가 탈장이 되는 상황에서는 연결 소켓이 즉시 해제가 되지 않고 상당시간 그 연결 소켓을 유지하게 된다. 더욱이 소켓이 계속적으로 유지되고 있는 상태로 알고 있으므로 내부적으로 정보를 주고받는 것도 가능하다고 판단하여 오동작의 원인이 될 수 있다. 특히, 실시간 시스템인 경우에는 더욱 문제점이 된다.

또한, 연결 해제가 안되는 경우 뿐 아니라 서버-클라이언트 사이의 어떤 모듈의 오동작으로 인하여 서버와 클라이언트간의 연결이 끊어진 상태에서는 기설정된 소켓을 해제하고 재연결을 해야 하는데 상황을 인지하지 못하면 오동작상태를 계속 유지하고 있게 되는 오류가 발생한다.

도 1은 종래의 연결 지향 소켓 이용시의 오류를 나타내는 흐름도이다.

도 1을 참조하면 서버(1)는 제 1 클라이언트(2) 및 제 2 클라이언트(3)와 소켓을 생성하여 통신을 수행하다가 제 2 클라이언트(3)에 전력 장애가 발생했음에도 불구하고 이를 인지하지 못하여 계속적으로 제 2 클라이언트(3)에 데이터를 전송함으로써 데이터 전송의 오류를 초래하고 있다.

한편, 표준 소켓 옵션 중에 'KEEPALIVE'라는 연결 관리를 수행하는 것이 있지만, 일반적으로 2시간(7200초)을 기본값으로 가지며 중간에 어떠한 메시지의 교류가 없는 단순한 방식이어서 빠른 연결복구가 불가능하다.

따라서, 대부분의 응용 프로그램에서는 이러한 경우의 처리를 위해 따로 각 응용 프로그램마다 특정한 방식을 이용하여 체크를 해주어야만 하는데 이렇게 되면 응용 프로그램마다 개별적인 연결 관리 방식을 가져야만 하므로 유사한 기능들을 여러 응용 프로그램들에 모두 구현해야 하는 매우 불필요한 작업들이 중복된다.

또한, 각 연결관리가 일괄적으로 되지 못하므로 실제 서버와 클라이언트간의 연결 문제인지 단순히 해당 응용프로그램간의 동작 문제인지 인식할 수 없어 시스템 관리가 어렵고 복잡해지는 문제점이 있다.

본 발명은 이러한 종래의 문제점을 해결하기 위하여 안출된 것으로, 서버- 클라이언트상에 구동되는 많은 응용 프로그램 모듈들이 소켓의 연결을 관리하는 관리를 수행해야 하는 불필요한 작업을 줄일 수 있는 소켓 연결 관리 시스템 및 소 켓 연결 상태 체크 방법을 제공하는데 그 목적이 있다.

이러한 목적을 달성하기 위한 본 발명의 일측면에 의하면, 서버 또는 클라이언트의 통신을 위해 필요한 소켓을 생성하고, 해당 소켓의 연결상태를 체크하기 위해 정의된 API(Application Programmable Interface)를 호출하여 그 생성된 소켓을 관리하는 적어도 하나 이상의 응용 프로그램 모듈과, 응용 프로그램 모듈로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈과, 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성되어 응용 프로그램 모듈에 의해 생성된 소켓의 연결상태를 주기적으로 체크하는 소켓 체크 실행모듈을 포함하는 소켓 관리 시스템을 제공한다.

또한 본 발명의 다른 측면에 의하면, 서버 또는 클라이언트의 통신을 위해 필요한 소켓을 생성하고 관리하도록 프로그래밍된 응용 프로그램 모듈이 구동되어 임의의 소켓을 생성하는 단계와, 응용 프로그램 모듈이 그 생성된 소켓의 연결상태를 체크하기 위해 정의된 임의의 API(Application Programmable Interface)를 호출하는 단계와, 응용 프로그램 모듈로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈에서 해당 프로그램이 실행되는 단계와, 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성된 소켓 체크 모듈에 의해 응용 프로그램 모듈에 의해 생성된 소켓의 연결상태를 주기적으로 체크하는 단계를 포함하는 소켓 연결 상태 체크 방법을 제공 한다.

또한 본 발명의 다른 측면에 의하면, 임의의 클라이언트와 소켓을 설정하는 서버에서 설정된 소켓의 연결상태를 체크하는 방법에 있어서, 클라이언트와 소켓을 설정할 때 해당 소켓의 연결 상태를 체크하기 위한 프로그램이 저장된 라이브러리 함수를 호출하는 단계와, 호출된 라이브러리 함수의 실행에 의하여 주기적으로 체크할 소켓을 등록하는 단계와, 상기 호출된 라이브러리 함수의 실행에 의해 주기적으로 상기 클라이언트에 주기적으로 소켓 체크 요청 메시지를 전송하여 해당 클라이언트로부터 전송되는 소켓 체크 응답메시지의 수신 여부에 따라 등록된 소켓의 연결 상태를 주기적으로 체크하는 단계를 수행하는 소켓 연결 상태 체크 방법을 제공한다.

본 발명의 다른 측면에 의하면, 임의의 서버와 소켓을 설정하고 있는 클라이언트에서 해당 소켓의 연결상태를 체크하는 방법에 있어서, 서버와 소켓을 설정할 때 해당 소켓의 연결 상태를 체크하기 위한 프로그램이 저장된 라이브러리 함수를 호출하는 단계와, 호출된 라이브러리 함수의 실행에 의해 서버로부터 주기적으로 수신되는 소켓 체크 요청 메시지에 대하여 소켓 체크 응답메시지를 전송하고, 소켓 체크 요청 메시지가 주기적으로 수신되는지 여부에 따라 서버와 설정된 소켓의 연결 상태를 체크하는 단계를 수행하는 소켓 연결 상태 체크 방법을 제공한다.

도 2는 본 발명의 일실시예에 따른 소켓 관리 시스템을 적용하는 서버 - 클라이언트의 구성도이다.

도 2를 참조하면 서버(100)와 다수의 클라이언트(200, 300, 400, 500)들이 네트워크를 통해 연결되어 있다. 서버(1)에 구동되고 있는 서버 응용 프로그램 모듈과 각 클라이언트(200, 300, 400, 500)에 구동되고 있는 클라이언트 응용 프로그램 모듈들은 소켓통신을 연결되어 있다.

서버(100)에 구동되고 있는 서버 응용 프로그램 모듈은 각 클라이언트(200, 300, 400, 500)에 구동되고 있는 클라이언트 응용 프로그램 모듈과 통신을 위해 필요한 소켓을 설정하고 그 설정된 소켓의 연결 상태를 주기적으로 체크한다.

여기에서, 서버(100) 또는 각 클라이언트(200, 300, 400, 500)에서 실행되는 각 응용 프로그램 모듈들은 해당 응용 프로그램 모듈에 프로그래밍된 절차를 수행하여 다양한 서비스를 제공한다. 이에 따라 응용 프로그램 모듈은 서버(100) 또는 각 클라이언트(200, 300, 400, 500)에서 제공하는 서비스의 종류에 따라 다양한 형태로 구현될 수 있을 것이다.

아울러, 응용 프로그램 모듈은 서버-클라이언트 기반의 통신 프로토콜을 가지고 다양한 디지털 처리장치에서 운용되는 다양한 종류의 소프트웨어 응용 프로그램 모듈을 포함할 수 있다.

또한, 응용 프로그램 모듈은 서버-클라이언트 기반의 통신 프로토콜을 가지고 운용됨에 따라 서버(100) 또는 각 각 클라이언트(200, 300, 400, 500)에서 실행되는 경우 서버(100)와 각 클라이언트(200, 300, 400, 500)에 구동되고 있는 응용 프로그램 모듈간의 통신을 위해 소켓을 생성하고, 통신이 완료된 후에는 생성된 소켓 연결을 해제하는 일련의 동작을 수행한다.

각 응용 프로그램 모듈들은 서버(100)와 각 클라이언트(200, 300, 400, 500) 간에 설정한 소켓의 연결상태를 실시간으로 파악할 필요가 있다. 이를 위해 응용 프로그램 모듈은 소켓의 연결상태를 체크하기 위해 정의된 API를 호출하여 그 API에 의해 생성된 소켓 체크 실행 모듈에 의해 소켓 체크 작업을 수행하게 한다.

여기에서, 각 응용 프로그램 모듈들은 임의의 클라이언트와의 통신을 위해 소켓을 생성하고, 그 생성된 소켓을 유지하거나 해제하는 절차에 대하여는 일반적인 기술을 준용한다. 이에 따라 이하의 도면과 설명에서는 설정된 임의의 소켓을 체크하기 위해 API를 호출하여 그 API에 의해 생성된 소켓 체크 실행 모듈에 의해 소켓 체크 작업을 수행하는 구성과 동작에 대하여 상세하게 설명하도록 한다.

본 발명에서는 서버(100)와 각 클라이언트(200, 300, 400, 500)에서 구동되고 있는 응용 프로그램 모듈들이 상호간에 설정된 소켓의 연결상태를 체크하기 위한 API를 정의하고, 각 응용 프로그램 모듈에서는 그 API를 호출하여 각 소켓들에 대한 연결상태를 주기적으로 체크하게 한다.

이에 따라 소켓의 연결상태를 체크하는 기능을 제공하기 위한 API들은 서버(100)와 클라이언트(200, 300, 400, 500)에서 각각 사용 호출가능하도록 이원화 되어 있다. 이하에서는 API의 소켓 연결 상태 체크 기능을 Health-Check로 명명하며 약자로 HC (또는 hc)를 사용한다. 이에 따라 소켓 연결 상태의 체크를 위한 모든 API는 'hc_'로 시작된다.

서버와 클라이언트는 매주기 마다 소켓의 연결 상태를 체크하기 위한 메시지를 주고 받는다. 서버에서는 클라이언트로 매 주기마다 소켓의 연결 상태를 체크하기 위한 헬스 체크 요청 메시지(HC_REQUEST)를 전송하고, 클라이언트는 서버로 헬 스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

도 3은 본 발명의 일실시예에 따른 서버에 동작하는 소켓 관리 시스템의 구성도이다.

도 3을 참조하면 서버에서 구동되는 소켓 관리 시스템은 클라이언트와의 통신을 위해 필요한 소켓을 생성하고, 해당 소켓의 연결상태를 체크하기 위해 정의된 API(Application Programmable Interface)를 호출하여 그 생성된 소켓을 관리하는 적어도 하나 이상의 응용 프로그램 모듈(110)과, 응용 프로그램 모듈(110)로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈(120)과, 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성되어 응용 프로그램 모듈에 의해 생성된 소켓의 연결상태를 주기적으로 체크하는 소켓 체크 실행모듈(130)과, DB(140)를 포함하여 구성된다.

응용 프로그램 모듈(110)에는 소켓의 연결상태를 체크하기 위해 정의된 API들이 인코딩되어 있다. 우선 정의된 API에 대하여 살펴보도록 한다.

서버 초기화 API(hc_server_init)(111)는 HC에서 사용할 HC 기능용 thread를 생성하는 API이다. 서버 초기화 API는 응용 프로그램 시작부분에 추가한다. 이하에서는 HC 기능용 쓰레드(thread)를 소켓 체크 실행 모듈로 명명하도록 한다.

서버 등록 API(hc_server_register)(112)는 헬스 체크(HC)에서 임의의 소켓에 대한 연결 상태를 체크할 수 있도록 소켓을 등록하는 API이다. 서버 등록 API는 응용 프로그램 모듈에서 서버용 소켓을 열고 클라이언트와 연결이 되는 위치에 추가하며 클라이언트와의 연결된 소켓은 등록되어 이후로 상태를 계속 체크하게 된 다.

서버 등록 취소 API(hc_server_unregister)(113)는 HC에서 체크하던 소켓을 등록취소하는 API이다. 서버 등록 취소 API(113)는 정상적인 소켓의 해제시에 응용 프로그램 모듈에서 사용된다. 서버 등록 취소 API(113)는 응용 프로그램 모듈에서 클라이언트와 연결을 해제하는 위치에 코딩된다.

서버 프로세스 API(hc_server_process)(114)는 서버에 실행된 응용 프로그램 모듈에 의해 소켓의 연결상태를 체크하도록 등록된 해당 소켓으로부터 데이터를 전송 받았을 때 해당 데이터가 HC용 데이터인지를 확인하고 처리한다. 서버 프로세스 API는 서버용이므로 소켓 체크 요청 메시지(hc_request)에 대한 응답인 소켓 체크 응답 메시지(hc_response)를 받았을 때의 처리를 위한 것이다.

서버 해제 API(hc_server_exit)(115)는 등록되어 있던 모든 소켓을 등록해제하고 소켓 체크 실행 모듈(130)을 해제하는 API이다.

공통 라이브러리 모듈(120)은 응용 프로그램 모듈(110)로부터 임의의 API가 호출되는 경우 호출된 각 API에 설정된 동작을 수행하기 위한 프로그램이 코딩되어 있다. 그에 따라 공통 라이브러리 모듈(120)은 서버 초기화 API, 서버 등록 API, 서버 등록 취소 API, 서버 프로세스 API, 서버 해제 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 각각의 프로그램들을 구비하고 있다.

즉, 응용 프로그램 모듈(110)로부터 서버 초기화 API(hc_server_init)(111)가 호출되면 서버 초기화 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 HC에서 사용할 소켓 체크 실행 모듈을 생성하여 임의의 소켓 의 연결상태를 주기적으로 체크할 준비를 한다.

응용 프로그램 모듈(110)로부터 서버 등록 API(hc_server_register)(112)가 호출되면 서버 등록 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 헬스 체크(HC)에서 임의의 소켓에 대한 연결 상태를 체크할 수 있도록 소켓을 기생성된 소켓 체크 실행 모듈(130)에 등록한다.

응용 프로그램 모듈(110)로부터 서버 등록 취소 API(113)가 호출되면 서버 등록 취소 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 소켓 체크 실행 모듈(130)에서 체크하던 소켓을 등록 취소한다. 소켓 체크 실행 모듈(130)에서 소켓의 등록을 취소하면 해당 소켓은 해제된다.

응용 프로그램 모듈(110)로부터 서버 프로세스 API(hc_server_process)(114)가 호출되면 서버 프로세스 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 클라이언트로부터 임의의 메시지가 전달되는 경우 해당 메시지가 서버에서 해당 클라이언트로 전송한 헬스 체크 요청 메시지에 대한 헬스 체크 응답 메시지인지의 여부를 확인하고 그에 따라 클라이언트의 상태값을 변동시킨다.

응용 프로그램 모듈(110)로부터 서버 해제 API(hc_server_exit)(115)가 호출되면 서버 해제 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 소켓 체크 실행 모듈(130)에 해당 소켓의 연결상태를 체크하기 위해 등록되어 있던 모든 소켓을 등록해제하고 해당 소켓 체크 실행 모듈(130)을 해제시킨다.

소켓 체크 실행 모듈(130)은 응용 프로그램 모듈(110)로부터 서버 초기화 API를 호출함에 따라 공통 라이브러리 모듈(120)에 서버 초기화 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램이 실행되어 생성된다.

소켓 체크 실행 모듈(130)은 매 주기마다 응용 프로그램 모듈로부터 지정받은 소켓에 대하여 해당 소켓의 연결상태를 체크하기 위하여 헬스 체크 요청 메시지를 전송하고, 그에 따라 클라이언트로부터 헬스 체크 응답 메시지가 수신되는지 여부에 따라 해당 소켓의 연결상태를 체크하게 된다.

DB(140)는 서버(100)와 소켓을 생성하여 통신을 수행하고 있는 각 클라이언트의 ID 및 클라이언트의 상태정보를 저장하고 있다.

도 4는 본 발명의 일실시예에 따른 클라이언트에서 동작하는 소켓 관리 시스템의 구성도이다.

도 4를 참조하면 클라이언트에서 구동되는 소켓 관리 시스템은 소켓의 연결 상태를 체크하는 API를 호출하도록 프로그래밍된 적어도 하나 이상의 응용 프로그램 모듈(210)과, 응용 프로그램 모듈(210)로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈(220)과, 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성되어 응용 프로그램 모듈에 의해 생성된 소켓의 연결상태를 주기적으로 체크하는 소켓 체크 실행모듈(230)과, DB(240)를 포함하여 구성된다.

응용 프로그램 모듈(210)에는 소켓의 연결상태를 체크하기 위해 정의된 API들이 인코딩되어 있다. 클라이언트에서 정의된 API에 대하여 살펴보도록 한다.

클라이언트에는 다음과 같은 종류의 클라이언트 초기화 API(211)와, 클라이언트 프로세스 API(212)와, 클라이언트 해제 API(213)가 정의되어 있다.

클라이언트 초기화 API(hc_client_init)(211)는 HC에서 사용할 변수들을 초기화하는 API이다. 클라이언트 초기화 API(211)는 응용 프로그램 모듈의 구동시 시작 부분에 코딩된다.

클라이언트 프로세스 API(hc_client_process)(212)는 클라이언트에 실행되고 있는 응용 프로그램 모듈이 서버(100)로부터 데이터를 전송받았을 때 해당 데이터가 HC용 데이터인지를 확인하고 처리하는 API이다. 클라이언트에 실행되고 있는 API이므로 서버로부터 요청 메시지(hc_request)를 받았을 때의 처리를 위한 것이다.

클라이언트 해제 API(hc_client_exit)(213)는 필요한 변수들을 초기화하고 HC 동작을 끝내는 API이다.

공통 라이브러리 모듈(220)은 응용 프로그램 모듈(210)로부터 임의의 API가 호출되는 경우 호출된 각 API에 설정된 동작을 수행하기 위한 프로그램이 코딩되어 있다. 그에 따라 공통 라이브러리 모듈(120)은 클라이언트 초기화 API, 클라이언트 프로세스 API, 클라이언트 해제 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 각각의 프로그램들을 구비하고 있다.

즉, 응용 프로그램 모듈(210)로부터 클라이언트 초기화 API(hc_client_init)(211)가 호출되면 클라이언트 초기화 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 소켓 체크를 위한 초기화를 수행하고 소켓 체크 실행 모듈을 생성하여 서버와 설정된 소켓의 연결상태를 주기적으로 체크할 준비를 한다.

응용 프로그램 모듈(210)로부터 클라이언트 프로세스 API가 호출되면 클라이언트 프로세스 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 클라이언트에 실행되고 있는 응용 프로그램 모듈이 서버(100)로부터 메시지를 전송받았을 때 해당 메시지가 헬스 체크 요청 메시지(hc_request)인지 여부를 판단한다.

응용 프로그램 모듈(210)로부터 클라이언트 해제 API가 호출되면 클라이언트 해제 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램을 실행하여 헬스 체크 동작을 해제하고 해당 소켓 체크 실행 모듈(230)을 종료하는 동작을 수행한다.

소켓 체크 실행 모듈(230)은 응용 프로그램 모듈(210)로부터 서버 초기화 API를 호출함에 따라 공통 라이브러리 모듈(220)에 서버 초기화 API에 상응하여 정의된 기능을 수행할 수 있도록 코딩된 프로그램이 실행되어 생성된다.

소켓 체크 실행 모듈(230)은 매 주기마다 응용 프로그램 모듈로부터 지정받은 소켓에 대하여 해당 소켓의 연결상태를 체크하기 위하여 전송되는 헬스 체크 요청 메시지를 수신하면 그에 따라 서버에 헬스 체크 응답 메시지를 전송함으로써 서버에서 헬스 체크 응답 메시지의 수신여부에 따라 해당 소켓의 연결상태를 체크할 수 있도록 한다.

DB(240)는 서버(100)와 설정된 소켓을 유지하기 위한 서버(100)에 대한 소켓 설정 정보를 저장하고 있다.

도 5는 본 발명의 일실시예에 따른 소켓 연결 상태 체크를 위한 메시지(HC 메시지)의 구성도이다.

도 5를 참조하면 헬스 체크 메시지의 헤더에는 매직 넘버 필드(Magic Number)와, 메시지 타입 필드(Message)와, 클라이언트 ID 필드(Client ID)와, 패킷 길이 필드(Length)로 구성되고, 바디에는 타임 스탬프 필드(Timestamp)와, 타임아웃값 필드(TImeot Value)와, 예비필드(Reserved)를 포함하여 구성된다.

매직 넘버 필드와, 메시지 타입 필드와, 클라이언트 ID 필드와, 패킷 길이 필드는 각각 2바이트씩 할당되어 있다.

매직 넘버 필드에 설정되는 값은 소켓의 연결 상태를 체크하기 위한 매직넘버로서 해당 메시지가 헬스 체크 메시지인지를 판별하기 위하여 특정값이 설정되고 여기에서는 서버의 시스템 시간값이 설정된다.

메시지 타입 필드에는 해당 메시지가 헬스 체크 요청 메시지인지 헬스 체크 응답 메시지인지 여부를 표시하기 위한 값이 설정된다.

클라이언트 ID 필드는 서버와 소켓 연결이 설정된 클라이언트 ID의 식별자가 설정되어 각 클라이언트를 구별한다.

패킷 길이 필드는 해당 패킷의 전송오류를 체크하기 위하여 메시지의 길이가 설정된다.

타임 스탬프 필드에는 해당 패킷이 전송되는 시간정보가 설정된다. 타임 스탬프값은 서버와 클라이언트간에 메시지들을 송수신할때 정상적으로 동작하는지 여 부를 확인하기 위해 서버에서 현재 시간을 타임 스탬프 필드에 설정하여 클라이언트에 전송하고, 클라이언트는 그 값을 그대로 헬스 체크 응답 메시지(HC_RESPONSE)에 설정하여 서버에 전송한다. 서버에서는 이 값이 정확하게 클라이언트로부터 오는지를 체크하여 클라이언트의 상태를 판단한다.

타임 아웃값 필드는 서버에서 클라이언트로 헬스 체크 요청 메시지를 전송한 다음으로부터 시간을 카운트하여 일정 시간이 경과할때 까지 헬스 체크 응답 메시자가 수신되지 않으면 해당 소켓의 연결상태가 차단된 것으로 판단하여 소켓을 강제적으로 차단하기 위한 타임아웃 설정값이다.

서버의 전송 주기(Ts)가 변화하면 클라이언트의 기다리는 주기(Tc)도 바뀌어야 하므로 Tc값이 변화될 때 타임 아웃값을 설정하여 전송한다. 이때, Tc는 Ts+α 의 값을 가지는 것이 적당한다. 여기에서 α는 사용자에 의해 설정되는 여유값이다.

한편, 서버(100)에서 각 클라이언트들을 관리하기 위해서는 클라이언트들의 상태정보를 저장하고 있어야 한다. 이에 서버(100)에서는 등록된 클라이언트의 소켓마다 배열 혹은 linked list 형태로 DB(140)를 구성하고 클라이언트 ID(client ID), 클라이언트 소켓(client socket), 클라이언트 상태(client status)를 저장한다.

클라이언트의 상태는 도 6에 도시된 바와 같이 3가지의 상태를 가질 수 있다.

최초에는 종료 상태(HC_ST_CLOSED)에서 임의의 소켓이 소켓 체크 실행 모듈 (130)에 소켓 체크를 위해 등록이 되면 정상 상태(HC_ST_NORMAL)로 상태가 변화되고 서버의 소켓 체크 모듈(130)에서 해당 클라이언트(200)로 헬스 체크 요청 메시지(HC_REQUEST)를 전송하면 전송 상태(HC_ST_SEND)가 된다. 여기에서 클라이언트(200)로부터 헬스 체크 응답 메시지를 수신하면 정상 상태(HC_ST_NORAML)로 다시 상태가 변화된다. 서버(100)에서는 헬스 체크 요청 메시지(HC_REQUEST)를 전송하고 다음번 체크시에 이 클라이언트(200)의 상태를 체크한다.

이에 따라 서버(100)로부터 헬스 체크 요청 메시지를 수신한 클라이언트들은 서버(10)로 헬스 체크 응답 메시지를 전송하게 되고, 서버(100)에서는 헬스 체크 응답 메시지의 수신 여부에 따라 해당 클라이언트의 상태를 판단하여 DB(140)에 해당 클라이언트의 상태를 설정한다.

서버(100)에서 구동되고 있는 응용 프로그램 모듈(110)에서는 클라이언트로부터 임의의 메시지가 수신되면 서버 프로세스 API(114)를 호출한다. 서버 프로세스 API(114)가 호출되면 공통 라이브러리 모듈(120)에 코딩된 프로그램이 실행되어 클라이언트로부터 수신된 해당 메시지가 헬스 체크 응답 메시지인지 여부를 판단한다. 판단하여 헬스 체크 응답 메시지인 경우 해당 클라이언트의 상태값을 정상 상태(HC_ST_NORMAL)로 설정한다.

정상 상태(HC_ST_NORMAL)이면 정상적으로 헬스 체크 응답 메시지를 받은 경우이지만 전송 상태(HC_ST_SENT)로 남아 있다면 무응답(No response)인 경우이다.

도 7은 본 발명의 일실시예에 따른 소켓 관리 시스템을 적용하여 서버에서 소켓을 관리하는 흐름도이다.

도 7을 참조하면, 서버에서 임의의 응용 프로그램 모듈이 구동되면 응용 프로그램을 설정된 클라이언트와 소켓을 형성하는 절차를 수행함과 아울러, 해당 소켓의 연결상태를 체크하기 위해 응용 프로그램 모듈에 코딩된 API를 호출한다(S100). 응용 프로그램 모듈(110)에 의해 API가 호출되면 공통 라이브러리 모듈(120)에서는 호출된 API에 상응하여 정의된 프로그램을 구동하여 소켓의 연결상태를 주기적으로 체크하기 위한 소켓 체크 모듈(130)을 생성한다(S200).

응용 프로그램 모듈(110)은 임의의 클라이언트와 소켓을 생성한 다음 그 소켓의 연결상태를 주기적으로 체크하기 위해 소켓 체크 모듈(130)에 해당 소켓을 등록하기 위한 API를 호출한다. 이에 따라 공통 라이브러리 모듈(120)에서는 해당 API에 상응하여 정의된 프로그램을 구동하여 임의의 소켓에 대한 헬스 체크를 위해 해당 소켓을 소켓 체크 실행 모듈(130)에 등록한다(S300).

소켓 체크 모듈(130)에서는 등록된 소켓의 연결상태를 주기적으로 체크한다(S400).

도 8은 본 발명의 일실시예에 의한 서버에서 소켓 체크 모듈의 동작 흐름도이다.

도 8을 참조하면, 서버(100)에서 일단 생성된 소켓 체크 모듈(130)은 소켓의 연결상태를 주기적으로 체크할 소켓을 등록받아 설정된 절차에 의하여 헬스 체크를 주기적으로 수행한다(S410).

한번의 헬스 체크 동작이 수행되면 소켓 체크 모듈(130)에서는 현재 시간 정보를 획득하여(S420), 헬스 체크 리스트에 등록된 소켓을 가지고 있는 클라이언트 들에게 전송할 헬스 체크 요청 메시지(HC_REQUEST)를 생성한다(S430). 이때, 생성되는 헬스 체크 요청 메시지의 헤더에는 해당 소켓이 설정되어 있는 클라이언트의 ID와, 현재 시간 정보와 타임아웃값이 설정된다.

소켓 체크 모듈(130)은 생성된 헬스 체크 요청 메시지((HC_REQUEST)를 소켓을 설정하고 있는 해당 클라이언트들에게 전송한다(S440).

도 9는 본 발명에 따른 서버의 소켓 체크 모듈이 등록된 소켓의 연결상태를 주기적으로 체크하는 상세한 동작 흐름도이다.

도 9를 참조하면, 소켓 체크 모듈(130)은 DB(140)에 설정된 해당 클라이언트의 상태값을 읽어서(S411) 클라이언트의 상태값이 무응답 상태인지 여부를 판단한다(S412). 클라이언트의 상태가 정상 상태(HC_ST_NORMAL)이면 정상적으로 메시지를 받은 것이지만 전송 상태(HC_ST_SENT)로 남아 있다면 무응답(No response)인 경우라고 판단할 수 있다.

판단결과 무응답인 경우에는 제 1 카운트값을 증가시킨다(S413). 그리고 그 제 1 카운트값이 설정된 제 1 허용횟수(Ns)를 초과하는지 여부를 판단한다(S414). 여기에서 제 1 허용횟수(Ns)는 서버(100)에서 응답이 없는 클라이언트(200, 300)를 기다리는 최대 횟수를 의미한다.

판단 결과 제 1 카운트값이 설정된 제 1 허용횟수(Ns)를 초과하는 경우에는 해당 클라이언트(200, 300)와의 연결을 해제한다(S415).

한편, 클라이언트(200, 300)의 상태값이 무응답 상태인지 여부를 판단한 결과 무응답이 아닌 경우에는 잘못된 응답인지 여부를 판단한다(S416). 판단 결과 응 답은 있으나 매직값이 다른 클라이언트(200, 300)가 잘못된 경우라면 제 2 카운트값을 증가시킨다(S417). 그리고 그 제 2 카운트값이 설정된 제 2 허용횟수(Ns_w)를 초과하는지 여부를 판단한다(S418). 여기에서, 제 2 허용횟수(Ns_w)는 서버(100)에서 응답은 있으나 매직값이 다른 클라이언트(200, 300)가 잘못된 연속 응답을 기다리는 최대 횟수를 의미한다.

판단 결과 제 2 카운트값이 설정된 제 2 허용횟수(Ns_w)를 초과하는 경우에는 로그(log)나 타임 아웃(timeout)값을 조정한다(S419).

도 10은 본 발명에 따른 클라이언트의 소켓 체크 모듈이 소켓의 체크시 수행하는 동작 흐름도이다.

도 10을 참조하면, 클라이언트의 소켓 체크 모듈(230)은 수신 주기의 타임 아웃전에 서버(100)로부터 헬스 체크 요청 메시지(HC_REQUEST)가 수신되었는지 여부를 판단한다(S510). 판단결과 헬스 체크 요청 메시지(HC_REQUEST)가 수신된 경우 그에 대한 헬스 체크 응답 메시지(HC_RESPONSE)를 서버(100)로 전송한다(S520).

소켓 체크 모듈(230)은 헬스 체크 응답 메시지(HC_RESPONSE)를 서버(100)로 전송하면 수신 주기 카운터(미도시됨)를 초기화한 후(S530) 수신 주기를 새롭게 카운팅한다(S540)

한편, 판단 결과 수신주기의 타임아웃전에 헬스 체크 요청 메시지(HC_REQUEST)가 수신되지 않고 수신주기의 타임아웃을 초과한 경우 타임아웃이 초과한 횟수를 카운트하는 카운트값을 증가시키고(S550), 그 카운트값이 허용횟수를 초과하는지 여부를 판단한다(S560). 판단결과 해당 카운트값이 허용횟수를 초과하 지 않은 경우에는 수신 주기 카운터를 초기화하여(S530) 수신주기를 카운팅하는 (S540) 절차를 수행하고, 판단 결과 해당 카운트값이 허용횟수를 초과하는 경우에는 소켓 연결을 해제한다(S570)

도 11은 본 발명의 일실시예에 따른 서버와 클라이언트간의 헬스 체크 메시지의 전송 흐름도이다.

소켓의 헬스 체크 기능은 서버(100)와 클라이언트(200, 300)간의 주기적인 헬스 체크 데이터와 양측의 타이머를 이용하여 구현된다. 서버(100)에서는 헬스 체크 요청 메시지(hc_request)를 전송하고, 클라이언트(200, 300)에서는 이에 대한 응답으로 헬스 체크 응답 메시지(hc_response)를 전송한다.

여기에서 Ts는 서버(100)에서 클라이언트들(200, 30)에게 헬스 체크 요청 메시지(HC_REQUEST)를 전송하는 주기로서, Ts 타임아웃이 일어나면 클라이언트 상태를 체크하고 정상인 클라이언트에게 헬스 체크 요청 메시지(HC_REQUEST)를 전송한다.

도 11을 참조하면, 제 1 클라이언트(200)는 서버에 소켓 설정 메시지를 전송하여 연결을 시도한다. 이에 따라 서버는 제 1 클라이언트(200)에 연결을 설정하고 연결 확인 메시지를 전송한다. 이에 따라 제 1 클라이언트(200)와 서버(100)간에 하나의 소켓이 설정된다.

한편, 제 2 클라이언트(300)도 서버에 소켓 설정 메시지를 전송하여 연결을 시도한다. 이에 따라 서버(100)는 제 2 클라이언트(300)에 연결을 설정하고 연결 확인 메시지를 전송한다. 이에 따라 제 2 클라이언트(300)와 서버간(100)에 하나의 소켓이 설정된다.

서버(100)는 제 1 클라이언트(200)와 제 2 클라이언트(300)와 각각 소켓을 설정한 다음 일정 주기마다 제 1 클라이언트(200)와 제 2 클라이언트(300)에 소켓의 연결상태를 체크하기 위한 헬스 체크 요청 메시지(HC_REQUEST)를 각각 전송한다.

서버로부터 헬스 체크 요청 메시지(HC_REQUEST)를 수신한 제 1 클라이언트(200)와 제 2 클라이언트(300)는 서버에 헬스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

제 1 클라이언트(200)와 제 2 클라이언트(300)로부터 헬스 체크 응답 메시지(HC_RESPONSE)를 수신한 서버(100)는 헬스 체크 요청 메시지(HC_REQUEST)를 전송할 시간이 되면 제 1 클라이언트(200)와 제 2 클라이언트(300)에게 헬스 체크 요청 메시지(HC_REQUEST)를 전송한다. 이때 전송되는 헬스 체크 요청 메시지(HC_REQUEST)는 이전에 전송된 헬스 체크 요청 메시지(HC_REQUEST)와 매직넘버값이 서로 다르게 설정된다.

마찬가지로, 서버(100)로부터 헬스 체크 요청 메시지(HC_REQUEST)를 수신한 제 1 클라이언트(200)와 제 2 클라이언트는 서버(300)에 헬스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

도 12는 본 발명에 의한 헬스 체크 메시지를 이용한 클라이언트 장애 발견 및 처리 흐름도이다.

여기에서, Ts는 서버(100)에서 클라이언트들(200, 30)에게 헬스 체크 요청 메시지(HC_REQUEST)를 전송하는 주기이고, 제 1 허용횟수(Ns)는 서버(100)에서 응답이 없는 클라이언트(200, 300)를 기다리는 최대 횟수. 즉, Ts * Ns 시간동안 클라이언트로부터 응답 메시지가 없으면 서버에서 연결을 해제하는데 사용되는 변수이다.

도 12를 참조하면, 서버(100)는 제 1 클라이언트(200)와 제 2 클라이언트(300)와 각각 소켓을 설정한 다음 일정 주기마다 제 1 클라이언트(200)와 제 2 클라이언트(300)에 소켓의 연결상태를 체크하기 위한 헬스 체크 요청 메시지(HC_REQUEST)를 각각 전송한다.

서버(100)로부터 헬스 체크 요청 메시지(HC_REQUEST)를 수신한 제 1 클라이언트(200)와 제 2 클라이언트(300)는 서버(100)에 헬스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

마찬가지로, 서버(10)로부터 헬스 체크 요청 메시지(HC_REQUEST)를 수신한 제 1 클라이언트(200)는 서버(100)에 헬스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

한편, 제 2 클라이언트(300)에서 장애가 발생한 경우 제 2 클라이언트(300)는 서버(100)로 헬스 체크 응답 메시지(HC_RESPONSE)를 보낼 수 없다. 클라이언트 장애라고 하면 예를 들어 클라이언트의 전원 오프와 같은 오류가 있을 수 있다.

서버(100)는 헬스 체크 요청 메시지(HC_REQUEST)를 전송할 시간이 되면 제 1 클라이언트(200)와 제 2 클라이언트(300)에게 헬스 체크 요청 메시지(HC_REQUEST)를 전송한다. 이때 전송되는 헬스 체크 요청 메시지(HC_REQUEST)는 이전에 전송된 헬스 체크 요청 메시지(HC_REQUEST)와 매직넘버값이 서로 다르게 설정된다.

마찬가지로, 서버(100)로부터 헬스 체크 요청 메시지(HC_REQUEST)를 수신한 제 1 클라이언트(200)는 서버(100)에 헬스 체크 응답 메시지(HC_RESPONSE)를 전송한다.

한편, 제 2 클라이언트(300)는 아직 장애가 해결되지 않은 상태이므로, 서버(100)로 헬스 체크 응답 메시지(HC_RESPONSE)를 보낼 수 없다.

서버(100)는 헬스 체크 요청 메시지(HC_REQUEST)를 전송할 시간이 되면 제 1 클라이언트(200)에 대하여는 매직 넘버값을 다르게 설정하여 헬스 체크 요청 메시지(HC_REQUEST)를 전송한다.

그러나, 서버(100)는 제 2 클라이언트(300)에 대하여는 제 2 클라이언트(300)로부터 수신되어야 할 헬스 체크 응답 메시지가 수신되지 않은 횟수가 설정된 횟수(Ns)를 초과하는 경우 제 2 클라이언트(300)와 설정하였던 소켓의 연결을 해제한다.

도 13은 본 발명에 의한 헬스 체크 메시지를 이용한 서버의 장애 발견 및 처 리 흐름도이다.

여기에서, Tc는 클라이언트(200, 300)에서 헬스 체크 요청 메시지(HC_REQUEST)를 받은 후 다음 번 헬스 체크 요청 메시지(HC_REQUEST)를 받기까지 기다리는 타이머의 주기이다.

Nc는 서버(100)에서 헬스 체크 요청 메시지(HC_REQUEST)를 보내지 않을 경우 클라이언트(200, 300)가 기다리는 최대 횟수로서, Tc * Nc 시간동안 서버의 응답이 없으면 설정된 소켓의 연결을 해제한다.

도 13을 참조하면, 서버(100)에서 헬스 체크 요청 메시지(HC_REQUEST)를 제 1 클라이언트(200)와 제 2 클라이언트(200)에 전송한다. 이에 따라 제 1 클라이언트(200)와 제 2 클라이언트(300)는 그에 대한 헬스 체크 응답 메시지(HC_RESPONSE)를 서버로 전송한다.

서버(100)에서는 설정된 주기마다 헬스 체크 요청 메시지를 제 1 클라이언트(200)와 제 2 클라이언트(300)로 전송하게 되는데 만약, 서버(100)에 장애가 발생한 경우에는 더 이상 헬스 체크 요청 메시지를 전송할 수 없다.

서버 장애라고 하면 예를 들어 서버의 전원오프와 같은 오류가 있을 수 있다. 이 경우, 클라이언트가 재접속 요구를 하느냐는 응용 프로그램에 따라 다를 수 있으므로 옵션으로 처리한다.

제 1 클라이언트(200)와 제 2 클라이언트(300)는 서버(100)에 헬스 체크 응답 메시지를 전송한 후 서버(100)로부터 헬스 체크 요청 메시지가 수신되는지 여부를 체크한다.

아울러, 제 1 클라이언트(200)와 제 2 클라이언트(300)는 자신들이 서버(100)에 헬스 체크 응답 메시지를 전송한 후 경과된 시간을 체크하여 전송주기(Tc) 타임아웃을 경과한 횟수가 지정된 횟수(Nc)를 초과하는 경우 서버와 유지되었던 소켓의 연결을 해제한다.

그리고, 제 1 클라이언트와 제 2 클라이언트는 서버에 새로운 소켓을 설정하기 위하여 새로운 연결을 시도한다.

이렇게 함으로써 각 응용 프로그램들은 원하는 연결관리 기능을 가질 뿐 아니라 시스템 관리에 필요한 서버-클라이언트간의 연결상태도 정확하게 파악할 수 있으며, 빠른 연결 복구 혹은 연결 종료를 가능하게 해준다.

또한, 많은 응용 프로그램 모듈들이 소켓의 연결을 관리하는 관리를 수행해야 하는 불필요한 작업을 없애고 하나의 모듈로 구성된 라이브러리를 이용하여 효율적으로 구현이 가능하다. 이에 따라 네트워크 장비간이나 서버 클러스터링 환경에서 상대쪽의 비정상적 전원 오프나 모듈의 탈장 등 예외 상황이 발생하는 경우 여러 응용 프로그램들에서 적용가능하다.

또한, TCP 연결에서 재 연결이나 연결해제 등 빠르게 처리가 안되는 오류를 쉽고 빠르게 처리 가능하도록 할 수 있다. 이렇게 함으로써 서버 - 클라이언트간의 연결관리를 일원화할 수 있는 시스템 관리를 구현할 수 있고 시스템의 신뢰성을 높일 수 있다.

Claims

서버 또는 클라이언트의 통신을 위해 필요한 소켓을 생성하고, 해당 소켓의 연결상태를 체크하기 위해 정의된 API(Application Programmable Interface)를 호출하여 그 생성된 소켓을 관리하는 적어도 하나 이상의 응용 프로그램 모듈과,

상기 응용 프로그램 모듈로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈과,

상기 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성되어 상기 생성된 소켓의 연결상태를 주기적으로 체크하는 소켓체크 실행모듈을 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서, 상기 API는,

소켓 체크 모듈을 생성하기 위한 서버 초기화 API와,

임의의 소켓에 대한 연결 상태를 체크할 수 있도록 상기 생성된 소켓 체크 모듈에 소켓을 등록하기 위한 서버 등록 API와,

상기 소켓 체크 모듈에 등록되어 연결상태를 체크하던 소켓의 등록을 취소하기 위한 서버 등록 취소 API와,

클라이언트로부터 수신되는 소켓 체크용 메시지를 처리하기 위한 서버 프로세스 API와,

상기 소켓 체크 실행 모듈에 등록되어 있던 모든 소켓을 등록해제하고 소켓 체크 실행 모듈을 해제하기 위한 서버 해제 API중 적어도 하나의 API를 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서, 상기 공통 라이브러리 모듈은,

소켓 체크 모듈을 생성하기 위한 서버 초기화 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

임의의 소켓에 대한 연결 상태를 체크할 수 있도록 상기 생성된 소켓 체크 모듈에 소켓을 등록하기 위한 서버 등록 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

상기 소켓 체크 모듈에 등록되어 연결상태를 체크하던 소켓의 등록을 취소하기 위한 서버 등록 취소 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

클라이언트로부터 수신되는 소켓 체크용 메시지를 처리하기 위한 서버 프로세스 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

상기 소켓 체크 실행 모듈에 등록되어 있던 모든 소켓을 등록해제하고 소켓 체크 실행 모듈을 해제하기 위한 서버 해제 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램중 적어도 하나를 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서, 상기 소켓 체크 실행모듈은,

서버에 탑재되어 해당 서버와 임의의 소켓을 설정하고 있는 클라이언트에 주기적으로 소켓 체크 요청 메시지를 전송하여 해당 클라이언트로부터 전송되는 소켓 체크 응답메시지의 수신 여부에 따라 등록된 소켓의 연결 상태를 주기적으로 체크하는 소켓 연결 관리 시스템.
제 1항에 있어서, 소켓을 생성하고 있는 클라이언트의 상태정보를 저장하는 DB를 더 포함하는 소켓 연결 관리 시스템.
제 5항에 있어서, 상기 클라이언트의 상태정보는 소켓 체크용 메시지의 송수신 여부에 따라 종료 상태, 전송상태, 정상 상태를 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서, 상기 API는,

소켓 체크 모듈을 생성하기 위한 클라이언트 초기화 API와,

서버로부터 수신되는 소켓 체크용 메시지를 처리하기 위한 클라이언트 프로 세스 API와,

상기 소켓 체크 실행 모듈에 등록되어 있던 모든 소켓을 등록해제하고 소켓 체크 실행 모듈을 해제하기 위한 클라이언트 해제 API중 적어도 하나의 API를 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서,

소켓 체크 모듈을 생성하기 위한 클라이언트 초기화 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

서버로부터 수신되는 소켓 체크용 메시지를 처리하기 위한 클라이언트 프로세스 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램과,

상기 소켓 체크 실행 모듈에 등록되어 있던 모든 소켓을 등록해제하고 소켓 체크 실행 모듈을 해제하기 위한 클라이언트 해제 API의 호출에 상응하여 정의된 기능을 수행하도록 코딩된 프로그램중 적어도 하나를 포함하는 소켓 연결 관리 시스템.
제 1항에 있어서, 상기 소켓 체크 실행모듈은,

클라이언트에 탑재되어 해당 클라이언트와 소켓을 설정하고 있는 서버로부터 주기적으로 전송되는 소켓 체크 요청 메시지에 따라 서버에 소켓 체크 응답메시지 를 전송하는 소켓 연결 관리 시스템.
서버 또는 클라이언트의 통신을 위해 필요한 소켓을 생성하고 관리하도록 프로그래밍된 응용 프로그램 모듈이 구동되어 임의의 소켓을 생성하는 단계와,

상기 응용 프로그램 모듈이 그 생성된 소켓의 연결상태를 체크하기 위해 정의된 임의의 API(Application Programmable Interface)를 호출하는 단계와,

상기 응용 프로그램 모듈로부터 임의의 API가 호출되는 경우 호출된 API에 설정된 동작을 수행하기 위한 프로그램이 코딩된 공통 라이브러리 모듈에서 해당 프로그램이 실행되는 단계와,

상기 공통 라이브러리 모듈에 코딩된 프로그램의 실행에 의해 생성된 소켓 체크 모듈에 의해 상기 생성된 소켓의 연결상태를 주기적으로 체크하는 단계를 포함하는 소켓 연결 상태 체크 방법.
제 10항에 있어서, 상기 주기적으로 체크하는 단계는,

서버와 임의의 소켓을 설정하고 있는 클라이언트에 주기적으로 소켓 체크 요청 메시지를 전송하여 해당 클라이언트로부터 전송되는 소켓 체크 응답메시지의 수신 여부에 따라 등록된 소켓의 연결 상태를 주기적으로 체크하는 소켓 연결 상태 체크 방법.
제 1항에 있어서, 상기 주기적으로 체크하는 단계는,

서버로부터 주기적으로 전송되는 소켓 체크 요청 메시지에 따라 서버에 소켓 체크 응답메시지를 전송하는 소켓 연결 상태 체크 방법.
제 10항에 있어서, 상기 프로그램은 서버에 탑재되어,

생성된 소켓의 연결 상태를 체크하기 위한 소켓 체크 모듈을 생성하는 단계와,

임의의 소켓에 대한 연결 상태를 체크할 수 있도록 상기 생성된 소켓 체크 모듈에 해당 소켓을 등록하는 단계와,

상기 생성된 소켓 체크 모듈에 의해 서버와 임의의 소켓을 설정하고 있는 클라이언트에 주기적으로 소켓 체크 요청 메시지를 전송하여 해당 클라이언트로부터 전송되는 소켓 체크 응답메시지의 수신 여부에 따라 등록된 소켓의 연결 상태를 주기적으로 체크하는 단계를 수행하도록 프로그래밍된 소켓 연결 상태 체크 방법.
제 10항에 있어서, 상기 프로그램은 클라이언트에 탑재되어,

생성된 소켓의 연결 상태를 체크하기 위한 소켓 체크 모듈을 생성하는 단계와,

상기 생성된 소켓 체크 모듈에 의해 서버로부터 주기적으로 전송되는 소켓 체크 요청 메시지에 따라 서버에 소켓 체크 응답메시지를 전송하는 단계를 수행하도록 프로그래밍된 소켓 연결 상태 체크 방법.
제 10항에 있어서, 상기 프로그램은 클라이언트에 탑재되어,

생성된 소켓의 연결 상태를 체크하기 위한 소켓 체크 모듈을 생성하는 단계와,

상기 생성된 소켓 체크 모듈에 의해 서버로부터 주기적으로 전송되는 소켓 체크 요청 메시지가 설정된 주기내에 수신되지 않는 횟수가 일정횟수를 초과하는 경우 연결된 소켓을 해제하는 단계를 수행하도록 프로그래밍된 소켓 연결 상태 체크 방법.
임의의 클라이언트와 소켓을 설정하는 서버에서 그 설정된 해당 소켓의 연결상태를 체크하는 방법에 있어서,

상기 클라이언트와 소켓을 설정할 때 해당 소켓의 연결 상태를 체크하기 위한 프로그램이 저장된 라이브러리 함수를 호출하는 단계와,

상기 호출된 라이브러리 함수의 실행에 의하여 주기적으로 체크할 소켓을 등록하는 단계와,

상기 호출된 라이브러리 함수의 실행에 의해 주기적으로 상기 클라이언트에 주기적으로 소켓 체크 요청 메시지를 전송하여 해당 클라이언트로부터 전송되는 소 켓 체크 응답메시지의 수신 여부에 따라 등록된 소켓의 연결 상태를 주기적으로 체크하는 단계를 포함하는 소켓 연결 상태 체크 방법.
제 16항에 있어서, 상기 주기적으로 체크하는 단계는,

현재 시간정보를 획득하는 단계와,

상기 소켓을 설정하고 있는 클라이언트에게 주기적으로 소켓 연결상태를 체크하기 위한 요청 메시지에 상기 획득한 시간정보를 첨부하여 전송하는 단계와,

상기 클라이언트로부터 전송되는 응답 메시지의 수신여부에 따라 상기 소켓의 연결상태를 체크하는 단계를 포함하는 소켓 연결 상태 체크 방법.
제 17항에 있어서, 상기 소켓의 연결상태를 체크하는 단계는,

상기 클라이언트에 소켓의 연결상태를 체크하기 위한 요청메시지를 전송한 후 기설정된 전송주기의 타임아웃을 초과하도록 상기 클라이언트로부터 응답 메시지가 없는 무응답 상태인지를 판단하는 단계와,

상기 판단 결과 무응답 상태인 경우 상기 전송 주기의 타임아웃을 초과한 횟수를 카운트하여 기설정된 허용횟수를 초과하는 경우 소켓 연결을 해제하는 단계를 포함하는 소켓 연결 상태 체크 방법.
제 17항 또는 제 18항에 있어서, 상기 소켓의 연결상태를 체크하는 단계는,

상기 클라이언트로부터 응답 메시지가 수신되는 경우 해당 응답 메시지에 포함된 시간정보가 상기 클라이언트로 전송한 요청 메시지에 저장된 시간정보와 일치하는 정상적인 응답메시지인지 판단하는 단계와,

판단 결과 상기 시간정보가 일치하지 않는 경우 비정상적인 응답 메시지가 수신된 횟수를 카운트하여 기설정된 허용횟수를 초과하면 상기 클라이언트와의 소켓 연결을 해제하는 단계를 포함하는 소켓 연결 상태 체크 방법.
임의의 서버와 소켓을 설정하고 있는 클라이언트에서 해당 소켓의 연결상태를 체크하는 방법에 있어서,

상기 서버와 소켓을 설정할 때 해당 소켓의 연결 상태를 체크하기 위한 프로그램이 저장된 라이브러리 함수를 호출하는 단계와,

상기 호출된 라이브러리 함수의 실행에 의해 상기 서버로부터 주기적으로 수신되는 소켓 체크 요청 메시지에 대하여 소켓 체크 응답메시지를 전송하고, 상기 소켓 체크 요청 메시지가 주기적으로 수신되는지 여부에 따라 상기 서버와 설정된 소켓의 연결 상태를 체크하는 단계를 포함하는 소켓 연결 상태 체크 방법.
제 20항에 있어서, 상기 소켓의 연결 상태를 체크하는 단계는,

상기 서버에 상기 소켓 체크 응답 메시지를 전송한 후 기설정된 전송주기의 타임아웃을 초과하기전에 상기 서버로부터 소켓 체크 요청 메시지가 수신되었는지 여부를 판단하는 단계와,

상기 판단 결과 상기 전송주기의 타임아웃을 초과하도록 상기 소켓 체크 요청 메시지가 수신되지 않은 경우 상기 전송 주기의 타임아웃을 초과한 횟수를 카운트하여 기설정된 허용횟수를 초과하는 경우 소켓 연결을 해제하는 단계를 포함하는 소켓 연결 상태 체크 방법.