KR100914308B1 - 티씨피 처리 시스템 및 그 제어방법 - Google Patents

티씨피 처리 시스템 및 그 제어방법 Download PDF

Info

Publication number
KR100914308B1
KR100914308B1 KR1020070090691A KR20070090691A KR100914308B1 KR 100914308 B1 KR100914308 B1 KR 100914308B1 KR 1020070090691 A KR1020070090691 A KR 1020070090691A KR 20070090691 A KR20070090691 A KR 20070090691A KR 100914308 B1 KR100914308 B1 KR 100914308B1
Authority
KR
South Korea
Prior art keywords
state machine
function
tcp
address
machine object
Prior art date
Application number
KR1020070090691A
Other languages
English (en)
Other versions
KR20090025673A (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 KR1020070090691A priority Critical patent/KR100914308B1/ko
Publication of KR20090025673A publication Critical patent/KR20090025673A/ko
Application granted granted Critical
Publication of KR100914308B1 publication Critical patent/KR100914308B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • 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)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

티씨피 처리 시스템 및 그 제어방법이 개시된다.
본 발명에 따른 티씨피 처리 시스템은, TCP 처리 시 발생하는 이벤트 메시지에 의해 전이되는 TCP 처리 상태에 따라 실행되는 각 함수들을 분리하여 구성한 상태 기계 오브젝트와; 상기 이벤트 메시지에 따라 상기 상태 기계 오브젝트를 호출하여 해당 함수를 실행하는 프레임 워크와; 상기 프레임 워크가 상기 상태 기계 오브젝트를 호출하여 실행시킬 수 있도록, 상기 상태 기계 오브젝트의 주소를 상기 프레임 워크에 등록하는 데이터 재구성 로더를 포함한다.
본 발명에 의하면, 바이너리 수준의 부분적인 TCP 코드 갱신이 가능하고 세션의 재연결 없이 적은 오버헤드로 새로운 TCP를 재구성할 수 있으며, 각기 다른 TCP 버전들을 보유한 운영체제 간에도 TCP 기반 데이터 전송을 용이하게 수행할 수 있다.

Description

