KR100602651B1 - Ｔｃｐ 커넥션 관리 장치 및 방법 - Google Patents

Ｔｃｐ 커넥션 관리 장치 및 방법 Download PDF

Info

Publication number
KR100602651B1
KR100602651B1 KR20040009774A KR20040009774A KR100602651B1 KR 100602651 B1 KR100602651 B1 KR 100602651B1 KR 20040009774 A KR20040009774 A KR 20040009774A KR 20040009774 A KR20040009774 A KR 20040009774A KR 100602651 B1 KR100602651 B1 KR 100602651B1
Authority
KR
South Korea
Prior art keywords
tcp
tcp connection
scc
kernel
message
Prior art date
Application number
KR20040009774A
Other languages
English (en)
Other versions
KR20050081513A (ko
Inventor
박형준
최병구
박용석
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR20040009774A priority Critical patent/KR100602651B1/ko
Priority to JP2005029537A priority patent/JP2005228316A/ja
Priority to CNA2005100078929A priority patent/CN1655552A/zh
Priority to US11/052,095 priority patent/US7532577B2/en
Publication of KR20050081513A publication Critical patent/KR20050081513A/ko
Application granted granted Critical
Publication of KR100602651B1 publication Critical patent/KR100602651B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

본 발명은 두 어플리케이션들간에 설정되는 TCP 커넥션을 감시함에 있어서, TCP 커넥션에 발생한 이상을 신속하게 감지하면서 TCP 커넥션 감시를 수행하기 위해 발생하는 오버헤드를 감소시키기 위한 것으로, 어플리케이션의 하위에 존재하는 TCP/IP 커널에서의 메시지 교환을 통하여 TCP 커넥션 감시를 수행하는 임베디드 시스템의 TCP 커넥션 관리 장치 및 방법을 제안한다.
임베디드 시스템, TCP 커넥션, SCC(Session Connectivity Check), TCP 커넥티비티 체크, TCP 세션 커넥티비티 체크, 커널, TCP/IP 커널

Description

ＴＣＰ 커넥션 관리 장치 및 방법{APPARATUS AND METHOD OF TCP CONNECTION MANAGEMENT}
도 1은 임베디드 시스템의 소프트웨어 블록들 간의 메시지 교환을 통한 TCP 세션 커넥티비티 체크를 도시하는 도면.
도 2는 TCP 커넥션에서 사용되는 TCP 패킷의 포맷을 도시하는 도면.
도 3은 TCP 헤더부의 옵션 필드에 해당하는 TCP 옵션들을 도시하는 도면.
도 4는 소프트웨어 블록들 간의 TCP 커넥션 생성 과정을 도시하는 도면.
도 5는 프로토콜 계층구조를 도시하는 도면.
도 6은 리눅스 커널에서의 제어흐름을 도시하는 도면.
도 7은 BSD 시스템의 소켓 옵션을 도시하는 도면.
도 8은 본 발명을 실시하기 위해 사용되는 새로운 TCP 옵션인 SO_SCC를 나타내는 도면.
도 9는 본 발명에 따른 도면으로, TCP/IP 커널에서 수행되는 TCP 세션 커넥티비티 체크를 도시하는 도면.
도 10은 본 발명에 따른 도면으로, 본 발명의 실시를 위한 TCP/IP 커널의 구성요소들을 도시하는 블록구성도.
도 11은 본 발명의 실시를 위해 사용되는 TCP 세션 커넥티비티 체크 옵션의 항목을 도시하는 도면.
도 12는 본 발명에 따른 도면으로, TCP 세션 커넥티비티 체크 기능을 위해 사용되는 TCP 패킷 포맷을 나타내는 도면.
도 13은 본 발명에 따른 도면으로, 클라이언트 측에서의 TCP 세션 커넥티비티 체크 과정을 도시하는 순서흐름도.
도 14는 본 발명에 따른 도면으로, 서버 측에서의 TCP 세션 커넥티비티 체크 과정을 도시하는 순서흐름도.
본 발명은 임베디드 시스템(Embedded System)에서의 TCP 커넥션(Transmission Control Protocol Connection) 관리 장치 및 방법에 관한 것으로, 특히 임베디드 시스템에서 실행되는 소프트웨어 블록들 간에 설정되어 있는 TCP 커넥션의 상태를 감시하고, 그에 따라 TCP 커넥션을 관리하는 임베디드 시스템의 TCP 커넥션 관리 장치 및 방법에 관한 것이다.
임베디드 시스템이란, 특정 필요에 의하여 하나의 단위 그룹에 다수의 프로세서를 구비하여, 각각의 프로세서가 상호 기능 협조를 통하여 해당 그룹이 목적한 서비스를 제공하는 시스템을 의미한다. 즉, 임베디드 시스템에서는 목적 달성을 위한 협조를 위해서 각 프로세서에서 동작하는 소프트웨어(software, 이하 "S/W"라 칭한다) 블록들간의 연결이 요구된다. 또, 임베디드 시스템에서는 특정 S/W 블록들간의 연결 단절 및 이상 동작이 다른 S/W 블록들의 기능에까지 영향을 미칠 수도 있다. 그러므로, 특히 임베디드 시스템에서는 커넥션의 이상 동작 여부를 신속하게 감지하고, 차단할 수 있는 관리 장치 및 방법이 요구된다.
한편, 네트워크 시스템은 수많은 S/W 블록들이 상호 연동하여 동작하고 있으며, 각각의 S/W 블록들 간의 통신을 위하여 공유 메모리(Shared Memory), 메시지 큐(Message Queue), TCP/UDP(User Datagram Protocol)/IP(Internet Protocol) 등 많은 방법을 사용하고 있다. 이들 중 공유 메모리나 메시지 큐는 동일한 하드웨어(hardware, 이하 "H/W"라 칭한다) 블록 내에서 동작하는 S/W 블록들 간의 통신을 위해 사용되고, TCP/UDP/IP는 별개의 H/W 블록에서 동작하는 S/W 블록들 간의 통신을 위해 사용된다. 특히 대용량 네트워크 시스템과 같이 다수의 H/W 블록으로 구성되어 있는 임베디드 시스템에서 H/W 블록간의 통신을 구현하거나, 좀더 신뢰성 있는 통신을 구현하기 위해 TCP/IP가 많이 사용되고 있다. 이는 패킷의 전송 여부를 확인하고 전송되지 않은 패킷을 재송신하는 TCP가 UDP에 비해 신뢰도가 높은 통신방법이기 때문이다. TCP가 제공하는 고신뢰성 통신 서비스는 송신측의 상위층에서 보낸 데이터를 수신측 TCP의 상위층에 완전한 모양으로 제공한다.
현재의 TCP/IP는 네트워크에서 신뢰성 있는 통신을 지원하려는 목적으로 탄생하였다. 그러나, TCP/IP는 폴링 프로토콜(Polling Protocol)이 아니다. 여기서 폴링 프로토콜이란, 순차적으로 송신 요구의 유무를 문의하고, 요구가 있을 경우에 는 그 단말 장치에 송신을 시작하도록 명령하며, 요구가 없을 경우에는 다음의 단말 장치에 대하여 문의하게 되는 전송 제어 방식을 가지는 프로토콜을 의미한다. 따라서, TCP에서는 커넥션의 상태를 수시로 체크하기 위한 메커니즘을 제공하지 않는다.
TCP에서 커넥션의 상태를 체크하는 기능을 수행하기 위해 킵얼라이브 타이머(keepalive timer)가 존재하나, 이는 피어 커넥션(peer connection)의 상태를 체크하기 위한 것이 아니라 배드 피어(bad peer)를 체크하기 위한 것이다. 킵얼라이브 타이머는 두 TCP 사이에 설정된 오랜 기간 동안 휴지(idle) 상태에 있는 것을 방지하기 위해서 사용된다. 한 클라이언트가 서버와의 TCP 커넥션을 설정하고, 데이터를 전송한 후, 더 이상 데이터를 전송하지 않는 경우를 생각해 보자. 여기서 클라이언트는 TCP 커넥션의 설정을 요청한 측이고, 서버는 클라이언트로부터 TCP 커넥션의 설정을 요청 받은 측이다.
클라이언트에 이상이 발생한 경우에는, 이상이 발생한 클라이언트와 서버간의 TCP 커넥션은 연결된 상태를 영원히 유지하게 될 것이다. 이러한 상황을 해결하기 위하여 대부분의 서버에는 킵얼라이브 타이머가 구현되어 있다. 서버가 클라이언트로부터 세그먼트를 받을 때마다, 서버는 이 타이머를 초기화한다. 시간-종료는 일반적으로 2시간이다. 만일 서버가 2시간이 지나도록 클라이언트로부터 어떠한 세그먼트도 수신하지 못하면, 서버는 이상 발생 여부를 판단하기 위하여 프로브 세그먼트를 전송한다. 각각 75초의 시간 간격으로 10개의 프로브를 전송하였는데도 어떠한 응답도 수신하지 못하였을 경우에 서버는 클라이언트가 다운되었다고 간주하고 해당 TCP 커넥션을 종료한다. 따라서, 킵얼라이브 타이머를 이용하여 TCP 커넥션 상태를 체크하는 경우에 시스템은 TCP 커넥션에 이상이 발생하여 단절된 후에 오랜 시간이 지난 후에야 해당 TCP 커넥션의 단절을 감지할 수 있다.
TCP 커넥션 상태를 감시하기 위한 다른 방법으로, 대부분의 시스템에서는 어플리케이션 계층(Application Layer)에서 주기적으로 작은 메시지를 주고받는 방법을 사용한다. 이 방법을 사용하는 시스템은 특성 TCP 커넥션에서 일정시간 이상 메시지의 교환이 없는 경우 이 TCP 커넥션에 이상이 발생한 것으로 판단한다. 이 방법은 TCP 커넥션의 단절을 신속하게 감지할 수 있다는 점에서 킵얼라이브 타이머를 사용하는 것보다 효율적이다. 그러나, 이렇게 각각의 어플리케이션 계층에서 TCP 커넥션에 대한 감시를 수행하는 방법을 수많은 어플리케이션 프로세스들이 동작하고 있는 임베디드 시스템에서 적용할 때는, 해당 기능에 대한 커넥션을 유지하고 커넥션 단절을 빨리 검출해야 할 필요가 있는 모든 어플리케이션에서 구현해야 하므로, 많은 양의 오버헤드(overhead)가 발생하게 된다.
특히, 모든 어플리케이션에 동일하게 적용되는 이벤트(Event), 예를 들어 서브 시스템의 전원 차단(Power OFF), 링크의 단절, H/W 블록(Hardware Block)의 탈장과 같은 이벤트가 발생하였을 경우에는 실제로 각 S/W 블록간의 커넥션은 실제로 아무런 데이터도 주고받지 못하는 상태가 되며, 이러한 상태에 있는 커넥션을 빨리 감지(Detect)하여 차단(Close)하고 각 S/W 블록별로 필요한 기능을 수행하여야 효율적인 임베디드 시스템을 구현할 수 있다.
도 1은 임베디드 시스템의 S/W 블록들 간의 메시지 교환을 통한 TCP 커넥션 에 대한 감시를 도시하고 있다.
도 1에 도시된 시스템은 복수의 H/W 블록들(100-1 내지 100-n)로 이루어지는 임베디드 시스템이다. 각 H/W 블록(100)은 TCP/IP 커널을 통하여 다른 H/W 블록(100)과의 TCP/IP 통신을 수행할 수 있다. 각 H/W 블록(100)에는 복수의 S/W 블록들(111 내지 119)이 실행되고 있으며, 이 S/W 블록들(111 내지 119)은 다른 H/W 블록(100)에서 실행되는 S/W 블록들(111 내지 119)과 TCP/IP 통신을 통해 연결된다. 그런데, 이와 같은 경우, 각 S/W 블록들(111 내지 119) 간의 TCP 커넥션의 상태를 감시하기 위해서는 모든 S/W 블록들(111 내지 119)간에 메시지 교환이 이루어져야 한다.
예를 들어, H/W 블록 1의 S/W 블록 1(111-1)과 H/W 블록 2의 S/W 블록 1(112-1) 간의 TCP 커넥션을 감시하기 위해 사용되는 감시 메시지의 전송 경로는 H/W 블록 1의 S/W 블록 1(111-1) → H/W 블록 1의 TCP/IP 커널(120-1) → H/W 블록 2의 TCP/IP 커널(120-2) → H/W 블록 2의 S/W 블록 1(112-2)이다. 또, 이에 대한 응답 메시지는 반대의 경로를 통해 H/W 블록 2의 S/W 블록 1(112-1)로부터 H/W 블록 1의 S/W 블록 1(111-1)에 전송된다.
이와 같은 방법을 통해 TCP 커넥션의 상태를 감시하기 위해서는 앞서 기술한 경로를 통한 메시지의 전송이 수시로 이루어져야 하므로 과도한 오버헤드가 발생하게 되다. 따라서, 임베디드 시스템을 효율적으로 관리하기 위하여 신속하면서도 오버헤드가 적은 TCP 커넥션 관리 장치 및 방법이 요구된다.
따라서, 본 발명의 목적은 TCP 커넥션의 단절을 신속하게 감지할 수 있는 임베디드 시스템의 TCP 커넥션 관리 장치 및 방법을 제공함에 있다.
본 발명의 다른 목적은 TCP 커넥션 감시 기능에 따라 발생하는 오버헤드를 감소시키는 TCP 커넥션 관리 장치 및 방법을 제공함에 있다.
본 발명의 또 다른 목적은 좀더 표준화된 TCP 커넥션 상태 감시 기능을 구현할 수 있는 TCP 커넥션 관리 장치 및 방법을 제공함에 있다.
이와 같은 목적을 달성하기 위하여 본 발명은 TCP/IP 커널에서 TCP 커넥션의 연결 상태 감시 기능을 수행하는 장치 및 방법을 제안한다.
본 발명은 임베디드 시스템에서 실행 중인 S/W 블록들 간에 설정되어 있는 TCP 커넥션의 상태에 대한 주기적인 감시를 통해 비정상적으로 동작하는 TCP 커넥션을 신속하게 감지하면서도 그에 따른 오버헤드를 감소시키기 위하여, 어플리케이션인 S/W 블록보다 하위에 존재하는 TCP/IP 커널에서 TCP 커넥션에 대한 감시, 즉 TCP 세션 커넥티비티 체크(TCP Session Connectivity Check)를 수행하는 TCP 커넥션 관리 장치 및 방법을 제안한다.
이를 구체적으로 기술하면, 본 발명은 임의의 두 어플리케이션들간에 설정된 TCP(Transmission Control Protocol) 커넥션을 관리하는 장치에 있어서, 상기 TCP 커넥션의 설정 정보 및 상기 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 위한 설정 값을 저장하고, 상기 설정 정보 및 설정 값에 따라 SCC(Session Connectivity Check) 메시지를 생성하여 상대 TCP/IP 커널에 송신하고, 상대 TCP/IP 커널로부터의 SCC 응답 메시지 수신 여부에 따라 상기 TCP 커넥션의 정상 동작 여부를 판단하는 TCP/IP 커널을 포함하는 TCP 커넥션 관리 장치를 제안한다.
또한, 본 발명은 임의의 두 어플리케이션들간에 설정된 TCP 커넥션을 관리하는 방법에 있어서, 상기 TCP 커넥션이 TCP 세션 커넥티비티 체크를 요청하는 TCP 커넥션인지 판단하는 제 1과정과, TCP 세션 커넥티비티 체크를 위한 SCC 메시지를 생성하는 제 2과정과, 상기 생성된 SCC 메시지를 상기 TCP 커넥션을 통해 연결되는 상대 TCP/IP 커널에 송신하는 제 3과정과, 상기 상대 TCP/IP 커널로부터 상기 SCC 메시지에 대한 응답 메시지가 소정의 시간 내에 수신되는지 판단하고, 상기 응답 메시지가 상기 시간 내에 수신되지 않으면 상기 TCP 커넥션이 정상 동작하지 않는 것으로 판단하는 제 4과정을 포함하는 TCP 커넥션 관리 방법을 제안한다.
본 발명에서의 "커널"은 특히 TCP와 관련된 부분을 가리킨다. 일반적으로 커널이란 운영체제의 코어(core)를 의미하나, 네트워크 측면에서의 운영체제를 고려할 시에는 트랜스포트 계층의 TCP와 네트워크 계층의 IP가 커널에 해당하게 된다. 따라서 본 발명을 설명함에 있어서는 그 이해를 돕기 위해 "TCP/IP 커널"이라는 용어를 사용한다. 비록 TCP/IP라는 용어를 사용하였으나 본 발명은 TCP 커널에서 동작하게 된다.
이하 도면을 참조하여 본 발명을 상세히 설명한다.
이하 참조하는 도면에는 그 설명의 편의를 위하여 참조부호를 사용하고 있는 데, 동일한 기능을 가지는 블록을 여러 개 도시할 때는 "-"를 사용하여 각각을 구분하였다. 예를 들어, 도 1에 도시된 각 H/W 블록들은 100-1, 100-2 등의 참조부호를 가진다. 각각의 H/W 블록을 구분하여 언급할 필요가 있을 때는 참조부호를 (100-1), (100-2)와 같이 부가하고, H/W 블록들을 통칭하는 경우에는 참조부호를 대표번호인 (100)으로 부가하도록 한다.
하기에서 본 발명은 그 대상을 임베디드 시스템으로 하여 설명되고 있으며, 또 본 발명이 특히 효과적으로 적용될 수 있는 시스템 역시 임베디드 시스템이다. 그러나 본 발명은 임베디드 시스템만이 아니라, TCP 커넥션의 연결 상태에 대한 감시가 필요한 다른 시스템들에 대해서도 적용될 수 있다.
도 1에 도시된 TCP/IP 커널(120)은 파일, 프로세서 및 네트워킹 관리를 수행하는 TCP 커널 계층에 해당하는 것으로, 실행 중인 각 S/W 블록(111 내지 119)에 대한 관리를 수행한다. 이는 TCP/IP 커널(120)이 S/W 블록들(111 내지 119) 간에 설정되어 있는 TCP 커넥션 정보 가지고 있어야 한다는 의미이다. 그러므로, TCP/IP 커널(120)은 이러한 정보를 참조하여 S/W 블록들(111 내지 119) 간에 설정된 TCP 커넥션에 대한 감시를 수행할 수 있을 것이다. 이와 같이, TCP/IP 커널(120)이 각 S/W 블록들(111 내지 119) 간의 TCP 커넥션에 대한 감시를 수행하게 되면, 감시 메시지의 교환이 TCP/IP 커널들(120) 간에서만 이루어지면 되므로, TCP 커넥션 감시에 따른 오버헤드를 상당히 감소시킬 수 있다.
도 2는 TCP 커넥션에서 사용되는 TCP 패킷의 포맷을 도시하는 도면이다.
도 2에 도시된 바와 같이, TCP 패킷은 헤더부(200)와 데이터 부(240)로 구성 된다. TCP 헤더부(200)는 16비트의 송신원 포트(Source Port) 필드(202), 16비트의 수신처 포트(Destination Port) 필드(204), 32비트의 시퀀스 번호(Sequence Number) 필드(206), 32비트의 응답 번호(Acknowledgement Number) 필드(208), 4비트의 데이터 오프셋 필드(210), 6비트의 예약(Reserved) 필드(212), 6비트의 제어 플래그 필드(214 내지 224), 16비트의 윈도우 사이즈 필드(226), 16비트의 체크썸(Checksum) 필드(228), 16비트의 긴급 포인터(Urgent Pointer) 필드(230), 24비트의 옵션(Options) 필드(232), 8비트의 패딩(padding) 필드(234)를 포함한다.
TCP 패킷의 헤더부(200)는 패킷이 어느 커넥션에 속하고 있는가를 식별하는 정보를 포함한다. TCP 헤더부(200)의 송신원 포트 번호(202) 및 수신처 포트 번호(204)의 포트 번호는 TCP가 제공하는 식별자이다. 포트 번호는 0에서 65535까지의 식별자이다. 시퀀스 번호(206)는 TCP 패킷의 송신 순서를 나타내기 위해 사용된다. 즉, 시퀀스 번호(206)는 데이터가 분할되어 TCP 패킷에 실려서 송신되는 경우, 이 분할된 데이터를 원래의 순서대로 조합하기 위해 사용된다. 응답 번호(208)는 TCP 패킷이 수신측에 올바르게 수신되었음을 송신측에 알리기 위해 사용된다. 데이터 오프셋(210)은 TCP 헤더의 길이를 나타낸다. 일반적으로, 특별한 옵션을 포함하지 않은 TCP 헤더의 길이는 20바이트이다. 예약(212)은 나중에 확장하기 위해 준비해 둔 필드이며, 6바이트의 길이이다.
제어 플래그들(214 내지 224)은 일반적으로 그 값이 "1"로 지정될 때 의미를 가지는데, 그 각각의 의미는 다음과 같다. URG(Urgent Flag, 긴급 플래그)(214)는 긴급 처리를 해야 하는 데이터가 포함되어 있음을 알리기 위해 사용된다 긴급 처 리를 해야 하는 데이터의 위치는 긴급 포인터(230)에 들어 있다. ACK(Acknowledgement Flag, 응답 확인 플래그)(216)는 응답 확인의 사용 여부를 나타낸다. ACK(216)의 값이 응답 확인을 사용하지 않는 것으로 설정되어 있다면, 이는 TCP의 특징인 신뢰성 있는 통신을 포기하고 UDP통신에 가까운 형태로 동작한다. PSH(Push Flag, 푸시 플래그)(218)는 TCP가 받은 데이터를 상위의 어떤 어플리케이션에 보낼 것인지를 나타낸다. RST(Reset Flag, 초기화 플래그)(220)는 통신 불량이 발생하여 제어할 수 없는 상태일 때 초기화를 명령하기 위해 사용된다. SYN(Synchronize Flag, 동기화 플래그)(222)는 가상 회로를 확립할 때 사용된다. FIN(Fin Flag, 종료 플래그)(224)는 송신 쪽이 보낸 데이터가 종료되었다는 것을 나타낸다.
윈도우 사이즈(226)는 통신 가능한 데이터 양을 알리기 위해 사용된다. 긴급 포인터(230)는 URG(214)가 설정되어 있을 때 유용하다. 윈도우 사이즈(226)에 나타난 수치는 긴급 처리를 해야 하는 데이터를 가리키는 포인터로 취급된다. 옵션(232)은 통신의 세부 사항을 조정하기 위해 사용되는데, 옵션이므로 지정하지 않아도 통신을 할 수 있다. 옵션의 지정 여부는 사용자가 선택한다. 체크썸(228)은 데이터 오류검출 방법으로, 패킷의 완전성을 체크하기 위해 사용된다.
도 3은 도 2에 도시된 TCP 헤더부의 옵션 필드에 사용될 수 있는 TCP 옵션들을 도시하고 있다.
도 3에 각각의 레퍼런스가 표기되어 있으므로 이에 대한 설명은 생략한다.
도 4는 도 1에 도시된 S/W 블록들 간의 TCP 커넥션 생성 과정을 도시하고 있 다.
도 4에 도시된 S/W 블록 A(400) 및 S/W 블록 B(410)는 도 1에 도시된 S/W 블록(111 내지 119)에 해당한다. 먼저, S/W 블록 A(400)는 S/W 블록 B(410)에 SYN 플래그(222)가 1이고 ACK 플래그(216)가 0인 SYN 패킷(401)을 송신한다. S/W 블록 A(400)로부터 TCP 패킷(401)을 수신한 S/W 블록 B(410)는 이에 대한 회신인, SYN 플래그(222)와 ACK 플래그(216)가 모두 1인 SYN 응답(ack) 패킷(403)을 S/W 블록 A(400)에 송신한다. SYN 응답 패킷(403)을 수신한 S/W 블록 A(400)가 ACK 플래그(216)가 1이고 SYN 플래그(222)가 0인 ACK 패킷(405)을 S/W 블록 B(410)에 송신함으로써 S/W 블록 A(400)와 S/W 블록 B(410) 간에 TCP 커넥션이 설정된다. 이와 같은 커넥션 생성 과정을 3중 핸드셰이크(3-way handshake)라 한다.
도 4에 도시된 바와 같은 과정을 통해 생성된 TCP 커넥션에 대한 TCP 커넥션 단절 감시(TCP Connection Loss Check) 기능은 TCP의 옵션 기능을 사용하여 구현된다. 본 발명에 따른 TCP 세션 커넥티비티 체크를 위해서는 도 4에 도시된, TCP 커넥션 생성 과정에 새로운 TCP 옵션을 추가한 SYN 메시지를 사용하여 TCP 커넥션 단절 감시 기능을 사용하기 위한 협상(Negotiation)을 수행한다. 이와 같이 임의의 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크 수행 여부는 TCP 커넥션의 생성 시에 결정된다. 생성되는 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크 수행 여부는 그 TCP 커넥션에 대한 생성을 요청하는 소프트웨어 블록(111 내지 119)의 요청에 따라 결정된다.
도 5는 소켓과 프로토콜 스택의 계층구조를 도시하는 도면이다.
도 5에 도시된 계층 구조를 살펴보면, 제일 최하위 층에 네트워크 인터페이스인 병렬포트(500), 직렬포트(502), 이더넷 카드(504)가 위치한다. 네트워크 인터페이스는 특정 네트워크에 대응한 하드웨어이다.
네트워크 인터페이스의 상위 층에 디바이스 드라이버인 PLIP(Parallel Line Internet Protocol)(510), SLIP(Serial Line Internet Protocol), 이더넷(514), ARP(Address Resolution Protocol)(516)이 위치한다. 디바이스 드라이버는 하드웨어와 통신하는 소프트웨어이다.
디바이스 드라이버의 상위 층인 네트워크 계층에 IP(Internet Protocol)(520)이 위치한다. 네트워크 계층의 상위 층인 트랜스포트 계층에 TCP(530), UDP(User Datagram Protocol)(532)이 위치한다.
트랜스포트 계층의 상위 에 INET 소켓(540)이 위치한다. INET 소켓(540)의 상위 에 BSD(Berkeley Software Distribution) 소켓(550)이 위치한다. INET 소켓(540)과 BSD 소켓(550)을 통칭하여 소켓이라 한다. 소켓이란 TCP/IP에 입각한 IPC(Interprocess Communication, 프로세스간 통신) 인터페이스이다. 소켓을 사용하면 파일의 기록ㆍ판독을 하는 것과 마찬가지로 네트워크를 경유하여 데이터를 송수신 할 수 있게 된다. INET 소켓(540)은 TCP와 UDP의 소켓이고, BSD 소켓(550)은 일반적인 소켓 인터페이스의 관리를 수행한다.
마지막으로, 최상위 층이 어플리케이션(560)이 된다.
도 5에서 어플리케이션(560)을 제외한 BSD 소켓(550) 이하 병렬포트(500), 직렬포트(502), 이더넷 카드(504)의 네트워크 인터페이스까지가 운영체제에 해당될 수 있다. 이들 운영체제 중에서 트랜스포트 계층의 TCP(530)와 네트워크 계층의 IP(520)를 특히 커널에 해당한다. 물론 이들 구분은 시스템의 통신과 관련된 부분에 대한 구분이 될 것이다.
S/W 블록(111 내지 119)은 도 5에 도시된 어플리케이션(560)에 해당한다. 즉, S/W 블록(111 내지 119)은 메시지 전송 등의 통신을 수행하기 위한 계층구조에서 가장 상위에 위치하고 있다.
도 6은 리눅스 커널을 예로 들어 시스템 상에서의 제어흐름을 도시하는 도면이다.
임의의 어플리케이션 즉, 임의의 소프트웨어 블록(111 내지 119)이 다른 하나의 소프트웨어 블록(111 내지 119)에 하나의 메시지를 송신하고자 하는 경우, 시스템 상에서는 도 6에 도시된 바와같은 제어흐름이 이루어진다. 메시지를 보내고자 하는 소프트웨어 블록(111 내지 119)은 인터페이스의 하나인 VFS(Virtual File System)(600)에서 sys_write()라는 함수를 호출하여 보내고자 하는 메시지의 내용을 기록한다. 이를 통해 소프트웨어 블록이 송신하고자 하는 메시지는 BSD 소켓(550)에 전달된다.
VFS(600)로부터 메시지를 전달받은 BSD 소켓(550)은 sock_write() 함수를 호출하여 이 메시지를 INET 소켓(540)에 전달한다. INET 소켓(540)은 inet_sendmsg() 함수를 호출하여 BSD 소켓(550)으로부터 전달받은 메시지를 TCP(530)에 전달한다. TCP(530)는 tcp_send_skb() 함수를 호출하여 INET(540) 소켓으로부터 전달받은 메시지를 IP(520)에 전달한다. IP(520)는 ip_queue_xmit() 함수를 호출하여 TCP(530)로부터 전달받은 메시지를 디바이스(610)에 전달한다. 디바이스(610)는 디3_start_xmit() 함수를 호출하여 TCP(530)로부터 전달받은 메시지를 송신한다.
한편, 본 발명에서는 TCP 커넥티비티 체크를 커널인 TCP/IP가 수행하므로, 본 발명에 따른 TCP 커넥티비티 체크를 적용한다면 도 6의 TCP(530) 이하의 함수 호출만이 수행된다. 따라서, INET 소켓(540) 이상에서의 함수 호출 및 그에 따른 메시지 흐름이 생략될 수 있으며, 그에 따른 오버헤드 감소가 이루어진다.
도 7은 BSD 시스템에서 지원하는 소켓 옵션을 도시하는 도면이고, 도 8은 본 발명을 실시하기 위해 사용되는 새로운 TCP 옵션인 SO_SCC를 도시하는 도면이다.
도 8에 도시된 새로운 TCP 옵션인 SO_SCC(Socket Option_Session Connectivity Check)을 추가함으로써 본 발명에 따른 TCP 세션 커넥티비티 체크를 구현할 수 있게 된다. 최초 TCP 커넥션 생성 시에 SO_SCC를 이용하여 해당 TCP에 대한 TCP 커넥티비티 체크가 수행되도록 설정한다.
본 발명에 따른 TCP 세션 커넥티비티 체크 기능의 구현을 통해서, S/W 블록(111 내지 119)간에 설정된 TCP 커넥션에 대한 감시 기능은 TCP/IP 커널(120)이 수행하게 된다. 이를 도면을 참조하여 설명한다.
도 9는 본 발명에 따른 도면으로, TCP/IP 커널(120)에서 수행되는 TCP 세션 커넥티비티 체크를 도시하는 도면이다.
본 발명과 같이 TCP 세션 커넥티비티 체크가 TCP/IP 커널(120)에서 이루어지는 경우에는, 도 9에 도시된 바와 같이, TCP 세션 커넥티비티 체크를 위한 메시지 교환이 TCP/IP 커널(120) 간에서만 이루어진다. 예를 들어, H/W 블록 1의 S/W 블록 1(111-1)과 H/W 블록 2의 S/W 블록 1(112-1)간에 설정된 TCP 커넥션에 대한 커넥티비티 체크를 위한 메시지 교환은 H/W 블록 1의 TCP/IP 커널(120-1)과 H/W 블록 2의 TCP/IP 커널(120-2) 간에서만 이루어진다. 즉, 각 S/W 블록(111 내지 119)과 TCP/IP 커널(120) 간의 메시지 교환이 생략되므로 그에 따른 오버헤드 감소가 발생한다. 한편, TCP/IP 커널(120) 간의 메시지 교환을 통한 TCP/IP 커널(120)에서의 TCP 세션 커넥티비티 체크를 수행하기 위해서는 TCP 커넥션 생성 시에 이를 위한 설정이 수행되어야 한다. 이에 대해서는 도 4에 도시된 TCP 커넥션 생성 과정을 설명하면서 언급한 바 있다.
먼저, 본 발명에 따른 TCP/IP 커널(120)의 구조의 일 실시예를 도면을 참조하여 설명한다.
도 10은 본 발명에 따른 도면으로, 도 9에 도시된, TCP/IP 커널에서의 TCP 세션 커넥티비티 체크를 수행하기 위한 TCP/IP 커널의 구성요소들을 도시하는 블록구성도이다.
도 10에 도시된 바와 같이, 본 발명에 따른 TCP/IP 커널(120)은 입출력부(1000), 제어부(1010), 저장부(1020) 및 타이머(1030)를 포함한다. 도 10의 타이머(1030)는 본 발명에서는 특히 SCC 타이머가 될 수 있다.
TCP/IP 커널(120)의 입출력부(1000)는 상위 층 및 하위 층과의 인터페이스를 제공한다. 이를 통해 TCP/IP 커널(120)은 자신이 포함된 하드웨어 블록(100-1 내지 100-n)에 다른 하드웨어 블록(100-1 내지 100-n)과의 TCP/IP 통신을 제공한다. 하드웨어 블록 1의 TCP/IP 커널(120-1)을 예로 들어 설명해 보자.
하드웨어 블록 1의 TCP/IP 커널(120-1)은 입출력부(1000)를 통하여 소프트웨어 블록(111-1 내지 111-k) 및 상대 하드웨어 블록의 TCP/IP 커널(120-2 내지 120-n)과의 메시지 전송을 수행할 수 있다. 물론, 상세히 설명하자면, TCP/IP 커널(120-1)은 소프트웨어 블록(111-1 내지 111-k) 또는 상대 TCP/IP 커널(120-2 내지 120-n)과 직접 연결되는 것이 아니라, 도 5 및 도 6에 도시된 다른 중간과정들을 거쳐서 연결된다. 그러나, 이하 본 발명을 기술함에 있어서는 특별히 요구되지 않는 한 그 중간과정들에 대한 언급을 생략한다.
저장부(1020)는 자신의 상위에서 현재 동작 중인 소프트웨어 블록(111-1 내지 111-k)에 대한 정보 및 동작 중인 소프트웨어 블록(111-1 내지 111-k)에 대하여 본 발명에 따른 TCP 세션 커넥티비티 체크를 제공하기 위한 설정 값들을 저장한다. 저장부(1020)에 저장되는, TCP 세션 커넥티비티 체크를 실시하기 위한 설정 값들에 대해서는 후술하도록 한다.
제어부(1010)는 설정 값들에 따라 본 발명의 TCP 세션 커넥티비티 체크를 위한 SCC 메시지의 송신 조건 판단, TCP 커넥션의 이상 동작 여부 판단 등을 수행한다. 타이머(1030)는 SCC 메시지를 송신하기 위한 주기, SCC 응답 메시지가 수신되지 않는 시간의 판단 등을 위한 시간의 경과를 카운트한다.
다음으로, TCP/IP 커널(120)에서의 TCP 세션 커넥티비티 체크를 실시하기 위한 설정을 도면을 참조하여 설명한다.
도 11은 본 발명의 실시를 위해 사용되는 TCP 세션 커넥티비티 체크 옵션을 도시하는 도면이다.
도 11에 도시된 바와 같이, 본 발명에 따른 TCP 세션 커넥티비티 체크 옵션은 kind 필드(1100), Len 필드(1102), 확인(confirm) 필드(1104), strict 체크 필드(1106), 체크 간격 필드(1108), 종료 카운트 필드(1110)를 포함한다.
도 11에 도시된 실시예에서 kind=27로 설정된 kind 필드(1100)는 본 발명에 따른 TCP 커넥션 감시 기능이 설정됨을 나타내는 것이다. length = 7로 설정된 Len 필드(1102)는 그 길이를 나타낸다. 확인 필드(1104)는 해당 옵션이 적절히 설정되었음을 나타내는 값이다. strict 체크 필드(1106)는 SCC 메시지를 항상 송신할지 여부를 결정한다. 체크 간격 필드(1108)는 SCC 메시지를 송신할 주기를 정한다. 종료 카운트 필드(1110)는 SCC 메시지 또는 SCC 응답 메시지를 수신하지 못했을 경우 해당 TCP 세션을 차단하기 전에 재 전송할 SCC 메시지의 개수 또는 SCC 응답 메시지를 기다리는 시간을 나타낼 수 있다.
한편, 도 11에 도시된, 추가되는 소켓 옵션에 대한 프로그램 코드의 일 실시예를 보이면 다음과 같다.
struct tcp_scc {
intl_onoff;/* zero=off, nonzero=on */
intl_strict;/* zero=non strict, nonzero=strict */
intl_interval;/* seconds */
intl_count;
};
이 프로그램 코드를 사용하는 실시예에서는 TCP 세션 커넥티비티 체크를 위해 ON/OFF, strict, interval, count의 설정 값들이 적어도 사용된다. 여기서 ON/OFF는 본 발명에 따른 TCP 세션 커넥티비티 체크 기능의 사용여부를 나타내는 값으로, 도 11의 확인 필드(1104)의 값에 해당한다. strict는 주기적인 메시지의 송신 여부를 나타내는 값으로, strict 체크 필드(1106)의 값에 해당한다. interval은 메시지를 송신할 시간 간격을 나타내는 값으로, 체크 간력 필드(1108)의 값에 해당한다. count는 종료 카운트 필드(1110)의 값에 해당한다.
이 값들의 사용 예를 기술하면, 다음과 같다. ON/OFF 값은 "0" 또는 "1"의 두 값 중에서 선택할 수 있다. ON/OFF 값이 0이면 본 발명에 따른 TCP 세션 커넥티비티 체크 기능을 사용하지 않는 것으로 판단하고, ON/OFF 값이 1이면 TCP 세션 커넥티비티 체크 기능을 사용하는 것으로 판단한다. strict 값은 "0" 또는 "1"의 두 값 중에서 선택할 수 있다. strict 값이 0이면 TCP/IP 커널(120)은 주기적으로 SCC 메시지를 송신하여 TCP 세션 커넥티비티 체크를 수행한다. strict 값이 1이면 TCP/IP 커널(120)은 감시 대상인 TCP 커넥션 회선 상에 신호가 아무런 신호도 존재하지 않는 경우에 SCC 메시지를 송신하여 TCP 세션 커넥티비티 체크를 수행한다. SCC 메시지를 송신할 시간 간격을 의미하는 interval 값은 일반적으로 초단위로 설정될 수 있다. count 값은 대기 횟수를 나타내는 값 또는 대기 시간을 나타내는 값으로 설정될 수 있다.
이들 설정 값들은 S/W 블록(111 내지 119) 별로 적합하게 결정될 수 있으며, TCP/IP 커널(120)은 이 설정 값에 따라 TCP 세션 커넥티비티 체크 기능을 수행한 다. 도 11은 kind 필드(1100)를 27로, Len 필드(1102)를 7로 설정한 경우를 본 발명에 따른 일 실시예로써 도시하고 있다. 그러나, 도 11에 도시된 필드 값의 설정 값 및 각 필드의 크기에 대한 설정 값은 본 발명의 이해를 돕기 위해 예를 든 것으로, 본 발명은 이러한 구체적인 수치에 의해 한정되지 않는다.
도 12는 본 발명에 따른 도면으로, 세션 커넥티비티 체크 기능을 가지는 TCP 패킷 포맷을 나타내는 도면이다.
도 12에 도시된 바와 같이, 본 발명에서는 도 2에 도시된 TCP 패킷의 헤더부(200)에서 6비트의 예약 필드(210) 중의 한 비트를 TCP 세션 커넥티비티 체크(Session Connectivity Check, SCC; 이하 "커넥티비티 체크"라 칭한다) 플래그(1200)로 사용함으로써 커넥티비티 체크 기능을 가지는 TCP 패킷을 생성할 수 있다. 즉, 본 발명에 따른 TCP 패킷의 헤더부는 제어 플래그가 7비트가 된다. 기존의 제어 플래그들(214 내지 224)에 더하여지는 SCC 필드(1200)는 본 발명에 따른 커넥티비티 체크를 위해 사용된다.
최초의 TCP 커넥션 생성 시에 TCP 세션 커넥티비티 체크 옵션을 사용하여 두 S/W 블록들(111 내지 119)간에 설정된 TCP 커넥션을 감시하기 위한 협상을 수행한 이후 TCP 커넥션의 클라이언트 측에서는 TCP 커넥션의 서버 측에 도 12에 도시된 바와 같이 SCC 플래그(1200)를 포함하는 TCP 헤더를 가지는 TCP 패킷인 SCC 메시지를 송신하게 된다. 여기서 클라이언트는 TCP 커넥션의 설정을 요청한 S/W 블록(111 내지 119)의 하위에 존재하는 TCP/IP 커널(120)이 될 수 있으며, 서버는 클라이언트로부터 TCP 커넥션 설정을 요청 받은 S/W 블록(111 내지 119)의 하위에 존재하는 TCP/IP 커널(120)이 될 수 있다.
도 13과 도 14에 도시된 실시예들을 예로 들어 본 발명에 따른 TCP 세션 커넥티비티 체크 과정을 설명한다. 도 13 및 도 14는 strict가 "1"로 설정된 경우의 실시예들이다. 따라서, TCP/IP 커널(120)은 SCC 메시지를 항상 송신하지 않고, 해당 TCP 커넥션으로 아무런 트래픽이 들어오지 않는 경우에만 TCP 세션 커넥티비티 체크 과정을 시작한다.
도 13은 본 발명의 실시예에 따른 도면으로, 클라이언트 측에서의 TCP 세션 커넥티비티 체크 과정을 도시하는 순서흐름도이다.
도 13에 도시된 실시예는 서버(1310)에 이상이 발생했을 때 수행되는 과정이다. 도 13에 도시된 TCP 세션 커넥티비티 체크 과정을 간단히 3과정으로 나누면 다음과 같다.
① 클라이언트(1300)는 TCP 커넥션 생성 시에 SYNC에서 TCP 세션 커넥티비티 옵션에 설정된 주기에 따라 서버(1310)에 SCC 메시지를 송신한다. ② 클라이언트(1300)는 SCC 메시지 송신 후, SCC 응답 메시지가 수신되면 설정된 시간 후에 다음 SCC 메시지를 송신하기 위해 SCC 타이머(1030)를 동작시킨다. ③ 클라이언트(1300)는 SCC 메시지 송신 후, SCC 응답 메시지가 수신되지 않으면 설정된 카운트만큼 SCC 메시지를 재 전송하고, 설정된 카운트 내에 SCC 응답 메시지가 수신되지 않으면 해당 TCP 커넥션을 차단한다.
이 과정을 상세히 설명하면 다음과 같다.
도 13의 제 1320단계에서 클라이언트(1300)는 서버(1310)와 연결된 회선 상 에 트래픽이 없는지 판단한다. 즉, 클라이언트(1300)는 회선을 통해 송신되거나 수신되는 신호가 없는지 판단한다. 회선 상에 트래픽이 없다면 클라이언트(1300)는 SCC 타이머(1030)를 사용한 카운트를 시작한다.
제 1322단계에서 클라이언트(1300)는 SCC 타이머(1030)가 만기되었는지, 즉, 서버(1310)와의 사이에 트래픽이 없는 시간이 소정의 설정된 시간을 초과하였는지 판단한다. 설정된 시간 동안 클라이언트(1300)와 서버(1310) 사이의 회선에 트래픽이 없었다면 클라이언트(1300)는 서버(1310)와의 TCP 커넥션이 정상적으로 동작하고 있는지를 감시해야 할 필요가 있다고 판단한다. 클라이언트(1300)는 서버(1310)와의 TCP 커넥션을 감시하기 위해 서버(1310)에 SCC 메시지(1323)를 송신한다.
클라이언트(1300)로부터 SCC 메시지(1323)를 수신한 서버(1310)는 제 1324단계에서 SCC 타이머(1030)를 리셋한다. 서버(1310)는 SCC 메시지(1323)를 수신함으로써 클라이언트(1300)와의 회선 상에 트래픽이 발생한 것으로 판단하게 되기 때문이다. 서버(1310)는 SCC 메시지(1323)에 대한 응답 신호인 SCC 응답 메시지(1325)를 클라이언트(1300)에 송신하여 TCP 커넥션이 정상적으로 이루어지고 있음을 클라이언트(1300)에 통지한다.
서버(1310)로부터 SCC 응답 메시지(1325)를 수신한 클라이언트(1300)는 SCC 타이머(1030)를 리셋하고 다시 카운트를 시작한다. 클라이언트(1300)는 SCC 타이머(1030)가 만기될 때마다 서버(1310)에 SCC 메시지를 송신하고 그에 대한 SCC 응답 메시지를 수신함으로써 TCP 커넥션이 정상적으로 동작하고 있음을 확인한다.
한편, TCP 커넥션에 이상이 발생하여 두 S/W 블록들(111 내지 119) 간에 메시지가 정상적으로 전송되지 않는 경우라면, 클라이언트(1300)가 SCC 메시지를 송신해도 서버(1310)는 이에 대해 응답하지 못할 것이다. 그에 따른 과정이 도 13의 제 1326단계 내지 제 1346단계에 도시되어 있다.
제 1326단계에서 클라이언트(1300)는 SCC 타이머(1030)가 만기되었는지 판단한다. SCC 타이머(1030)가 만기되었다면 클라이언트(1300)는 다시 서버(1310)에 SCC 메시지(1327)를 송신한다. 그런데, 서버(1310)와의 TCP 커넥션이 비정상적으로 종료된 경우라면, 이 SCC 메시지(1327)는 서버(1310)에 전달될 수 없을 것이고, 서버(1310)는 이에 대해 응답할 수도 없을 것이다. 그러므로 클라이언트(1300)는 서버(1310)로부터 SCC 메시지(1327)에 대한 응답 메시지를 수신할 수 없게 된다.
제 1340단계에서 클라이언트(1300)는 SCC 메시지(1327)를 송신한 시점으로부터 카운트를 시작한 SCC 타이머(1030)가 만기되었는지 판단한다. SCC 타이머(1030)가 만기되었다면, 즉 클라이언트(1300)가 서버(1310)에 SCC 메시지(1327)를 송신하고 송신한 SCC 메시지에 대한 응답 메시지를 수신하지 못한 시간이 설정된 시간을 초과하는 것으로 판단되었다면 클라이언트(1300)는 제 1342단계에서 서버(1310)와의 TCP 커넥션이 비정상 종료된 것으로 판단할지 여부를 결정하기 위한 카운트를 시작한다. 제 1344단계에서 카운트 값이 소정의 임계치를 초과하는 것으로 판단되면, 클라이언트(1300)는 서버(1310)와의 TCP 커넥션이 비정상 종료된 것으로 판단하고, 제 1346단계에서 해당 TCP 커넥션을 종료한다.
그런데, 도 13에 도시된 경우와 달리 서버(1310) 측이 아닌 클라이언트(1300) 측에 이상이 발생하여 TCP 커넥션이 비정상적으로 동작하는 경우가 발생할 수도 있다. 이런 경우에는 서버(1310)가 TCP 커넥션의 정상 동작 여부를 판단해야 한다. 서버(1310)가 TCP 커넥션의 정상 동작 여부를 판단하는 과정을 도면을 참조하여 설명한다.
도 14는 본 발명의 실시예에 따른 도면으로, 서버 측에서의 TCP 세션 커넥티비티 체크 과정을 도시하는 순서흐름도이다.
도 14에 도시된 실시예는 클라이언트(1300)에 이상이 발생했을 때 수행되는 실시예이다. 도 14에 도시된 TCP 세션 커넥티비티 체크 과정을 간단히 3과정으로 나누면 다음과 같다.
① 서버(1310)는 최초 TCP 커넥션 생성 시에 사용되는 SYNC에 포함되는 TCP 세션 커넥티비티 옵션에 설정된 주기에 따라 클라이언트(1300) 측으로부터 SCC 메시지가 수신되기를 기다린다. ② SCC 타이머(1030)가 만기(expire)되기 전에 클라이언트(1300)로부터 SCC 메시지가 수신되면 서버(1310)는 SCC 응답 메시지를 클라이언트(1300) 측에 송신한 후, 다음 SCC 메시지가 설정된 시간 내에 수신되는지를 판단하기 위해 SCC 타이머(1030)를 동작시킨다. ③ SCC 타이머(1030)가 만기되었다면, 서버(1310)는 설정된 카운트 값 내에 SCC 메시지가 수신되는지를 판단하기 위해 SCC 타이머(1030)를 동작시키고, 설정된 카운트 값 내에 SCC 메시지가 수신되지 않으면 해당 TCP 커넥션을 차단한다.
이 과정을 상세히 설명하면 다음과 같다.
도 14의 제 1400단계에서 클라이언트(1300)는 서버(1310)와 연결된 회선 상 에 트래픽이 없는지 판단한다. 회선 상에 트래픽이 없다면 클라이언트(1300)는 SCC 타이머(1030)를 사용한 카운트를 시작한다.
제 1402단계에서 클라이언트(1300)는 SCC 타이머(1030)가 만기되었는지, 즉, 서버(1310)와의 사이에 트래픽이 없는 시간이 설정된 시간을 초과하였는지 판단한다. 설정된 시간 동안 클라이언트(1300)와 서버(1310) 사이의 회선에 트래픽이 없었다면 클라이언트(1300)는 서버(1310)와의 TCP 커넥션이 정상적으로 동작하고 있는지를 검사해야 할 필요가 있다고 판단한다. 클라이언트(1300)는 서버(1310)와의 TCP 커넥션을 검사하기 위해 서버(1310)에 SCC 메시지(1403)를 송신한다.
클라이언트(1300)로부터 SCC 메시지(1323)를 수신한 서버(1310)는 제 1404단계에서 SCC 타이머(1030)를 리셋한다. 서버(1310)는 SCC 메시지(1403)를 수신함으로써 클라이언트(1300)와의 회선 상에 트래픽이 발생한 것으로 판단하게 되기 때문이다. 서버(1310)는 SCC 메시지(1404)에 대한 응답 신호인 SCC 응답 메시지(1405)를 클라이언트(1300)에 송신하여 TCP 커넥션이 정상적으로 이루어지고 있음을 클라이언트(1300)에 통지한다.
그런데, SCC 메시지(1403)를 송신한 후에 클라이언트(1300) 측에 이상이 발생하여 제 1410단계와 같이 클라이언트(1300)가 다운되거나 TCP 커넥션이 비정상적으로 종료될 수가 있다. 임베디드 시스템이 효율적으로 동작하기 위해서는 이러한 클라이언트(1300)의 이상 여부를 서버(1310)가 판단할 수 있어야 한다.
클라이언트(1300)에 이상이 발생하는 경우, 서버(1310)는 클라이언트(1300)로부터 SCC 메시지를 수신할 수 없다. 따라서, 제 1404단계에서 리셋한 SCC 타이 머(1030)가 만기될 때까지 TCP 회선 상에는 어떠한 신호도 존재하지 않게 된다. 제 1420단계에서 SCC 타이머(1030)가 만기되면, 서버(1310)는 제 1422단계에서 클라이언트(1300)와의 TCP 커넥션이 비정상 종료된 것으로 판단할지 여부를 결정하기 위한 카운트를 시작한다. 제 1424단계에서 카운트 값이 소정의 임계치를 초과하는 것으로 판단되면, 서버(1310)는 클라이언트(1300)와의 TCP 커넥션이 비정상 종료된 것으로 판단하고, 제 1426단계에서 해당 TCP 커넥션을 종료한다.
한편, 도 13 및 도 14에 도시된 것은 strict 체크 필드(1106)의 값이 "1"로 설정된 경우, 즉 TCP/IP 커널(120)이 임의의 TCP 커넥션의 회선 상에 아무런 신호도 없을 때에 SCC 메시지를 송신하여 해당 TCP 커넥션의 상태를 감시하는 TCP 세션 커넥티비티 체크 과정에 대한 순서흐름도이다. 이와 달리 strict 체크 필드(1106)의 값이 "0"으로 설정된 경우, 즉 TCP/IP 커널(120)이 설정된 시간 간격에 따라 주기적으로 SCC 메시지를 송신하여 TCP 커넥션의 상태를 감시하는 경우에 클라이언트(1300)는 도 13의 제 1320단계 및 도 14의 제 1400단계의 회선 상에 트래픽이 존재하는지를 판단하는 과정을 생략하고 주기적으로 SCC 메시지를 송신하여 TCP 세션 커넥티비티 체크를 수행한다.
앞서 기술한, strict 값의 설정에 따라 SCC 메시지의 송신 조건을 달리하는 두 실시예를 그 효과 측면에서 고려해 보면 다음과 같은 차이점이 있을 수 있다. TCP 커넥션 상에 트래픽이 존재하지 않는 경우에만 SCC 메시지를 송신하는 첫 번째 실시예는 트래픽의 존재 여부에 관계없이 SCC 메시지를 송신하는 두 번째 실시예보다 더 적은 오버헤드를 발생하면서 TCP 세션 커넥티비티 체크를 수행할 수 있다. 그러나, 임의의 TCP 커넥션에 이상이 발생하였는데 그 회선 상에 이상동작에 따른 트래픽이 존재한다면 첫 번째 실시예로는 해당 TCP 커넥션의 이상 발생 여부를 판단할 수 없을 것이다. 그러므로, 본 발명에 따른 TCP 세션 커넥티비티 체크를 적용하고자 하는 시스템의 특성에 따라 어떤 실시예를 적용할 것인가를 판단하고 그에 따라 적절한 설정 값을 선택함이 바람직할 것이다.
다른 한편, 상술한 바와 같이, S/W 블록들(111 내지 119) 간에 설정된 TCP 커넥션의 상태를 검사함에 있어서는 그 TCP 커넥션의 설정을 요청한 쪽인 클라이언트(1300)가 TCP 커넥션 상태 검사의 주체가 됨이 바람직하나, 클라이언트(1300) 측에 이상이 발생하는 경우에 대비하여 서버(1310)가 본 발명에 따른 TCP 커넥션 상태 검사의 주체가 될 수도 있다. 즉, 서버(1310)가 SCC 메시지의 송신 조건을 판단하고, 조건이 충족될 시 클라이언트(1300)에 SCC 메시지를 송신하여 본 발명에 따른 TCP 커넥션 상태 검사를 수행할 수도 있다.
본 발명에서는 임베디드 시스템에서 시스템 커널 레벨에서 TCP 커넥션의 상태를 감시하는 기능을 구현함으로써 커넥션 상태 감시기능을 표준화 할 수 있고, 많은 어플리케이션 S/W 블록에서 구현해야할 기능을 시스템 커널에서 구현하여 해당 기능을 사용할 수 있는 옵션을 제공함으로써, 시스템의 개발기간 단축과 신뢰성을 향상시킬 수 있다.

Claims (15)

  1. 임의의 두 어플리케이션들간에 설정된 TCP(Transmission Control Protocol) 커넥션을 관리하는 장치에 있어서,
    상기 TCP 커넥션의 설정 정보 및 상기 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 위한 설정 값을 저장하고, 상기 설정 정보 및 설정 값에 따라 SCC(Session Connectivity Check) 메시지를 생성하여 상대 TCP/IP 커널에 송신하고, 상대 TCP/IP 커널로부터의 SCC 응답 메시지 수신 여부에 따라 상기 TCP 커넥션의 정상 동작 여부를 판단하는 TCP/IP 커널을 포함하는 TCP 커넥션 관리 장치.
  2. 제 1항에 있어서, 상기 TCP/IP 커널은,
    상기 두 어플리케이션들간의 TCP 커넥션에 대한 설정 정보 및 상기 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 위한 설정 값을 저장하는 저장부와,
    상기 설정 정보 및 설정 값을 참조하여 SCC 메시지를 생성하고, SCC 메시지를 송신할 시간인지를 판단하여 SCC 메시지의 송신이 요청되는 시간에 상기 생성된 SCC 메시지를 출력하고, 상기 상대 TCP/IP 커널로부터의 SCC 응답 메시지 송신 여부에 따라 상기 TCP 커넥션의 정상 동작 여부를 판단하는 제어부와,
    상기 제어부로부터 SCC 메시지를 입력받아 상기 상대 TCP/IP 커널에 송신하는 입출력부와,
    상기 SCC 메시지를 송신할 시간인지를 판단하기 위한 타이머를 포함하는 TCP 커넥션 관리 장치.
  3. 제 1항에 있어서,
    상기 TCP 커넥션으로 연결된 두 어플리케이션들 중 상기 TCP/IP 커널의 상위 계층에 존재하는 어플리케이션이 상기 TCP 커넥션 생성 및 생성되는 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 상기 TCP/IP 커널에 요청하는 TCP 커넥션 관리 장치.
  4. 제 3항에 있어서,
    상기 TCP/IP 커널은 상기 어플리케이션으로부터 상기 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 요청 받은 경우에만 상기 TCP 커넥션에 대한 TCP 세션 커넥티비티 체크를 수행하는 TCP 커넥션 관리 장치.
  5. 제 1항에 있어서, 상기 SCC 메시지 및 상기 SCC 응답 메시지는 자신이 TCP 커넥션의 연결 상태 감시를 위한 패킷임을 표시하는 제어 플래그인 SCC 플래그를 포함하는 TCP 패킷인 TCP 커넥션 관리 장치.
  6. 제 1항에 있어서, 상기 상대 TCP/IP 커널에 SCC 메시지를 송신한 TCP/IP 커널은 상대 TCP/IP 커널로부터의 SCC 응답 메시지가 일정시간 이상 수신되지 않으면 상기 두 어플리케이션들 간의 TCP 커넥션에 이상이 발생한 것으로 판단하는 TCP 커넥션 관리 장치.
  7. 제 1항에 있어서, 상기 TCP 세션 커넥티비티 체크를 위한 설정 값은 TCP 세션 커넥티비티 체크 기능의 실행 여부를 지시하는 값을 포함하는 TCP 커넥션 관리 장치.
  8. 제 1항에 있어서, 상기 TCP 세션 커넥티비티 체크를 위한 설정 값은 상기 SCC 메시지의 송신 조건을 지시하는 값인 strict 값을 포함하는 TCP 커넥션 관리 장치.
  9. 제 8항에 있어서, 상기 strict 값이 설정되어 있으면, 상기 TCP/IP 커널은 주기적으로 상기 상대 TCP/IP 커널에 SCC 메시지를 송신하고, 상대 TCP/IP 커널로 부터의 SCC 응답 메시지가 일정시간 이상 수신되지 않으면 상기 두 어플리케이션들 간의 TCP 커넥션이 단절된 것으로 판단하는 TCP 커넥션 관리 장치.
  10. 제 8항에 있어서, 상기 strict 값이 설정되어 있지 않으면, 상기 TCP/IP 커널은 상기 두 어플리케이션들 간의 TCP 회선 상에 신호가 존재하지 않을 때에 SCC 메시지를 송신하고, 상대 TCP/IP 커널로부터의 SCC 응답 메시지가 일정시간 이상 수신되지 않으면 상기 두 어플리케이션들 간의 TCP 커넥션이 단절된 것으로 판단하는 TCP 커넥션 관리 장치.
  11. 제 1항에 있어서, 상기 TCP 연결 상태 감시를 위한 설정 값은 상기 SCC 메시지를 송신할 주기를 설정하는 값인 TCP 커넥션 관리 장치.
  12. 제 1항에 있어서, 상기 TCP/IP 커널은 상기 두 어플리케이션들 간의 TCP 연결에 이상이 발생한 것으로 판단되면, 상기 TCP 연결을 차단하는 TCP 커넥션 관리 장치.
  13. 임의의 두 어플리케이션들간에 설정된 TCP 커넥션을 관리하는 방법에 있어서,
    상기 TCP 커넥션이 TCP 세션 커넥티비티 체크를 요청하는 TCP 커넥션인지 판단하는 제 1과정과,
    TCP 세션 커넥티비티 체크를 위한 SCC 메시지를 생성하는 제 2과정과,
    상기 생성된 SCC 메시지를 상기 TCP 커넥션을 통해 연결되는 상대 TCP/IP 커널에 송신하는 제 3과정과,
    상기 상대 TCP/IP 커널로부터 상기 SCC 메시지에 대한 응답 메시지가 소정의 시간 내에 수신되는지 판단하고, 상기 응답 메시지가 상기 시간 내에 수신되지 않으면 상기 TCP 커넥션이 정상 동작하지 않는 것으로 판단하는 제 4과정을 포함하는 TCP 커넥션 관리 방법.
  14. 제 13항에 있어서,
    상기 정상동작하지 않는다고 판단된 TCP 커넥션을 차단하는 제 5과정을 더 포함하는 TCP 커넥션 관리 방법.
  15. 임의의 두 어플리케이션들간에 설정된 TCP 커넥션을 관리하는 방법에 있어서,
    상기 TCP 커넥션이 TCP 세션 커넥티비티 체크를 요청하는 TCP 커넥션인지 판단하는 제 1과정과,
    상기 TCP 커넥션 회선 상에 트래픽이 존재하는지 판단하는 제 2과정과,
    상기 TCP 커넥션 회선 상에 트래픽이 존재하지 않으면, TCP 세션 커넥티비티 체크를 위한 SCC 메시지를 생성하여 상기 TCP 커넥션을 통해 연결되는 상대 TCP/IP 커널에 송신하는 제 3과정과,
    상기 상대 TCP/IP 커널로부터 상기 SCC 메시지에 대한 응답 메시지가 소정의 시간 내에 수신되는지 판단하고, 상기 응답 메시지가 상기 시간 내에 수신되지 않으면 상기 TCP 커넥션이 정상 동작하지 않는 것으로 판단하는 제 4과정을 포함하는 TCP 커넥션 관리 방법.
KR20040009774A 2004-02-13 2004-02-13 Ｔｃｐ 커넥션 관리 장치 및 방법 KR100602651B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR20040009774A KR100602651B1 (ko) 2004-02-13 2004-02-13 Ｔｃｐ 커넥션 관리 장치 및 방법
JP2005029537A JP2005228316A (ja) 2004-02-13 2005-02-04 Ｔｃｐコネクション管理装置、ｔｃｐコネクション管理方法及びプログラム保存装置
CNA2005100078929A CN1655552A (zh) 2004-02-13 2005-02-06 管理传输控制协议(tcp)连接
US11/052,095 US7532577B2 (en) 2004-02-13 2005-02-08 Managing transmission control protocol (TCP) connections

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20040009774A KR100602651B1 (ko) 2004-02-13 2004-02-13 Ｔｃｐ 커넥션 관리 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20050081513A KR20050081513A (ko) 2005-08-19
KR100602651B1 true KR100602651B1 (ko) 2006-07-19

Family

ID=34836759

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20040009774A KR100602651B1 (ko) 2004-02-13 2004-02-13 Ｔｃｐ 커넥션 관리 장치 및 방법

Country Status (4)

Country Link
US (1) US7532577B2 (ko)
JP (1) JP2005228316A (ko)
KR (1) KR100602651B1 (ko)
CN (1) CN1655552A (ko)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8935405B2 (en) * 2005-03-07 2015-01-13 Nokia Corporation Expanding universal plug and play capabilities in power constrained environment
KR100734110B1 (ko) * 2006-02-09 2007-06-29 주식회사 팬택앤큐리텔 Ｔｃｐ단에서의 서버 에러 복구 방법
US7733774B1 (en) * 2007-06-07 2010-06-08 Symantec Corporation Method and apparatus for detecting process failure
KR100889670B1 (ko) * 2007-08-08 2009-03-19 삼성에스디에스 주식회사 모바일 디바이스상에서 ｔｃｐ 기반의 서비스거부 공격의 차단 방법
US8099505B2 (en) * 2008-03-26 2012-01-17 Microsoft Corporation Aggregating connection maintenance to optimize resource consumption
JP5112138B2 (ja) * 2008-03-28 2013-01-09 株式会社日立製作所 セッション管理方法、ストレージ装置、及び、計算機システム
JP5051056B2 (ja) * 2008-08-13 2012-10-17 富士通株式会社 通信システム
US8018863B2 (en) * 2008-09-09 2011-09-13 Telefonaktiebolaget L M Ericsson Reducing CC message transmission in a provider network
GB2464127B (en) * 2008-10-04 2012-10-24 Mingoa Ltd Detection of link connectivity in communication systems particularly ethernet oam system during start-up
CN101924744A (zh) * 2009-06-10 2010-12-22 中兴通讯股份有限公司 一种融合ip消息消息会话中继协议msrp参数协商的方法
US9106531B2 (en) * 2010-03-30 2015-08-11 Mingoa Limited Detection of link connectivity in communication systems
CN102238043A (zh) * 2010-05-05 2011-11-09 东方宇阳信息科技(北京)有限公司 一种基于客户端检测可靠连接是否有效的方法
US8706889B2 (en) * 2010-09-10 2014-04-22 International Business Machines Corporation Mitigating connection identifier collisions in a communication network
KR101141164B1 (ko) * 2010-11-17 2012-05-02 삼성에스디에스 주식회사 어플리케이션간 메시지 교환 시스템 및 방법
KR101788639B1 (ko) * 2011-01-10 2017-10-20 삼성전자 주식회사 휴대 단말기의 네트워크 접속 또는 해제 방법 및 장치
US9351331B2 (en) * 2012-04-18 2016-05-24 Qualcomm Incorporated Invasive socket manager
JP5756430B2 (ja) * 2012-06-05 2015-07-29 株式会社日立製作所 網監視装置
CN103297430B (zh) * 2013-05-24 2017-04-26 华为技术有限公司 数据传输方法及设备
KR101842666B1 (ko) * 2013-10-10 2018-05-14 구글 엘엘씨 통신들을 관리하기 위한 시스템들, 방법들 및 컴퓨터 프로그램 제품들
KR20150084307A (ko) * 2014-01-13 2015-07-22 삼성전자주식회사 네트워크에서 웹 로딩 시간 제어 방법 및 장치
CN104503850B (zh) * 2014-12-11 2017-10-31 天津中兴智联科技有限公司 嵌入式系统通信方法
US10412198B1 (en) * 2016-10-27 2019-09-10 F5 Networks, Inc. Methods for improved transmission control protocol (TCP) performance visibility and devices thereof
US11122483B2 (en) * 2016-11-21 2021-09-14 Huawei Technologies Co., Ltd. Network standard switching method and apparatus, and device
CN107070970B (zh) * 2016-12-29 2020-07-03 北京奇艺世纪科技有限公司 一种传输控制协议tcp连接的关闭方法及装置
US11223689B1 (en) 2018-01-05 2022-01-11 F5 Networks, Inc. Methods for multipath transmission control protocol (MPTCP) based session migration and devices thereof

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05204807A (ja) * 1992-01-29 1993-08-13 Fujitsu Ltd テスト・プログラムによるｔｃｐ／ｉｐのエンド・システム間の接続確認テスト方法

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212175B1 (en) * 1997-04-22 2001-04-03 Telxon Corporation Method to sustain TCP connection
US5978849A (en) 1997-06-13 1999-11-02 International Business Machines Corporation Systems, methods, and computer program products for establishing TCP connections using information from closed TCP connections in time-wait state
JPH1132084A (ja) 1997-07-11 1999-02-02 Nec Corp 通信接続制御方式
US7225249B1 (en) * 1997-09-26 2007-05-29 Mci, Llc Integrated systems for providing communications network management services and interactive generating invoice documents
US6330226B1 (en) 1998-01-27 2001-12-11 Nortel Networks Limited TCP admission control
US6484174B1 (en) * 1998-04-20 2002-11-19 Sun Microsystems, Inc. Method and apparatus for session management and user authentication
JP3602972B2 (ja) 1998-07-28 2004-12-15 富士通株式会社 通信性能測定装置及びその測定方法
US7002988B1 (en) * 1998-12-04 2006-02-21 Tekelec Methods and systems for communicating SS7 messages over packet-based network using transport adapter layer interface
JP3436218B2 (ja) * 1999-12-03 2003-08-11 日本電気株式会社 Ｔｃｐ／ｉｐネットワーク装置の電源遮断方法およびそのプログラムを記録した記録媒体
US7213063B2 (en) * 2000-01-18 2007-05-01 Lucent Technologies Inc. Method, apparatus and system for maintaining connections between computers using connection-oriented protocols
FR2805112B1 (fr) 2000-02-11 2002-04-26 Mitsubishi Electric Inf Tech Procede et unite de controle de flux d'une connexion tcp sur un reseau a debit controle
US6981180B1 (en) * 2000-03-16 2005-12-27 Akamai Technologies, Inc. Method and apparatus for testing request-response service using live connection traffic
JP2001345829A (ja) 2000-06-06 2001-12-14 Ntt Communications Kk 狭域通信システム
US7219158B2 (en) * 2000-07-21 2007-05-15 Hughes Network Systems Llc Method and system for improving network performance using a performance enhancing proxy
US6839344B1 (en) * 2000-12-19 2005-01-04 Nortel Networks Limited Transport mechanism for ISDN backhaul over IP
US20020078135A1 (en) * 2001-03-15 2002-06-20 Ibm Corporation Method and apparatus for improving the operation of an application layer proxy
EP1402355B1 (en) 2001-05-23 2018-08-29 Tekelec Global, Inc. Methods and systems for automatically configuring network monitoring system
US6832260B2 (en) * 2001-07-26 2004-12-14 International Business Machines Corporation Methods, systems and computer program products for kernel based transaction processing
US7152185B2 (en) * 2002-02-22 2006-12-19 Bea Systems, Inc. Method for event triggered monitoring of managed server health
US7299264B2 (en) 2002-05-07 2007-11-20 Hewlett-Packard Development Company, L.P. System and method for monitoring a connection between a server and a passive client device
US8090836B1 (en) * 2002-06-10 2012-01-03 Symantec Operating Corporation TCP connection migration
US6721907B2 (en) * 2002-06-12 2004-04-13 Zambeel, Inc. System and method for monitoring the state and operability of components in distributed computing systems
CN1251446C (zh) * 2002-07-18 2006-04-12 华为技术有限公司 一种防御网络传输控制协议同步报文泛滥攻击的方法
TW576045B (en) * 2002-09-20 2004-02-11 Ind Tech Res Inst System for controlling network flow by monitoring download bandwidth
US20050086342A1 (en) * 2003-09-19 2005-04-21 Andrew Burt Techniques for client-transparent TCP migration
US20050105508A1 (en) * 2003-11-14 2005-05-19 Innomedia Pte Ltd. System for management of Internet telephony equipment deployed behind firewalls

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05204807A (ja) * 1992-01-29 1993-08-13 Fujitsu Ltd テスト・プログラムによるｔｃｐ／ｉｐのエンド・システム間の接続確認テスト方法

Also Published As

Publication number Publication date
KR20050081513A (ko) 2005-08-19
JP2005228316A (ja) 2005-08-25
US7532577B2 (en) 2009-05-12
CN1655552A (zh) 2005-08-17
US20050180419A1 (en) 2005-08-18

Similar Documents

Publication Publication Date Title
KR100602651B1 (ko) Ｔｃｐ 커넥션 관리 장치 및 방법
KR100990415B1 (ko) 데이터 통신에서의 접속 상태를 동기화하는 방법 및 이를 사용하는 통신 노드
CN1633647B (zh) 用于管理网络中的数据传送的系统、方法
EP2230813B1 (en) A method and node for establishing a network connection by way of a connectionless transport layer protocol
EP1859594B1 (en) Server side tftp flow control
TWI555363B (zh) Transmission control protocol communication method and server
JP2006164252A (ja) ウェブサービス環境用の信頼できるメッセージング内の接続生存性の検証および維持
JP2001514773A (ja) 信頼性のあるイベントデリバリシステム
CN111147573A (zh) 一种数据传输的方法和装置
CN111711680A (zh) 基于udp协议的文件断点续传方法及装置
EP2692115B1 (en) Sctp endpoint migration
JP2007183738A (ja) 情報処理装置および方法、並びにプログラム
JP2006229399A (ja) 通信システム、中継ノード及びそれらに用いる通信方法並びにそのプログラム
US8392780B2 (en) Communication control method
CN115801642B (zh) 基于状态控制的rdma通讯管理模块、方法、设备及介质
KR20170126808A (ko) 단말 및 그 통신 방법
WO2007124629A1 (fr) Procédé de traitement de message lmp, unité et noeud de traitement de message lmp
JP2581476B2 (ja) 情報処理装置
JP4229596B2 (ja) サーバ監視方式
JPH05122278A (ja) 交換機の端末制御方式
JPH08298535A (ja) Ｏｓｉ通信システム
JPH11249978A (ja) データ転送方法および装置
KR20150009910A (ko) 컨트롤러와 네트워크 장치 간 연결 상태 확인 방법
JP2004260562A (ja) パケット送受信方法、及び装置
JP2004056306A (ja) 通信制御システム、通信制御方法、中継装置及び通信制御プログラム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130627

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20140627

Year of fee payment: 9

LAPS Lapse due to unpaid annual fee