티씨피 처리 시스템 및 그 제어방법{TCP processing system and method of controlling the same}
본 발명은 TCP(Transmission Control Protocol)처리 시스템 및 그 제어방법에 관한 것으로서, 더욱 상세하게는, 각 통신 상황에 부합되도록 TCP를 동적으로 재구성 및 확장할 수 있도록 하여, 각기 다른 TCP 버전들을 보유한 운영체제 간에도 TCP 기반 데이터 전송을 용이하게 수행할 수 있도록 하는 TCP 처리 시스템 및 그 제어방법에 관한 것이다.
TCP(Transmission Control Protocol)는 전송 계층에 위치한 프로토콜로써 각종 네트워크 통신에 널리 사용되고 있다. 그런데, 표준 TCP는 유선 인터넷 환경을 대상으로 하여 설계된 프로토콜이기 때문에, 무선 환경과 같이 전송 조건이 상이한 상태에서 표준 TCP 제어방식을 그대로 적용하는 경우 극심한 성능 저하 현상을 보여 왔다. 예컨대, 표준 TCP는 패킷이 손실될 경우 이를 혼잡(congestion)으로 간주하여 전송량을 감소시키는 제어를 수행한다. 이는, 유선 환경에서는 적절한 제어방법으로 간주할 수 있다. 그러나, 무선 환경에서는 혼잡 상황뿐만 아니라 무선 채널의 불안정성으로 인해 패킷의 손실이 발생하기도 함으로, 혼잡 상황이 아닌 무선 환경에서 표준 TCP 방식으로 제어하는 경우, 불필요한 전송률 감소로 인해 성능이 저하되는 현상이 발생할 수 있다. 이에, 전송 조건에 따라 발생할 수 있는 표준 TCP의 문제점을 개선하여, TCP Vegas, Westwood, BIC, CUBIC, Hybla, Veno 등의 다양한 버전의 TCP가 개발되었다.
한편, 일반적인 운영체제의 경우 TCP/IP를 사용하는 애플리케이션은 소켓 인터페이스를 사용하며, 이때 SOCK_STREAM이란 인자를 통해 내부적으로 표준 TCP 함수들과 자동으로 연결된다. 즉, 기존의 소켓 인터페이스로는 다른 버전의 TCP를 사용할 수 없음으로, 다양한 버전의 TCP를 적용하는 것이 사실상 불가능하다. 또한, 별도의 인터페이스 수정을 통해 표준 TCP가 아닌 다른 버전의 TCP를 사용할 수 있는 경우에도, 일부 버전들은 통신을 수행하는 상대방이 동일한 버전의 TCP를 사용하는 경우에 한해 통신이 가능하다.
이에, 각기 다른 버전의 TCP를 사용하는 운영체제 간 통신을 위한 기술이, “Upgrading Transport Protocols using Untrusted Mobile Code”의 논문(저자: P. Patel, A. Whitaker, D. Wetherall, J. Lepreau, T. Stack., 출판: 2003년 ACM Symposium on Operating Systems Principles 학술대회의 프로시딩)에서 제안된바 있다. 상기 논문에서 제시된 기술에 따르면, 상대방이 자신과 동일한 종류의 TCP를 가지고 있지 않을 경우, 먼저 표준 TCP로 세션을 연결하고 동시에 자신이 가지고 있는 새로운 TCP의 소스 코드를 상대방에게 전송한다. 새 TCP의 전송이 완료되면 상대방은 이를 컴파일하고 커널 내에 로드한다. 이후에는 기존의 표준 TCP로 연결된 세션을 종료하고 새로운 TCP로 세션을 다시 연결하여 통신을 수행하는 기술이 다.
그런데, 종래에 개시된 기술은 다음과 같은 문제점들을 가지고 있다.
첫째, 새로 개발된 TCP 기반 기술들은 대부분 표준 TCP 코드를 바탕으로 일부 알고리즘만을 수정하고 있다. 그런데, 종래의 TCP 처리 기술의 경우 TCP 전체 코드를 전송하여 갱신하도록 하고 있어, 표준 TCP와 동일한 구조를 갖는 부분에 대해서도 데이터를 송수신하여 갱신하여야 한다. 이는, 현재의 TCP/IP 스택의 구현 구조상 코드의 부분적인 갱신이 사실상 불가능하기 때문이다. 따라서, 새로운 TCP 구성을 사용하고자 하는 경우 중복되는 코드까지 모두 송수신하여 갱신해야함으로, 네트워크와 TCP 처리 시스템에 로드를 유발하게 되는 문제점이 있다.
둘째, TCP 코드의 경우 그 용량이 크기 때문에, 새로운 TCP 구성을 사용하기 위해 전체 TCP 코드를 송수신하는 경우 다운로드 시간이 늘어날 뿐 아니라, 수신한 시스템에서 이를 적용하고자 하는 경우 바이너리 수준의 코드와는 달리, 별도의 컴파일 과정을 거처야만 한다. 따라서, 전체 갱신 시간은 늘어날 수밖에 없으며, 더구나 PDA와 같은 모바일 핸드 헬드(hand-held) 단말에서는 대개 컴파일을 위한 개발 환경을 가지고 있지 않기 때문에 소스 수준의 코드를 처리하는 것이 사실상 불가능하다는 문제점이 있다. 즉, TCP 코드 전체를 송수신 및 처리하기 위해서는 별도의 TCP 코드의 컴파일을 위한 펌웨어 구성이 탑재되어야 한다는 문제점이 있다.
마지막으로, 새로 받은 TCP를 사용하기 위해서는 기존의 표준 TCP 세션을 끊고 다시 연결하는 과정을 거쳐야 한다. 따라서, TCP의 전송 윈도가 처음부터 다시 증가해야하므로 데이터 처리량이 크게 감소되는 문제점이 있다.
본 발명은 전술한 문제점을 해결하기 위해 안출 된 것으로서, 바이너리 수준의 부분적인 TCP 코드 갱신이 가능하고 세션의 재연결 없이 적은 오버헤드로 새로운 TCP를 재구성할 수 있도록 함으로써, 각기 다른 TCP 버전들을 보유한 운영체제 간에도 TCP 기반 데이터 전송을 용이하게 수행할 수 있도록 하는 TCP 처리 시스템 및 그 제어방법을 제공함에 그 목적이 있다.
전술한 목적을 달성하기 위해 본 발명은, TCP 처리 시 발생하는 이벤트 메시지에 의해 전이되는 TCP 처리 상태에 따라 실행되는 각 함수들을 분리하여 구성한 상태 기계 오브젝트와; 상기 이벤트 메시지에 따라 상기 상태 기계 오브젝트를 호출하여 해당 함수를 실행하는 프레임 워크와; 상기 프레임 워크가 상기 상태 기계 오브젝트를 호출하여 실행시킬 수 있도록, 상기 상태 기계 오브젝트의 주소를 상기 프레임 워크에 등록하는 데이터 재구성 로더를 포함하는 것을 특징으로 하는 TCP 처리 시스템을 제공한다.
그리고, 전술한 목적을 달성하기 위해 본 발명은, (a)TCP 처리 시 발생하는 이벤트 메시지에 의해 전이되는 TCP 처리 상태에 따라 실행되는 각 함수들을 분리하여 상태 기계 오브젝트를 구성하는 단계와; (b)상기 TCP를 처리하는 프레임 워크에 상기 상태 기계 오브젝트의 주소를 등록하는 단계와; (c)상기 프레임 워크가 상기 TCP 처리시 발생하는 이벤트 메시지에 따라 해당 상태 기계 오브젝트를 상기 주소를 통해 호출하여 해당 함수를 실행하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법을 제공한다.
또한, 전술한 목적을 달성하기 위해 본 발명은, 표준 TCP를 수정한 TCP2를 사용하는 제1 호스트가 3방향 핸드셰이킹(3-way handshaking)을 통해 제2 호스트에 TCP 세션 연결을 요청하는 단계와; 상기 제2 호스트가 상기 TCP2를 처리하기 위한 데이터 재구성 로더 및 기타 컴포넌트를 가지고 있는지 확인하는 단계와; 확인 결과, 상기 제2 호스트에 상기 TCP2의 처리를 위한 구성이 구비되어 있지 아니할 경우, 표준 TCP로 세션을 설정하는 단계와; 상기 표준 TCP로 설정된 세션을 통해 상기 제2 호스트가 상기 제1 호스트로부터 상기 TCP2의 처리를 위한 상기 데이터 재구성 로더 및 기타 컴포넌트를 다운로드 받는 단계와; 상기 다운로드가 완료되면 상기 데이터 재구성 로더가 상기 TCP2를 처리하는 프레임 워크를 실행시켜 상기 다운로드된 정보를 상기 제2 호스트에 등록하고 상기 다운로드된 컴포넌트들을 커널 주소 공간에 로딩하는 단계와; 기존 표준 TCP의 세션상에서 상기 TCP2의 수정 부분만을 교체하여 상기 세션의 종료 없이 상기 TCP2에 따라 상기 제1 호스트 및 제2 호스트 간 통신을 수행하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법을 제공한다.
이러한 구성을 갖는, 본 발명의 TCP 처리 시스템 및 그 제어방법에 따르면, 바이너리 수준의 부분적인 TCP 코드 갱신이 가능하고 세션의 재연결 없이 적은 오버헤드로 새로운 TCP를 재구성할 수 있다. 이에 따라, 각기 다른 TCP 버전들을 보 유한 운영체제 간에도 TCP 기반 데이터 전송을 용이하게 수행할 수 있다.
이하, 본 발명의 바람직한 실시예를 첨부도면에 의거하여 상세히 설명하기로 한다. 그러나, 다음에 예시하는 본 발명의 실시예는 여러 가지 다른 형태로 변형할 수 있으며, 본 발명의 범위가 다음에 상술하는 실시예에 한정되는 것은 아니다. 본 발명의 실시예는 당 업계에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위하여 제공된다.
도 1은 TCP 기반 데이터 송수신 동작의 상태 전이 다이어그램이다. 도 1에 도시된 바와 같이, TCP를 기반으로 데이터를 송수신하는 경우 각 상태에 따라 전달되는 메시지에 의해 그 처리상태가 전이된다. 이하 설명에서 연결 요청을 시도하는 측을 클라이언트로, 연결 요청을 수락하는 측을 서버로 가정하기로 한다.
서버는 CLOSED, LISTEN, SYN-RCVD, ESTABLISHED, CLOSE-WAIT, LAST-ACK 중 하나의 상태에 있을 수 있다.
서버는 CLOSED 상태에서부터 시작한다(P10).
CLOSED 상태에 있는 서버가 서버 응용프로그램으로부터 수동 개발(passive open) 요구를 수신하면 서버는 LISTEN 상태로 전환된다(P12).
LISTEN 상태에 있는 서버가 클라이언트로부터 SYN 메시지를 수신하면 서버는 클라이언트로 SYN+ACK 메시지를 전송하고 SYN-RCVD 상태로 전환된다(P14).
SYN-RCVD 상태에 있는 서버가 클라이언트로부터 ACK 메시지를 수신하면, 서버는 ESTABLISHED 상태로 전환된다(P16).
ESTABLISHED 상태는 데이터 전송상태로서, 서버는 데이터를 송수신하는 동안 ESTABLISHED 상태로 유지된다. ESTABLISHED 상태에 있는 서버가 클라이언트로부터 연결을 종료하기 위한 FIN 메시지를 수신하면, 서버는 클라이언트에게 ACK 메시지를 전송하고 CLOSE-WAIT 상태로 전환된다(P28).
CLOSE-WAIT 상태에서 서버는 프로그램으로부터 종료 요구 메시지를 수신할 때까지 대기하며, 종료 요구가 수신되면, 서버는 클라이언트에게 FIN 메시지를 전송하고 LAST-ACK 상태로 전환된다(P30).
LAST-ACK 상태에서, 서버는 마지막 ACK 메시지를 기다리며, ACK 메시지를 수신하면 CLOSED 상태로 전환된다(P10).
한편, 클라이언트는, CLOSED, SYN-SENT, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2와 TIME-WAIT 중의 하나의 상태에 있을 수 있다.
클라이언트는 CLOSED 상태에서부터 시작한다(P10).
CLOSED 상태에 있는 클라이언트가 클라이언트 응용프로그램으로부터 능동 개발(active open) 요구를 수신하면, 클라이언트는 서버로 SYN 메시지를 전송하고 SYN-SENT 상태로 전환된다(P26).
SYN-SENT 상태에 있는 클라이언트가 서버로부터 SYN+ACK 메시지를 수신하면, 클라이언트는 서버에게 ACK 메시지를 전송하고 ESTABLISHED 상태로 전환된다(P16).
ESTABLISHED는 데이터 전달 상태로서, 클라이언트는 데이터를 송수신하는 동안 ESTABLISHED 상태로 유지된다. ESTABLISHED 상태에 있는 클라이언트가 클라이언트 프로그램으로부터 해지 요구를 수신하면, 클라이언트는 서버에게 FIN 메시지를 전송하고 FIN-WAIT-1 상태로 전환된다(P18).
FIN-WAIT-1 상태에 있는 클라이언트는 서버로부터 ACK 메시지를 수신하기를 기다린다. ACK 메시지가 수신되면, 클라이언트는 FIN-WAIT-2 상태로 전환된다(P22). FIN-WAIT-2 상태의 클라이언트는 아무것도 전송하지 아니하며 이 상태에서 한 방향의 연결은 종료된다.
FIN-WAIT-2 상태에 있는 클라이언트는 서버가 서버-클라이언트 방향으로의 연결을 종료하기를 기다린다. 만일, 클라이언트가 상대방으로부터 FIN 메시지를 수신하면, 클라이언트는 ACK 메시지를 전송하고 TIME-WAIT 상태로 전환된다(P24).
한편, 상술한 과정에서, 데이터를 송수신하는 ESTABLISHED 상태는 패킷 전송(output)과 관련된 또 하나의 하위 레벨 전송 흐름을 가지고 있다.
도 2는, 도 1의 ESTABLISHED 상태에서 진행되는 하위 레벨의 상태 전이 다이어그램을 도시한 것으로서, 데이터 송신 시 재전송과 신속 재전송 및 복구를 수행하는 경우의 상태 전이 다이어그램을 도시한 것이다.
ESTABLISHED 상태에서는 데이터 송수신이 가능하며, 송수신 중인 데이터가 없는 경우 TCP는 전송 대기 상태인 IDLE 상태를 유지한다(P40).
IDLE 상태에서, SEND 메시지가 수신되면 TRANSMIT 상태로 전환되어 데이터를 송수신하게 된다(P42).
TRANSMIT 상태에서 데이터 송신 후 ACK 메시지가 수신되면 다시 IDLE 상태로 복귀하나, ACK 메시지가 수신되지 아니한 상태에서 재전송 타이머 만료(retransmission timer expires) 메시지가 수신되면 재전송 상태인 RETRANSMIT 상태로 전환된다(P44).
또한, TRANSMIT 상태에서 데이터 송신 후 duplicate ACK 메시지가 연속적으로 수신되면, 이는 메시지가 손실되었다는 강한 표시임으로, 세 번째 duplicate ACK 수신 시 신속 재전송 및 복구(FAST-RETRANSMIT RECOVERY) 상태로 전환된다(P46).
한편, TRANSMIT 상태에서 window size 0 메시지가 수신되면, 수신 측의 처리속도보다 송신 측의 전송속도가 빠를 경우로, 수신 측의 버퍼가 부족하다는 의미이다. 이에, 데이터 송신을 일시 중지하는 PERSIST 상태로 전환된다(P48).
PERSIST 상태에서 window가 0보다 큰 값으로 복귀되었다는 메시지(window becomes nonzero)가 수신되면 다시 TRANSMIT 상태로 복귀하여 데이터를 송신한다(P42).
이상과 같이, TCP를 이용한 데이터 송수신 동작은 송수신 되는 메시지에 따라 특정 상태를 유지하며, 각 상태마다 수행되어야 하는 기능이 명확하다. 이에, 본 발명에서는 이러한 TCP의 각 기능 즉, 함수들을 해당 상태(state)를 기준으로 분류하여, 각 상태들을 하나의 상태 기계(state machine)로 추상화(abstraction)하여 구현한다. 상태를 단위로 TCP의 함수들을 분리하는 경우, 각 함수 간의 의존성(dependency)이 약화하여 함수들의 재구성이나 부분적인 갱신이 용이해진다. 따라서, 본 발명은 TCP 기능 수행을 위한 함수들을 각 상태를 단위로 분리하여 상태 기계 오브젝트(state machine object)를 정의하며, 각 상태 기계 오브젝트의 이름은, LISTEN, SYNSENT, SYNRCVD, ESTABLISHED 등의 상태(state) 명으로 명명하기로 한다.
이러한 상태 기계 간의 전이 정보는 해시 테이블에서 유지되며, 각 상태 기계들의 루트(ROOT)는 프레임 워크로 관리될 수 있다. 프레임 워크는 TCP 처리를 위한 프로그램 흐름의 골격을 형성하는 클래스로서, TCB(Transmission Control Block)와 같은 전역 데이터를 포함하여 모든 상태 기계들이 같은 데이터를 공유할 수 있도록 한다. 프레임 워크 역시 상태 기계 구조체를 포함하고 있으며, 일반 상태 기계와 다른 점은 전역 데이터를 포함하고 있다는 것과, 프레임 워크의 상태 기계는 실제로 TCP의 동작과는 상관없이 실행의 시작점이 되는 프록시(proxy)의 역할만을 수행한다는 것이다.
도 3은 본 발명에 따른 TCP 처리 시스템에 적용되는 상태 기계 오브젝트의 데이터 구조도이다. 도 3에 도시된 바와 같이, 하나의 상태 기계 오브젝트(100)는 상태 기계 이름(110)과, 이벤트 발생에 따른 상태 전이 정보를 유지하는 전이 테이블(112)과, 각 상태 기계 오브젝트의 해당 TCP 함수를 실행시키고 전이 테이블이 생성되도록 하는 함수 포인터(114)와, 상태 전이가 발생할 때마다 프레임 워크의 활성 상태 지시자는 마지막으로 전이된 상태 기계를 가리키는 활성 상태 지시자(116)와, 부모 상태 기계(118) 및 프레임 워크 포인터(120)를 포함한다. 이러한 데이터 구조는 프로그래밍 언어를 이용하여 소프트웨어적으로 구현이 가능하다. 다음은 상태 기계 오브젝트를 C 언어로 코딩한 경우를 예시한 것이다.
<상태 기계 오브젝트>
struct SMachine {
char cname_[STRLEN]; //상태 기계 이름
struct HashTable* ttbl_; //전이 테이블
void (* start)(struct Framework *, struct Packet *, int tcpEvent);
//함수 포인터
void (* buildTTable)(struct SMachine *); //함수 포인터
SMachine* actSMachine; //활성 상태 지시자
SMachine* pref; //부모 상태 기계
SMachine* fref; //프레임 워크 포인터
};
상태 기계 이름(110)은 LISTEN, SYNSENT, SYNRCVD, ESTABLISHED 등과 같이 TCP의 상태 전이 다이어그램의 각 상태(state)들의 이름을 따서 설정된다.
전이 테이블(112)은 이벤트 메시지의 발생에 따른 상태 전이 정보를 유지한다. 본 발명의 구현 구조는 이벤트 드리븐(event-driven) 방식을 따르고 있는데, 이벤트 메시지는 전역 이벤트 메시지와 지역 이벤트 메시지로 나뉜다. 전역 이벤트 메시지는 패킷 송신(PKTSENT), 패킷 수신(PKTRCVD), 타임아웃(TIMEOUT) 등의 메시지가 수신되는 것으로서, 주로 프레임 워크를 통해 각 상태 기계의 start()함수로 전달되며 모든 상태 기계에 동일하게 정의되어 사용된다. 이 세 가지 전역 이벤트 메시지는 각각 패킷 송신, 패킷 수신, 타임아웃의 발생이 함수 호출의 목적임을 start() 함수에 알리는 역할을 한다.
한편, 지역 이벤트 메시지는 각 상태 기계마다 개별적으로 정의되어 사용된 다. 이는, 각 상태마다 전이를 위해 필요한 이벤트 메시지들이 각각 다르며, 수행하는 역할 역시 다르기 때문이다. 예를 들면 LISTEN 상태의 경우 syn/syn+ack을 의미하는 이벤트 메시지가 필요하고, TRANSMIT 상태의 경우 재전송을 한다거나 혼잡 윈도의 크기가 0이 됐을 때를 의미하는 이벤트 메시지가 필요하다.
이와 같이, 전역 이벤트 메시지는 TCP에 실행 제어가 넘어왔을 때 패킷의 송신, 수신, 타임아웃 중 어느 코드 부분을 실행할 것인가를 구분하기 위해 외부로부터 전달되는 이벤트 메시지이고, 지역 이벤트 메시지는 해당 상태 기계에서의 수행 코드가 처리된 뒤 어느 상태 기계로 전이할 것인가 등을 결정하기 위해 내부적으로 발생시키는 이벤트 메시지인 것이 가능하다.
이러한 지역 이벤트 메시지를 통해 각 상태 기계들은 [현재 상태, 지역 이벤트]를 쌍으로 하는 키 값을 생성하고 해당 이벤트 메시지 수신 시, 전이해야 할 상태 기계들을 포인터로 유지한다.
도 4는 본 발명에 따른 TCP 처리 시스템의 전이 테이블(112) 및 상태 기계 전이 다이어그램을 예시한 것이다. 전이 테이블(112)에서는 상태 기계명과 이벤트 메시지명을 구분하기 위해 이벤트 메시지 명에 E_의 접두어를 추가하여 기재하였다.
도 4의 상태 기계 전이 다이어그램과 같이, 현재 상태가 CLOSED이고(P50), CLOSED에서의 TCP 코드가 수행되면서 세션 연결을 위한 SYN 패킷이 전송되었다면 SYNSENT라는 지역 이벤트 메시지가 발생할 것이다. 따라서, CLOSED에서 SYNSENT 상태 기계로의 전이가 이루어져야 한다(P52). 이는 전이 테이블(112) 내에 [CLOSED, SYNSENT]라는 해시 키(Hash key)와 그에 대한 값(Hash value)으로 SYNSENT 상태 기계 오브젝트를 가리키는 포인터가 해시 함수 형태로 유지되고 있다는 것을 의미한다.
한편, 현재 상태가 LISTEN이고(P54), LISTEN에서의 TCP 코드가 수행되면서 세션 연결을 위한 SYN 메시지가 전송되었다면 SYNSENT라는 지역 이벤트 메시지가 발생할 것이다. 따라서, LISTEN에서 SYNRCVD 상태 기계로의 전이가 이루어져야 한다(P56). 이는 전이 테이블(112) 내에 [LISTEN, SYNSENT]라는 키(key)와 그에 대한 값(value)으로 SYNSENT 상태 기계 오브젝트를 가리키는 포인터가 해시 함수 형태로 유지되고 있다는 것을 의미한다.
함수 포인터(114)는 상태 기계를 외부에서 액세스하기 위한 인터페이스로, 부분 컴포넌트의 개발 및 배포를 용이하게 하기 위해 모든 상태 기계가 동일한 인터페이스를 갖도록 하는 것이 바람직하다. 이러한 함수 포인터(114)로는 start()와 buildTTable()이 있다. start()는 각 상태 기계 오브젝트의 해당 TCP 코드를 실행시키는 함수이고, buildTTable()는 초기 전이 테이블(112) 구성 시 사용되는 함수이다.
여기서, 전역 이벤트를 처리하는 start() 함수는 다음의 <start() 함수의 코딩 예>와 같이 코딩될 수 있다.
<start() 함수의 코딩 예>
/*전역 이벤트 확인*/
switch(Global_Event) {
case PKTSENT: goto PKTOUT;
case PKTRCVD: goto PKTIN;
case TIMEOUT: goto TIMEOUT;
...
} //
/*상태 기계의 코드 수행 및 지역 이벤트 결정*/
PKTOUT: // 송신 패킷 처리 코드
PKTIN: // 수신 패킷 처리 코드
TIMEOUT: // 타임아웃 이벤트 처리 코드
...
/*지역 이벤트 처리 */
EXEC_MACHINE: // 지역 이벤트에 따른 상태 전이
상기의 <start() 함수의 코딩 예>에서 확인할 수 있듯이, start()함수는 크게 세 부분으로 구성된다. 먼저 함수로 넘어온 패킷 전송(PKTSENT), 패킷 수신(PKTRCVD), 타임아웃(TIMEOUT) 등의 전역 이벤트 메시지를 확인하고, 이벤트에 따라 PKTOUT, PKTIN, TIMEOUT의 세 영역으로 각각 점프하여 필요한 코드를 수행한다. 그 후 수행 결과에 따라 지역 이벤트의 값이 결정되고 EXEC_MACHINE 영역에서 상태 전이가 된다.
상태 전이가 발생할 때 마다 프레임 워크의 활성 상태 지시자(116)는 마지막으로 전이된 상태 기계를 가리키게 한다. 이것은 본 구현 구조의 동작 원칙을 위한 것으로, 어떠한 경우에라도 프레임 워크의 start()가 우선적으로 호출되며 프레임 워크의 start()가 하는 역할은 현재 활성화된 상태 기계의 start() 함수를 호출하는 것이다.
한편, 각 상태 기계들은 자기 자신을 부모로 하여 하위 상태 기계들을 확장하여 가질 수 있다. 예를 들어, ESTABLISHED 상태의 하위 레벨 제어로서 데이터 송수신 시에는 재전송(RETRANSMIT, 도 2참조)과 신속 재전송 및 복구(FAST-RETRANSMIT RECOVERY, 도 2참조) 상태로 전환될 수 있다. 따라서, ESTABLISHED 상태 기계는 TRANSMIT, RETRANSMIT, FAST-RETRANSMIT RECOVERY, PERSIST 등의 상태 기계들로 확장이 되며, 이들의 부모 상태 기계(118)가 된다. 여기서, TRANSMIT, RETRANSMIT, FAST-RETRANSMIT RECOVERY, PERSIST 등의 상태 기계들에 대한 활성 상태 지시자(116)는 ESTABLISHED 상태 기계에서 관리하게 된다.
상태 기계 오브젝트(100)의 부모 상태 기계(118)는 C 언어 코딩 시 pref 필드로 코딩될 수 있다. 상태 기계 간의 전이는 부모 상태 기계(118)의 전이 테이블(112)에 의해 행해지기 때문에 부모 상태 기계(118)에 대한 포인터는 계속 유지되어야 한다.
프레임 워크 포인터(120)는 프로토콜 프레임 워크를 나타내는 것으로서 C 언어 코딩 시 fref 필드로 코딩될 수 있다. 프레임 워크는 LISTEN, ESTABLISHED 등의 상위 상태 기계들의 부모 상태 기계(118)가 되며 이들 간의 전이 역시 프레임 워크의 전이 테이블(112)에서 유지된다. TRANSMIT, RETRANSMIT와 같은 하위 상태 기계들은 ESTABLISHED가 부모 상태 기계(118)가 되며, 이들 간의 전이는 마찬가지로 ESTABLISHED에서 유지될 것이다. 그 밖에 프레임 워크 포인터(120)는 TCB(Transmission Control Block)와 같은 프로토콜의 글로벌 데이터에 접근하기 위해 필요하다. 즉, 프레임 워크는 TCB(Transmission Control Block)와 같은 전역 데이터를 포함하여 모든 상태 기계들이 같은 데이터를 공유할 수 있도록 한다. 프레임 워크 역시 상태 기계 오브젝트를 포함하고 있다. 다만, 일반 상태 기계와는 다르게, 전역 데이터를 포함하고 있으며, 프레임 워크의 상태 기계는 실제로 TCP의 동작과는 상관없이 실행의 시작점이 되는 프록시(proxy)의 역할만을 수행한다.
이상 설명한 바와 같이, 본 발명에 따른 TCP 처리 시스템은 TCP 기능 수행을 위한 함수들을 각 상태를 단위로 분리하여 상태 기계 오브젝트(state machine object)를 구성함으로써 TCP의 재구성이 가능하도록 하고 있다.
도 5는 본 발명의 TCP 처리 시스템에 따른 데이터 송수신 과정을 도시한 흐름도이다.
먼저, 초기화 단계를 위해 프레임 워크 오브젝트를 생성한다(S10).
프레임 워크의 tcpfBuildTTable() 함수를 호출하여 상위 레벨의 각 상태 기계들과 전이 테이블(112)을 생성한다(S12). 여기서, 전이 테이블(112)이 생성되면 이 함수는 actSMachine 포인터(상태 기계 실행)를 프로토콜의 초기 상태 기계를 가리키도록 한다.
TCP가 능동적인 연결(active open)인 경우 초기 상태는 CLOSED 상태이고, 프레임 워크의 start()함수는 CLOSED 상태 기계의 start()함수를 호출한다(S14).
CLOSED 상태 기계의 start()함수는 3방향 핸드셰이킹(3-way handshaking)의 첫 번째 패킷인 SYN을 내보내는 코드를 수행한다(S16). 3방향 핸드셰이킹은, 동기화 메시지(SYN segment), 종료 메시지(FIN segment), Acknowledgement(ACK)의 3개의 메시지를 이용하여 송수신단을 연결하는 방법이다.
패킷을 전송 후 start()함수의 EXEC_MACHINE에서 상태 지시자를 SYNSENT로 변경하여 다음에 올 패킷을 처리하게 한다(S18).
상대방으로부터 SYN+ACK를 받으면, 이제 SYNSENT 상태 기계는 ACK 패킷을 보내고 그 이후의 패킷 처리를 ESTABLISHED가 하도록 다시 상태 전이를 수행한다(S20). TCP의 데이터 전송은 이제 ESTABLISHED에서 이루어진다.
ESTABLISHED 상태에서의 데이터 송수신 흐름은 도 6에 도시된 바와 같다. 도 6은 본 발명의 TCP 처리 시스템에 따른 ESTABLISHED 상태에서의 하위 레벨 상태 전이 다이어그램이다.
전술했던 바와 같이, 모든 경우에 있어 제일 먼저 프레임 워크의 지시자가 가리키는 활성화 상태의 start() 함수가 호출되며, 전달된 이벤트에 따라 해당 코드가 실행된다.
ESTABLISHED 상태는 패킷 전송(output)과 관련된 하위 레벨 상태 기계들을 포함한다(P62). 따라서 PKTSENT 이벤트에 대해서는 내부적으로 다시 하위 활성화 상태 지시자가 가리키는 상태 기계의 start() 함수를 호출하게 된다.
ESTABLISHED 상태에서 일반적인 패킷 전송 시에는 TRANSMIT 상태 기계로 전환된다(P64).
그리고, 재전송을 알리는 TIMEOUT 이벤트가 발생한 경우(P60), P62단계의 ESTABLISHED 상태에서 RETRANSMIT 상태로 전환된다(P66).
한편, 패킷을 수신하는 경우(Read())는 별도의 전이 없이 그대로 ESTABLISHED start() 함수의 PKTIN 부분(전술한 <start() 함수의 코딩 예> 참조)이 수행된다(P68).
이러한 구성을 갖는, 본 발명에 따른 TCP 처리 시스템의 상태 기계 및 프레임 워크를 포함하는 패킷을 사용하기 위해서는, 프레임 워크와 새로 다운로드 받은 상태 기계와의 동적 바인딩 문제가 해결되어야 하며, 본 발명에서는 재구성 로더를 두어 이를 지원하고 있다.
도 7은 본 발명에 따른 TCP 처리 시스템에서 바이너리 코드의 심볼 참조 재지정 과정을 보여주는 데이터 재구성 로더의 구성도이다.
일반적으로 갱신용 상태 기계는 프레임 워크의 내부 구조를 알고 있다는 가정 하에 구현된 것이기 때문에 필요에 따라 프레임 워크 내의 함수들을 호출하는 코드를 포함하고 있다. 그러나 새 상태 기계들은 프레임 워크와 독립적으로 컴파일되어 다운로드 받은 것이기 때문에 프레임 워크 내의 심볼(symbol) 주소에 대한 정보가 없으며, 컴파일 당시 알 수 없는 심볼 주소들은 0x0으로 지정된다. 따라서 이러한 심볼들에 대한 참조를 가능하게 하기 위해 프레임 워크의 심볼 주소 정보를 바탕으로 재배치(relocation)하는 과정이 필요하게 된다.
이에, 데이터 재구성 로더는, 갱신할 상태 기계 오브젝트의 심볼 테이블(100)과, 주소 재배치 테이블(110)을 포함한다. 이 정보들은 컴파일러를 통해 생성되며, 심볼들의 주소값들은 리눅스의 readelf 프로그램을 통해서 얻을 수 있는 정보이다. 로딩 전 심볼 테이블 내의 buildTTable, frametab, tmclear 등의 심볼들은 아직 미결정 상태이기 때문에 주소값이 모두 0x0으로 설정되어 있다.
이 후 프레임 워크의 주소공간으로 로드될 때 프레임 워크의 심볼 주소값으로 대체되어 TCP 심볼정보 저장부(120)에 저장된다. 여기서, 주소 재배치 테이블(110)의 r_offset은 해당 심볼들이 참조되는 곳의 위치를 재배치 시작주소를 기준으로 한 상대 값을 나타낸 것이다. 예컨대, 주소 재배치 테이블(110)에서는 start라는 심볼이 재배치 시작 주소로부터 0x20만큼 떨어진 곳에서 참조 되고 있다는 것을 의미한다. 이들은 모두 상대주소를 의미하기 때문에 프레임 워크로 로드가 된 후에도 그대로 사용된다.
상태 기계의 심볼 주소값들이 정해지면 이제 변수 및 함수 참조에 대한 재배치 과정이 이루어져야 한다. 상태 기계 이미지 저장부(180)에는 프레임 워크의 주소공간으로 복사된 상태 기계의 이미지가 저장된다.
TCP 절대주소 저장부(140)에는 상태 기계 이미지 저장부(180)에 저장된 상태 기계의 시작주소가 저장되어 있다. 이에, 도 7의 예에서 이 상태 기계의 시작 주소는 0x0804d607이 되며 이것이 곧 재배치 시작 주소가 된다. 또한, 재배치 시작주소로부터 0x23 떨어진 곳으로부터 call smCreate 함수(160)가 수행되고 있으며, 이것은 프레임 워크의 smCreate 함수(140)를 호출하는 명령어이다.
심볼 참조는 현재 참조 위치에서 해당 함수의 주소값 차이만큼의 상대적인 값으로 이루어지기 때문에 결국 call 명령어에 대한 함수 호출 주소값은 다음의 식 (1)을 통해 산출될 수 있다.
함수의 호출 주소값 = 재배치 시작주소+상대주소+4-심볼의 절대주소
여기서, 상대주소는 상기 재배치 테이블에 저장된 값이고, 4는 함수 실행 후 복귀 주소를 기어가기 위해 PC(Program counter)값을 다음 명령어로 이동시킴으로 합산되는 값이다. 이에, 변수 참조에 대한 재배치의 경우는 4를 더하지 않는다.
상기 식 (1)에 의하면, call smCreate 함수(160)에 대한 호출 인자 값은 0x0804d607 + 0x23 - 0x0804b674 + 4가 되며, 이는 call smCreate 함수(160)와 TCP 절대주소 저장부(140) 주소값의 차이를 의미한다. 이상의 재배치 과정을 통해 재구성 로더는 새로 로드한 상태 기계들이 프레임 워크 주소 공간 내에서 원활히 동작하도록 돕게 된다.
이와 같은 구현 구조에서 TCP의 재구성은 결국 특정 상태 기계를 다른 상태 기계로 바꿈으로써 이루어진다. 이미 언급한 바와 같이 대부분의 TCP 변종들은 TCP 전체를 새로 다시 구현하기보다 특정 알고리즘만을 재구현한 것들이다. 예를 들어 혼잡 제어 알고리즘을 개선하는 경우, ESTABLISHED 또는 TRANSMIT 상태 기계만을 교체하는 것으로도 충분하다는 것이다. 따라서 새로 개발되는 TCP들은 전체가 아닌 필요한 몇 개의 상태 기계들만 구현하면 된다. 이에, 몇 개의 상태 기계들을 묶어서 하나의 배포형 컴포넌트로 포장하고, TCP 명칭 및 버전, 해시 키 개수, 키 값 등의 정보들을 컴포넌트 헤더에 추가하여 다운로드 할 수 있도록 정의하였다. 이때의 키 값은 교체할 상태 기계의 위치를 찾기 위해 사용된다. 즉, 전이 테이블(112)에서 컴포넌트 헤더에 포함된 키 값의 순서대로 상태 기계들을 따라간 뒤, 교체할 상태 기계의 포인터를 새로 받은 상태 기계의 포인터로 바꾸는 것이 가능하다.
도 8은 본 발명에 따른 TCP 처리 방법의 흐름도로서 각기 다른 TCP를 사용하는 호스트 간 데이터 송수신 흐름을 도시한 것이다.
표준 TCP를 수정한 TCP2를 사용하는 호스트 1이, 호스트 2 측에 TCP2 세션 연결을 요청한다(S20). 여기서, 호스트 1은 3방향 핸드셰이킹(3-way handshaking)을 통해 호스트 2 측에 TCP2 사용을 제안할 수 있다.
호스트 2는 TCP2를 처리하기 위한 데이터 재구성 로더 및 기타 컴포넌트를 가지고 있는지 확인한다(S22).
확인 결과, 호스트 2 측에 TCP2의 처리를 위한 구성이 구비되어 있지 아니할 경우, 표준 TCP로 세션을 설정하고, 별도의 백그라운드 세션을 열어 호스트 1로부터 TCP2를 처리하기 위한 데이터 재구성 로더 및 기타 컴포넌트를 다운로드 받는다(S24).
다운로드가 완료되면 재구성 로더가 이를 프레임 워크에 로드하고 미확인 심볼을 재지정하여 커널 주소 공간에 로딩한다(S26).
이후, 상태 기계의 부분 교체를 통해 TCP2로 재구성한다(S28). 이 후에는 기존 표준 TCP의 세션 종료 없이 그대로 TCP2가 이이서 사용된다. 또한, 자연스럽게 호스트 B 역시 다음 연결부터는 새로운 TCP2를 사용할 수 있게 된다.
도 9는 본 발명의 TCP 처리 시스템을 통한 데이터 송수신 결과 그래프로서, 20 RTT 근처의 세로로 굵은 점선으로 표시된 시점에 본 발명의 구현 구조를 바탕으로 TCP Reno에서 TCP Westwood로 재구성시켰다.
흰 원은 재구성되어 나타난 결과이며, 검은 원은 재구성을 하지 않았을 경우에 나타나는 결과이다. 결론적으로 세션의 끊김이나 재연결 없이 곧바로 재구성된 TCP가 동작할 수 있다는 것을 보여주고 있으며, 이로 인해 성능의 이득을 보고 있음을 확인할 수 있다.
이상 설명한 바와 같이, 본 발명은 TCP 기능 수행을 위한 함수들을 해당 상태(state)를 기준으로 분류하고, 각 함수들을 하나의 상태 기계(state machine) 오브젝트로 구현함으로써, TCP 코드의 부분적인 갱신이 가능하도록 하고 있다. 이에, 수정된 TCP의 갱신 시간을 감소시킬 수 있으며, 바이너리 수준의 TCP 갱신이 이루어지기 때문에 별도의 컴파일러가 탑재되어 있지 아니한 경우에도 수정된 TCP의 적용이 가능하다. 또한, 데이터 재구성 로더를 이용하여, 바이너리로 된 상태 기계 컴포넌트를 메모리에 적재한 뒤 실행 중인 기존 TCP 코드와 동적으로 바인딩 되도록 함으로써, 기존 세션의 끊김 없이 새로운 TCP를 곧바로 적용하는 것이 가능하다.
이상에서 대표적인 실시예를 통하여 본 발명에 대하여 상세하게 설명하였으나, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 상술한 실시예에 대하여 본 발명의 범주에서 벗어나지 않는 한도 내에서 다양한 변형이 가능함을 이해할 것이다. 그러므로 본 발명의 권리범위는 설명된 실시예에 국한되어 정해져서는 안되며 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.
도 1은 TCP 기반 데이터 송수신 동작의 상태 전이 다이어그램이다.
도 2는 TCP 도 1의 하위 레벨의 데이터 송수신 동작의 상태 전이 다이어그램이다.
도 3은 상태 기계 오브젝트의 데이터 구조도이다.
도 4는 본 발명에 따른 TCP 처리 시스템의 기계 오브젝트들 간의 상태 전이 다이어그램이다.
도 5는 본 발명에 따른 TCP 처리 시스템의 데이터 송수신 흐름도이다.
도 6은 본 발명의 TCP 처리 시스템에 따른 ESTABLISHED 상태에서의 하위 레벨 상태 전이 다이어그램이다.
도 7은 본 발명에 따른 TCP 처리 시스템에서 바이너리 코드의 심볼 참조 재지정 과정을 보여주는 재구성 로더의 구성도이다.
도 8은 본 발명에 따른 TCP 처리 방법의 흐름도이다.
도 9는 본 발명의 TCP 처리 시스템을 통한 데이터 송수신 결과 그래프이다.
*** 도면의 주요 부분에 대한 부호의 설명 ***
100 : 상태 기계 오브젝트 110 : 상태 기계 이름
112 : 전이 테이블 114 : 함수 포인터
116 : 활성 상태 지시자 118 : 부모 상태 기계
120 : 프레임 워크 포인터 200 : 심볼 테이블
210 : 주소 재배치 테이블 220 : 심볼 정보 테이블

Claims (24)

  1. TCP 처리 시 발생하는 이벤트 메시지에 의해 전이되는 TCP 처리 상태에 따라 실행되는 각 함수들을 분리하여 구성한 상태 기계 오브젝트와;
    상기 이벤트 메시지에 따라 상기 상태 기계 오브젝트를 호출하여 해당 함수를 실행하는 프레임 워크와;
    상기 프레임 워크가 상기 상태 기계 오브젝트를 호출하여 실행시킬 수 있도록, 상기 상태 기계 오브젝트의 주소를 상기 프레임 워크에 등록하는 데이터 재구성 로더를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  2. 제 1 항에 있어서,
    상기 상태 기계 오브젝트는,
    상기 상태 기계 오브젝트의 이름과;
    상기 이벤트 메시지에 따른 상태 전이 정보를 유지하는 전이 테이블과;
    상기 함수를 실행시키고 상기 전이 테이블을 생성하는 함수 포인터와;
    마지막으로 전이된 상태 기계 오브젝트를 가리키는 활성 상태 지시자와;
    부모 상태 기계의 이름과;
    상위 상태 기계 오브젝트의 부모 상태 기계를 표시하는 프레임 워크 포인터를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  3. 제 2 항에 있어서,
    상기 상태 기계 오브젝트의 이름은, 상기 각 함수가 실행되는 상태의 이름에 따라 명명되는 것을 특징으로 하는 TCP 처리 시스템.
  4. 제 1 항에 있어서,
    상기 이벤트 메시지는,
    모든 상태 기계 오브젝트에 동일하게 정의되어 사용되는 전역 이벤트 메시지와;
    각 상태 기계 오브젝트 마다 개별적으로 정의되어 사용되는 지역 이벤트 메시지를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  5. 제 4 항에 있어서,
    상기 전역 이벤트 메시지는,
    패킷 송신(PKTSENT) 메시지, 패킷 수신(PKTRCVD) 메시지, 타임아웃(TIMEOUT) 메시지를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  6. 제 2 항에 있어서,
    상기 전이 테이블에는,
    상기 상태 기계 오브젝트의 이름 및 해당 상태 기계 실행 시 수신되는 이벤트 메시지와, 그에 따라 호출될 상태 기계 오브젝트를 가리키는 포인터가 저장되는 것을 특징으로 하는 TCP 처리 시스템.
  7. 제 2 항에 있어서,
    상기 함수 포인터는,
    각 상태 기계 오브젝트의 해당 함수를 실행시키는 시작 함수(start())와;
    상기 전이 테이블을 구성하는 테이블 구성 함수(buildTTable())를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  8. 제 1 항에 있어서
    상기 프레임 워크는,
    모든 상태 기계 오브젝트들과 데이터를 공유할 수 있는 전역 데이터(Transmission Control Block, TCB)를 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  9. 제 1 항에 있어서,
    상기 데이터 재구성 로더는,
    상기 상태 기계 오브젝트에 포함된 함수의 심볼들이 저장된 심볼 테이블과;
    상기 함수의 심볼들의 주소가, 상기 상태 기계 오브젝트의 실제 시작주소를 기준으로 하는 상대적인 주소값으로 저장된 주소 재배치 테이블을 포함하고;
    상기 심볼 테이블의 함수 심볼을 로딩하여 상기 프레임 워크의 재배치 시작 주소에 복사하고, 상기 상태 기계 오브젝트의 실제 시작주소와, 상기 재배치 테이블의 상대적인 주소값과, 상기 함수가 저장된 실제주소인 절대주소를 연산하여 상기 함수의 호출 주소값으로 재배치 한 심볼 정보 테이블을 포함하는 것을 특징으로 하는 TCP 처리 시스템.
  10. 제 9 항에 있어서,
    상기 함수의 호출 주소값은 하기 식(1)을 통해 산출되고,
    함수의 호출 주소값 = 재배치 시작주소+상대주소+4-심볼의 절대주소 (1)
    상기 식(1)에서 상대주소는 상기 주소 재배치 테이블에 저장된 값이고, 4는 함수 실행 후 복귀 주소를 기억하기 위해 PC(Program counter)값을 다음 명령어로 이동시킴으로 합산되는 값인 것을 특징으로 하는 TCP 처리 시스템.
  11. (a)TCP 처리 시 발생하는 이벤트 메시지에 의해 전이되는 TCP 처리 상태에 따라 실행되는 각 함수들을 분리하여 상태 기계 오브젝트를 구성하는 단계와;
    (b)상기 TCP를 처리하는 프레임 워크에 상기 상태 기계 오브젝트의 주소를 등록하는 단계와;
    (c)상기 프레임 워크가 상기 TCP 처리시 발생하는 이벤트 메시지에 따라 해당 상태 기계 오브젝트를 상기 주소를 통해 호출하여 해당 함수를 실행하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  12. 제 11 항에 있어서,
    상기 상태 기계 오브젝트는,
    상기 상태 기계 오브젝트의 이름과;
    상기 이벤트 메시지에 따른 상태 전이 정보를 유지하는 전이 테이블과;
    상기 함수를 실행시키고 상기 전이 테이블을 생성하는 함수 포인터와;
    마지막으로 전이된 상태 기계 오브젝트를 가리키는 활성 상태 지시자와;
    부모 상태 기계의 이름과;
    상위 상태 기계 오브젝트의 부모 상태 기계를 표시하는 프레임 워크 포인터를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  13. 제 12 항에 있어서,
    상기 상태 기계 오브젝트의 이름은, 상기 각 함수가 실행되는 상태의 이름에 따라 명명되는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  14. 제 11 항에 있어서,
    상기 이벤트 메시지는,
    모든 상태 기계 오브젝트에 동일하게 정의되어 사용되는 전역 이벤트 메시지와;
    각 상태 기계 오브젝트 마다 개별적으로 정의되어 사용되는 지역 이벤트 메시지를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  15. 제 14 항에 있어서,
    상기 전역 이벤트 메시지는,
    패킷 송신(PKTSENT) 메시지, 패킷 수신(PKTRCVD) 메시지, 타임아웃(TIMEOUT) 메시지를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  16. 제 12 항에 있어서,
    상기 전이 테이블에는,
    상기 상태 기계 오브젝트 이름 및 해당 상태 기계 실행 시 수신되는 이벤트 메시지와, 그에 따라 호출될 상태 기계 오브젝트를 가리키는 포인터가 저장되는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  17. 제 12 항에 있어서,
    상기 함수 포인터는,
    각 상태 기계 오브젝트의 해당 함수를 실행시키는 시작 함수(start())와;
    상기 전이 테이블을 구성하는 테이블 구성 함수(buildTTable())를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  18. 제 11 항에 있어서
    상기 프레임 워크는,
    모든 상태 기계 오브젝트들과 데이터를 공유할 수 있는 전역 데이터(Transmission Control Block, TCB)를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  19. 제 11 항에 있어서,
    상기 (b)단계는,
    상기 상태 기계 오브젝트에 포함된 함수의 심볼들이 저장된 심볼 테이블과;
    상기 함수의 심볼들의 주소가, 상기 상태 기계 오브젝트의 실제 시작주소를 기준으로 하는 상대적인 주소값으로 저장된 주소 재배치 테이블을 구현하여 이루어지고,
    상기 심볼 테이블의 함수 심볼이 상기 프레임 워크의 재배치 시작 주소로 로딩되는 단계와;
    상기 상태 기계 오브젝트의 실제 시작주소와, 상기 주소 재배치 테이블의 상대적인 주소값과, 상기 함수가 저장된 실제주소인 절대주소를 연산하여 상기 함수의 호출 주소값을 산출하는 단계와;
    상기 호출 주소값이 재배치되는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  20. 삭제
  21. 제 11 항에 있어서, 상기 (c)단계는
    상기 프레임 워크를 이용하여 상태 전이 정보를 유지하는 전이 테이블을 생성하는 단계와;
    상기 TCP가 능동적인 연결(active open)인 경우 CLOSED 상태 기계 오브젝트의 start()함수를 호출하여 상대방 측과 3방향 핸드셰이킹(3-way handshaking)을 수행하는 단계와;
    상기 3방향 핸드셰이킹 후, 다음 상태 기계 오브젝트를 데이터 전송(SYNSENT) 오브젝트로 변경하여 다음에 올 패킷을 처리하는 단계와;
    상대방 측으로부터 확인 이벤트 메시지(SYN+ACK)를 받으면, 상기 데이터 전송(SYNSENT) 오브젝트가 응답 이벤트 메시지(ACK)를 송신한 후, 다음 상태 기계 오브젝트인 ESTABLISHED를 호출하여 데이터를 전송하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  22. 표준 TCP를 수정한 TCP2를 사용하는 제1 호스트가 3방향 핸드셰이킹(3-way handshaking)을 통해 제2 호스트에 TCP 세션 연결을 요청하는 단계와;
    상기 제2 호스트가 상기 TCP2를 처리하기 위한 데이터 재구성 로더 및 기타 컴포넌트를 가지고 있는지 확인하는 단계와;
    확인 결과, 상기 제2 호스트에 상기 TCP2의 처리를 위한 구성이 구비되어 있지 아니할 경우, 표준 TCP로 세션을 설정하는 단계와;
    상기 표준 TCP로 설정된 세션을 통해 상기 제2 호스트가 상기 제1 호스트로부터 상기 TCP2의 처리를 위한 상기 데이터 재구성 로더 및 기타 컴포넌트를 다운로드 받는 단계와;
    상기 다운로드가 완료되면 상기 데이터 재구성 로더가 상기 TCP2를 처리하는 프레임 워크를 실행시켜 상기 다운로드된 정보를 상기 제2 호스트에 등록하고 상기 다운로드된 컴포넌트들을 커널 주소 공간에 로딩하는 단계와;
    기존 표준 TCP의 세션 상에서 상기 TCP2의 수정 부분만을 교체하여 상기 세션의 종료 없이 상기 TCP2에 따라 상기 제1 호스트 및 제2 호스트 간 통신을 수행하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  23. 제 22 항에 있어서,
    상기 TCP2는,
    상기 TCP 처리에 따라 발생하는 이벤트 메시지에 의해 전이되는 각 상태에서 실행되는 함수들을, 상기 각 함수가 실행되는 상태에 따라 분리하여 구성한 상태 기계 오브젝트를 이용하여 통신을 수행하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
  24. 제 22 항에 있어서,
    상기 TCP2에 따라 상기 제1 호스트 및 제2 호스트 간 통신을 수행하는 단계는,
    상기 각 호스트에 설치된 프레임 워크가 전역 이벤트 메시지를 수신하는 단계와;
    상기 전역 이벤트 메시지가, 패킷 전송(PKTSENT), 패킷 수신(PKTRCVD), 타임아웃(TIMEOUT) 메시지 중 어느 것인지 확인하여, 상기 프레임 워크가 해당 메시지에 대응되는 함수를 실행하는 단계와;
    상기 함수 수행 결과에 따라 발생한 지역 이벤트 메시지에 따라 해당 상태 기계 오브젝트를 호출하는 단계와;
    상기 프레임 워크의 활성 상태 지시자가 상기 마지막으로 호출된 상태 기계 오브젝트를 지시하도록 설정하는 단계를 포함하는 것을 특징으로 하는 TCP 처리 시스템의 제어방법.
KR1020070090691A 2007-09-06 2007-09-06 티씨피 처리 시스템 및 그 제어방법 KR100914308B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020070090691A KR100914308B1 (ko) 2007-09-06 2007-09-06 티씨피 처리 시스템 및 그 제어방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020070090691A KR100914308B1 (ko) 2007-09-06 2007-09-06 티씨피 처리 시스템 및 그 제어방법

Publications (2)

Publication Number Publication Date
KR20090025673A KR20090025673A (ko) 2009-03-11
KR100914308B1 true KR100914308B1 (ko) 2009-08-27

Family

ID=40693959

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020070090691A KR100914308B1 (ko) 2007-09-06 2007-09-06 티씨피 처리 시스템 및 그 제어방법

Country Status (1)

Country Link
KR (1) KR100914308B1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9838318B2 (en) * 2011-12-28 2017-12-05 Cdf Ke Yuan TCP congestion control for large latency networks
CN108255525B (zh) * 2016-12-28 2020-08-25 比亚迪股份有限公司 基于轨道交通的控制方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045345A2 (en) 2004-10-29 2006-05-04 Ntt Docomo, Inc. Method and apparatus for switching between different protocol implementations
US7171486B2 (en) 1998-06-15 2007-01-30 Intel Corpoartion Reassembly of a transmission control protocol (TCP) data stream from payloads of TCP segments of a bidirectional TCP connection

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7171486B2 (en) 1998-06-15 2007-01-30 Intel Corpoartion Reassembly of a transmission control protocol (TCP) data stream from payloads of TCP segments of a bidirectional TCP connection
WO2006045345A2 (en) 2004-10-29 2006-05-04 Ntt Docomo, Inc. Method and apparatus for switching between different protocol implementations

Also Published As

Publication number Publication date
KR20090025673A (ko) 2009-03-11

Similar Documents

Publication Publication Date Title
Raisinghani et al. Cross-layer feedback architecture for mobile device protocol stacks
Chan et al. MobiPADS: a reflective middleware for context-aware mobile computing
JP4271234B2 (ja) 修正関数を有するプロトコルスタック
KR101099382B1 (ko) 패킷 네트워크에서의 종단점 어드레스 변경
FI113927B (fi) Menetelmä verkkopakettien sieppaamiseksi tietokonelaitteessa
US8291486B2 (en) Gateway device having socket library for monitoring, communication method of gateway device having socket library for monitoring, and communication program of gateway device having socket library for monitoring
US20040250253A1 (en) Method and apparatus for providing multi-client support in a sip-enabled terminal
JP2006519518A (ja) 柔軟なプロトコル・スタック
Snoeren A session-based architecture for internet mobility
KR20070092720A (ko) 클라이언트측 가속 기술을 제공하는 시스템 및 방법
US20240069977A1 (en) Data transmission method and data transmission server
US8090836B1 (en) TCP connection migration
US7412701B1 (en) Method for network management using a virtual machine in a network device
US20030229713A1 (en) Server network controller including server-directed packet forwarding and method therefor
KR100914308B1 (ko) 티씨피 처리 시스템 및 그 제어방법
CN108600378B (zh) 一种文件下载方法、装置、终端和存储介质
CN116708597A (zh) 一种数据处理方法及装置
CN111352642A (zh) 服务设备及服务软件升级的方法
US8533736B2 (en) System and method for adding local resources for use by a mobile agent object
US7805733B2 (en) Software implementation of hardware platform interface
CN111064592A (zh) 一种局域网软件更新的方法及usb装置
Janssens et al. NeCoMan: middleware for safe distributed-service adaptation in programmable networks
US7529812B2 (en) Socket connections over a serial link
JP2006246278A (ja) 通信品質制御方法及び通信品質制御システム
Srinivasan MTCP: transport layer support for highly available network services

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: 20120615

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20130621

Year of fee payment: 5

LAPS Lapse due to unpaid annual fee