KR19980086587A - Tcp/ip 소켓 애플리케이션을 이용한 시스템 자원 저감 툴 - Google Patents

Abstract

본 발명은 액티베이트_온_리시트(activate_on_receipt) 메커니즘을 이용함으로써 불필요한 시스템 유휴 시간 또는 다른 프로세싱 지연을 발생시키지 않고 멀티-호스트 컴퓨터 환경에서 데이터를 전송하는 새로운 방법을 제시한다. 이 메커니즘은 인입되는 데이터가 수신될 때까지, 시스템 자원들을 구속(tie-up)할 수 있는 판독과 같은 소정의 명령어들을 수신함과 동시에 임시 기억 위치를 준비해 둔다. 그 후, 시스템 환경은 인입되는 요구 데이터가 임시 기억 위치에 수신될 때까지 다른 연산들을 계속하여 수행하고, 요구 데이터가 임시 기억 위치에 수신되는 때에 메커니즘은 수신되는 데이터를 처리하기 위하여 모든 실행 중인 연산들을 종료시킨다. 만일 요구되는 임시 기억 위치의 크기가 인입되는 데이터의 크기를 수용할 수 있으면, 데이터는 직접 판독된다. 만일 요구되는 임시 기억 위치의 크기가 인입되는 데이터의 크기를 수용할 수 없으면, 새로운 기억 위치가 확보되고 데이터는 판독되기 전에 이 새로운 위치에 복사되고 완전히 수신된다.

Description

ＴＣＰ/ＩＰ 소켓 애플리케이션을 이용한 시스템 자원 저감 툴

본 발명은 TCP/IP 소켓 애플리케이션(socket application) 등과 같은 통신 세션(communication session) 동안에 발행되는 판독 함수(read function)와 같은 소정의 명령어를 처리하는 동안에 시스템에 의해 이용되는 자원들을 저감하도록 고안된 툴(tool)에 관한 것이다.

호스트 시스템 네트워크 또는 다른 유사한 멀티-호스트 컴퓨터 환경에서는, 동시에 데이터를 요구하고 액세스하거나 서로 다른 상주 애플리케이션들을 동시에 실행할 수 있는 다수의 프로세서들과 호스트들이 공존한다. 그런 환경에서는 데이터 프로세싱 시스템들을 이용하여 환경 도처의 서로 다른 위치들에 필요한 데이터를 보유함으로써 서로 다른 애플리케이션들의 프로세싱에 편의를 제공한다. 이로써, 원격 호스트 또는 유저에게 단일 이미지를 프리젠트(present)할 수 있게 되고 프로세서 컴플렉스(processor complexes)에 의한 작업 부담의 균형이 이루어지게 된다. 데이터는, 원격 호스트들에 링크되고 다른 호스트 시스템들에 링크되어 환경 내의 통신 링크들의 네트워크를 형성하는 하나 이상의 호스트 시스템들 내에 보유될 수 있다. 링크 상의 한 호스트로부터 링크 상의 다른 호스트로 메시지를 송신하기 위하여, 메시지의 루트를 정하고 컴플렉스 또는 환경 내의 링크 상의 적당한 호스트 컴퓨터들에 액세스함으로써 통신을 제어하기 위한 프로토콜이라 불리는 통신 규약이 확립된다. 일반적으로 이들 통신 프로토콜은 데이터 통신 제품의 기능 및 구조를 정의하는 텔레프로세싱 아키텍처(teleprocessing architecture)의 일부로서 존재한다.

그런 통신 네트워크 또는 환경에서는, 하나 이상의 운영 시스템(operating system)에 의해 제공되는 기능적 인터페이스(functional interface)인 애플리케이션 프로그램 인터페이스(이하, API라 함)가 또한 제공되어 하이 레벨 언어로 작성된 애플리케이션 프로그램이 상기 운영 시스템의 특정 데이터 또는 함수들을 이용할 수 있게 된다. 어떤 경우에는, API가 인터페이스 ― 그를 통해 애플리케이션 프로그램이 액세스 방법과 상호 대화(interact)를 함 ―로서 기능하기도 한다. 멀티태스킹 운영 시스템에서는, 운영 시스템에 대한 애플리케이션 프로그램 요구(request)가 API를 통하여 이루어져서, 종료될 태스크 또는 프로세스가 요구에 의해 자동적으로 기동된다. 병렬 프로세싱 환경에서는, 컴퓨터 아키텍처는, 다수의 태스크들을 고속으로 동시에 처리하기 위하여, 다수의 상호 접속된 프로세서들을 사용하여 다량의 데이터에 액세스한다. 그런 환경에서는, 멀티태스킹 운영 시스템은 적시의 태스크 프로세싱을 위하여 API에 크게 의존한다.

요구되는 태스크 프로세싱을 적시 방식(timely manner)으로 수행하기 위하여, 다수의 API들은 프로세서 그룹들 간의 복잡한 통신을 수행하기 위한 일련의 집합 연산들(a set of collective operations)을 정의한다. 집합 연산들과 관련된 몇 가지 장점이 있는데, 그 중에는 사용의 용이성과 성능이 있다. 그러나, 집합 연산들을 사용하는 데에는 한 가지 큰 단점이 있다. 대부분의 경우에, 이들 집합 연산들의 다수가 동기적(synchronous)이며, 그 연산들은 태스크의 성능을 위한 시간이 되기까지 프로세서를 블록(block)하기 때문에, 블로킹 연산들(blocking operations)들로 알려져 있다. 애초부터 그 태스크들이 동기적이 아닌 애플리케이션에 대한 해법은 논-블로킹(non-blocking) 또는 비동기 집합 연산들을 이용하는 것이다. 논-블로킹 연산들에 의해 각 태스크가 그 자신의 페이스로 진행될 수 있고, 주기적으로 그 연산들의 종료를 테스트하거나 필요할 경우 대기할(wait) 수 있다. 그러나, 논-블로킹 연산들 역시 어떤 단점들을 갖고 있다. 예를 들면, 대기할 필요가 있거나 또는 내부 의존 상황에 처했을 경우, 유저에게 제어권을 되돌려서 결정을 하게 해야 한다. 그 이유는, 비동기 집합 연산들이 이용되는 논-블로킹 환경에서는, 전체 연산이 어떠한 태스크 또는 프로세서 시간도 블록할 수 없게 되어 있기 때문이다. 이런 의존성 때문에, 연산을 블록할 수 있는 프로세스의 단계(stage)는 하나도 없다.

그러나, 제어권을 유저에게 되돌리는 것은 문제의 일부분에 불과하다. 제어권이 유저에게 되돌려진 후의 한 가지 중요한 문제는, 예를 들면 최초의 내부 의존 상황이 해결된 때와 같이, 연산이 재개될 수 있는 때를 통지하는 문제이다. 두 번째 관련 문제는, 일단 유저가 연산을 재개할 것을 결정하면 인터럽트가 발생하기 바로 전과 동일한 프로세싱 위치로 되돌아가는 것이다.

블로킹 연산과 논-블로킹 연산 모두에서 발생되는 또 다른 공통의 관련 문제는, 성능 문제 및 시스템 유휴 시간(system idle time)을 해결하는 것이다. read() 또는 recvfrom() call(호출)과 같은 소정의 명령어들은, 판독 또는 수신 명령어(read or receive command)의 데이터가 요구 애플리케이션에 의해 수신될 때까지 시스템 환경이 처리 중인 연산들을 일시적으로 중지할 것을 요구한다. 데이터가 프로세싱에 즉시 이용될 수 없는 경우에, 그 데이터가 이용될 수 있을 때까지 애플리케이션에 이용될 수 있는 대부분의 자원들이 중지 상태에 있게 되며 더 이상의 프로세싱이 불가능하게 된다. 블로킹 모드에서는, 명령어 프로세싱의 순차성에 따라, 전체 프로세스 환경은, 명령어 프로세싱의 다음 단계가 수행될 수 있기 전에, 인입되는 데이터(in-coming data)를 기다려야 한다. 논-블로킹 모드에서는, 여전히 데이터가 즉시 이용될 수 없는 경우에, 프로세스 환경은 그런 이용 가능성(availability)을 계속하여 체크하여 비동기 연산을 동기 연산이 되도록 하거나 또는 연산을 종료하고 유저에게 제어권을 되돌려야 하는데, 이는 또 다른 문제를 일으킨다. 고성능의 트랜잭션 지향 시스템(transaction oriented system)에서는, 그런 데이터의 이용 불가능성의 결과로서 다수의 프로세스들이 모두 동시에 중지될 가능성이 있다. 그 결과, 시스템은 자원들을 다 써 버려서, 어떤 새로운 프로세스들이 디스패치(dispatch)될 가능성이 없어질 수 있다.

본 발명의 목적은 시스템 이용 가능성 및 성능을 증가시키는 것이다.

본 발명의 다른 목적은 운영 시스템이 다수의 트랜잭션들을 처리할 수 있게 하여 시스템 제약(system constraints)으로 인해 시스템을 정지(shut down)시킬 필요가 없게 하는 것이다.

호스트들이 서로 통신하기 위하여 TCP/IP와 같은 통신 프로세서들을 이용하는, 복수의 프로세서들과 하나 이상의 중앙 메모리를 구비한 멀티-호스트 컴퓨터 환경에서는, 데이터 전송으로 인해 전체 시스템 동작의 중지 및 유휴 시간이 초래될 수 있다. 본 발명은, 데이터의 수신을 필요로 하는 프로세서들 중 하나로부터의 명령어를 수신함과 동시에 액티베이트_온_리시트 메커니즘을 이용하여 액티베이트_온_리시트 함수 호출(activate_on_receipt function call)을 발행하며, 그 후에 비로소 처리가 재개될 수 있다. 인입되는 데이터의 부분을 수신하기 위하여 작은 임시 기억 위치가 할당된다. 일단 수신된 데이터를 식별하고 요구 애플리케이션, 프로세서 및 통신 세션과 관련시키기 위한 수 개의 파라미터들도 전달된다. 그 사이에 시스템 환경은, 예를 들면 인입되는 데이터의 첫 번째 바이트들이 수신되는 때까지, 그 정상적인 프로세싱 연산을 계속 수행할 수 있다. 일 실시예에서는, 최초의 프로세스가 정식으로 종료되고 자원들이 자유로워진다. 다른 실시예에서는, 일단 첫 번째 바이트들이 수신되면, 액티베이트_온_리시트 메커니즘이, 인입되는 데이터를 처리하기 위한 새로운 프로세스를 생성하기 위하여 실행 중인 모든 프로세스를 종료시킨다. 만일 인입되는 데이터가 임시 할당된 기억 위치보다 크면, 남은 비트들이 수신되어 데이터 판독되기 전에, 그 데이터를 수용하도록 새로운 위치가 준비(set aside)된다. 만일 인입되는 데이터가 일시적으로 할당된 기억 위치보다 크지 않으면, 데이터는 그 임시 기억 위치로부터 판독되고 새로운 기억 위치가 할당되지 않는다.

도 1은 사용되는 통신 프로토콜의 개념상의 층 구성을 도시하는 블록도.

도 2는 본 발명의 개요에 관한 흐름도.

도 3은 본 발명의 특정 실시예에 관한 흐름도.

* 도면의 주요부분에 대한 부호의 설명

102 : 링크 층

104 : 머신-대-머신 층

106 : 포트-대-포트 층

108 : 애플리케이션 레벨

발명으로 간주되는 요지는 명세서의 결론부에 자세히 지적되고 명백하게 청구되어 있다. 그러나, 본 발명의 부가적인 목적 및 이점과 더불어 실제 구성 및 방법에 대해서는, 첨부 도면들과 관련된 이하의 설명을 참조함으로써 잘 이해될 수 있다.

수 개의 호스트 및/또는 원격 호스트들이 컴퓨터 네트워크로 접속되어 있는 경우, 그들간의 통신을 설정하고 유지할 필요가 생긴다. 통신이 가능하도록 하기 위하여, 호스트 컴퓨터들의 네트워크는 통신 링크들을 포함하는데, 그들 링크에는 서로 다른 종류의 호스트 컴퓨터들이 접속된다. 링크 상의 한 호스트로부터 링크 상의 다른 호스트로 메시지들이 송신되도록 하기 위하여, 통신 링크들을 제어하고 메시지의 루트를 정하고 링크 상의 적당한 호스트 컴퓨터들에 액세스하기 위한 프로토콜이라 불리는 규약들이 확립된다.

도 1에 도시된 바와 같이, 개념적으로 통신 프로토콜들이 층 구조를 이루는 것으로서 볼 수 있는데, 각 프로토콜 층은 그 바로 아래 층에 의해 제공되는 서비스들을 이용한다. 최하층은 하드웨어 레벨에서 작용하고 특정한 타입의 단일 네트워크 상의 호스트들 간의 데이터 전송을 제어하는 링크 층(102)이다. 다음의 상부층은 동일한 물리적 컴플렉스에 직접 접속되지 않은 호스트들 간에 통신할 수 있는 능력을 제공하는 머신-대-머신 (MM : Machine-to-Machine)(104) 층이다. 이 층의 널리 이용되는 예가 인터네트 프로토콜 (IP : Internet Protocol)이다. 인터네트 IP는 표준적인 소프트웨어 통신 패키지들의 사용을 허용하는 표준적인 산업용 통신 프로토콜이다.

다음의 상부 프로토콜 층은, 서로 다른 애플리케이션 프로그램들을 실행하는 다수의 프로세서들이 원격 호스트들에서의 원격 프로세스들과 동시에 통신할 수 있게 해주는 포트-대-포트 (PP : Port-to-Port)(106) 층이다. PP 층은 MM 프로토콜 층을 이용하여 호스트 머신들 간에 데이터를 전송한다. PP 층은, 프로세서에 국부 통신 포트(local communication port)를 할당하고 그 포트를 원격 호스트 상의 원격 포트에 접속시키고 그 국부 포트와 원격 포트간에 데이터를 전송하는 애플리케이션 층에 대해 인터페이스를 제공한다. 그런 PP 전송 프로토콜의 예들로는, TCP(Transmission Control Protocol), UDP(User Datagram Protocol) 및 XNS(Xerox Network System)이 있다. TCP는 IP 프로토콜 스위트 (IP suite of protocol)(TCP/IP)를 이용하는 장치들에서 동작할 수 있다.

최상층은 애플리케이션 레벨(108)이다. API들 역시 이 레벨에 존재한다. 게다가, 소켓 애플리케이션(socket application)들과 같은 다른 통신 애플리케이션도 이 레벨에 존재한다. 소켓 애플리케이션은 포트 식별자들을 TCP/IP 또는 다른 통신 세션 어드레스들과 연관시킴으로써 생성되는 고유의 호스트 식별자(host identifier)이다.

임의의 하이 레벨 애플리케이션, 특히 소켓 애플리케이션을 실행하는 동안에, 소정 타입의 명령어들로 인해 프로세싱 붕괴(processing disruption) 또는 자원들의 일시적인 펜딩(pending)이 초래될 수 있다. 이는 대개 데이터가 즉시 이용될 수 없는 경우이다. 예를 들면, TCP 프로토콜은 데이터에 액세스하기 위하여 read() 명령어를 이용했다. UDP는 TCP 프로토콜의 read() 명령어와 매우 유사한 유사 명령어 recv()/recvfrom() 함수 호출을 이용한다. read(), recv() 또는 recvfrom()의 어느 경우이든지 수신될 데이터(on-coming data)를 예상하여 프로세서에 의해 많은 부분의 메모리가 할당되고 준비된다. 이 할당되는 메모리 블록은 대개 최대 길이 또는 Max 데이터 길이가 32K에서 2 Megs 사이의 범위에 있을 수 있는 것으로 알려져 있다.

데이터가 즉시 수신되지 않는 경우, 데이터가 이용될 수 있을 때까지, 애플리케이션에 이용될 수 있는 대부분의 자원들은 중지 상태에 있게 되고 더 이상의 처리가 허용되지 않는다. 고성능 시스템에서는, 이로 인해 동시에 다수의 프로세서이 중지될 수 있다. 이 시스템 또는 프로세서 이용 불가능성은 후에 상세히 설명하겠지만 시스템이 블로킹 집합 연산을 실행하든지 또는 논-블로킹 집합 연산을 수행하든지 상관없이 발생된다.

A) 블로킹 연산

애플리케이션 또는 시스템이 블로킹 모드로 동작하는 경우, 프로세싱 연산들은 동기 모드로 수행된다. read(), recv() 또는 recvfrom() 명령어가 발행되었는데도 데이터가 즉시 이용될 수 없는 경우에 전체 시스템은 동기적으로 동작하기 않기 때문에, 데이터 바이트들이 인입될(come in) 때까지는 모든 스레드(thread)들은 유휴 상태로 있어야 한다. 데이터가 이용될 수 있을 때까지 더 이상의 프로세싱이 불가능하다. 더욱이 데이터의 수신을 위해 메모리의 많은 영역이 할당되어야 하기 때문에, 전체 시스템 환경이 영향을 받을 수 있다.

B) 논-블로킹 연산

논-블로킹 연산을 실행하는 동안에, 시스템의 프로세싱은 비동기적이며 따라서 데이터 판독/수신 명령어가 발행된 후에 프로세스는 블로킹 연산에서와 같은 식으로 유휴 상태에 놓이지 않는다. 그럼에도 불구하고, 데이터 수신 전의 전체 프로세스의 연산은 블로킹 모드로 동작하고 있는 때와 매우 유사하다. 논-블로킹 모드에서는, 시스템은 판독되는 데이터의 이용 가능성을 체크하고 데이터가 여전히 이용될 수 없음을 알아낼 때마다 결정을 해야 한다. 이 결정은, 연속적인 원리(continuous basis)에 기초하여 데이터의 이용 가능성을 계속하여 체크하거나 - 이는 블로킹 연산의 상황과 거의 유사한 상황을 발생시킴 -, 또는 현재 유휴 상태에 있는 프로세서들의 연속적인 연산에 필요한 공간 할당을 붕괴시키고 개조함으로써 할당된 메모리 공간을 재할당(reassign)해야 하는 것이다.

블로킹 또는 논-블로킹 어느 경우이든지, 최대 길이(Max 데이터 길이), 또는 데이터의 수신을 위해 할당된 메모리는 고성능 프로세스 시스템 내에서 이용될 수 있는 자원들의 연속적인 이용 가능성에 큰 문제를 일으킨다.

본 발명은 액티베이트_온_리시트 메커니즘을 통하여 상기 문제를 해결한다. 도 2에 도시된 바와 같이, (202)에 도시된 read(), recv(), recvfrom() 또는 다른 유사한 함수 호출 또는 명령어들을 수신함과 동시에, 본 발명은 액티베이트_온_리시트() 명령어라 불리는 새로운 함수 호출 (API)을 발행한다(204). 기본적으로, 이 새로운 함수 호출은 아무런 명령어도 발행되지 않은 것처럼 프로세스의 연산이 계속되도록 하여(206), 데이터의 첫 번째 바이트들이 도달하는 때까지 최초의 프로세스가 실행된다. 그러나, 어떤 상황에서는, 판독/수신(read/receive)이 발행된 후에 프로세스를 실제로 종료시킬 필요가 있을 수 있다. 본 발명의 대체 실시예에서는, 이 문제가 해결된다. 그런 경우에, 판독/수신의 최초의 발행에 의해 개시된 프로세스는 자원들을 자유롭게 하기 위하여 우선 종료되어야 한다. 그러나, 액티베이트_온_리시브 명령어 호출은 그런 종료에도 불구하고 요구 데이터를 얻는 일을 계속할 것이며 데이터가 도달하면, 이전 경우에서처럼 새로운 프로세스가 생성될 것이다. 어느 경우이든지, 인입되는 데이터의 적어도 일부를 수신하도록 바람직하게는 4K의 임시 기억 위치(208)가 메모리에 할당된다. 이로써, 2 Megs까지의 큰 영역을 이용하는 종래 기술에 반하여, 그런 데이터의 수신을 위해 작은 영역의 메모리가 준비될 수 있게 된다. 게다가, 프로세서에 의해서 보다는 시스템 자체에 의해서 매번 메모리의 최초 4K가 할당되며, 이는 공간 및 메모리 이용 가능성을 가장 효과적으로 이용할 것이다. 그 이유는, 시스템이 임의의 이용 가능한 포켓(pocket) 내에 영역을 할당할 수 있기 때문이며, 이는 프로세서들만이 보는 것보다 시스템이 그런 이용 가능성을 더 잘 볼 수 있기 때문이다.

각각의 액티베이트_온_리시트 호출과 함께, 나중의 프로세싱이 가능하도록 수 개의 파라미터들도 전달된다(205). 도 3에 도시된 바와 같이, 전달되는 파라미터들은, 명령어 또는 호출을 발행하는 호스트 및 애플리케이션을 장차 식별하기 위한 토큰 포인터(token pointer), 프로그램 명 포인터(program name pointer) 및 소켓 기술어(socket descriptor)이다(330). 소켓 기술어는, 애플리케이션에 의해 이전의 socket() API 함수 호출로부터 얻어지는 정수이며 애플리케이션의 TCP/IP 또는 다른 유사 프로토콜의 데이터 통신 세션의 절반과 관련된다(332). 프로그램 명 포인터는 데이터가 프로토콜의 데이터 통신의 다른 절반으로부터 호스트에 도달했을 때 입력되는 프로그램 명의 어드레스이다. 토큰 포인터는, 애플리케이션이 프로세스들 간에 전달하는 데이터를 포함하는 8 바이트 토큰의 어드레스를 포함한다.

소켓 애플리케이션이 activate_on_receipt() 함수 호출을 발행한 후에, 운영 시스템은 파일 기술어(file descriptor)라 불리는 소켓 기술어와 관련된 데이터 구조 내에 8 바이트 토큰 및 프로그램 명을 저장한다(334). 데이터가 들어오기 시작한 후에, 운영 시스템은 activate_on_receipt() 함수 호출을 read() 또는 recvfrom() 함수 호출로 변환시킨다. 만일 activate_on_receipt()이 소정의 스트림 또는 접속(connection) 지향 (TCP) 소켓을 위하여 발행되었다면, 시스템은 activate_on_receipt() 함수 호출을 read() 함수 호출로 변환시킨다. 만일 activate_on_receipt()이 데이터그램(datagram) 또는 비접속(connectionless)(UDP) 소켓을 위하여 발행되었다면, 시스템은 activate_on_receipt() 함수 호출을 recvfrom() 함수 호출로 변환시킨다. read() 또는 recvfrom()은 (32K 또는 그 이상의 요구의) 최대 길이를 갖는 TCP/IP 스택에 대해 발행된다.

도 2의 (214)에 도시된 바와 같이 데이터의 첫 번째 바이트들이 도달한 때를 메커니즘에 통지한다. 그때 메커니즘은 할당된 임시 기억 위치의 크기가 인입되는 데이터의 크기를 수용하는지를 판정한다.

수신된 데이터가 4K 할당 공간과 같거나 그보다 작을 경우, 수신되는 데이터의 나머지를 수신하기 위하여 더 이상의 공간이 할당되지 않을 것이다. 그러나, 데이터가 4K보다 클 경우, 수신되는 전체 데이터를 수용하기 위하여 더 많은 공간이 할당될 것이다(216).

첫 번째 데이터 바이트들이 할당된 위치에 수신되면, activate_on_receipt() 명령어는 최초의 프로세스를 종료시키고/종료시키거나 호스트 내에 새로운 프로세스를 생성한다는 점에서 시스템을 기동(activate)한다. 그 후, 데이터는 판독, 처리 또는 전송된다(213). (데이터가 도달한 후에, 시스템은 새로운 기억 영역을 확보하여 이 새로운 기억 영역에 데이터를 복사할 필요가 있을 수 있다(218). 그 후, 일단 데이터가 수신되면 함수 호출이 수행될 수 있다(220 내지 222)). 이 프로세스는 다음과 같이 상세히 수행된다.

도 3에 도시된 바와 같이, 파일 기술어는 이 TCP/IP 소켓과 관련된 소켓 기술어는 물론 이전에 저장된 8 바이트 토큰 및 프로그램 명이 있는 시스템 제어표의 위치를 알아내는 데 사용된다(338). 시스템은 내부 헤더로부터 얻어진 데이터의 길이, 기억 블록의 어드레스, 8 바이트 토큰 및 소켓 기술어를 시스템에 의해 생성될 새로운 프로세스와 관련된 다른 제어 블록에 복사한다. 만일 파일 기술어가 메시지가 데이터그램 소켓으로부터 수신되었음을 나타내면, 시스템은 내부 헤더로부터의 메시지의 소스 어드레스를 새로운 프로세스와 관련된 블록에 복사한다. 그 후 시스템은 새로운 프로세스를 생성하고(339) 파일 기술어로부터 그 프로그램 명이 얻어진 프로그램에 들어간다.

데이터를 얻기 위하여, 새로운 프로그램은 프로세스 중에 시스템에 의해 전달된 데이터를 이용하여 표준적인 read(), recv(), 또는 recvfrom() 소켓 API 함수 호출을 발행한다. 이 함수 호출은 TCP/IP 또는 다른 유사한 프로토콜의 스택에 송신되지 않는데, 그 이유는 시스템은 이미 네트워크로부터의 데이터를 보유하고 있음을 알기 때문이다. 이 두 번째 read(), recv() 또는 recvfrom() 함수 호출의 목적은, 프로그램이 그 자신의 버퍼 또는 운영 시스템에 의해 얻어지는 버퍼로부터 데이터를 얻을 수 있게 하려는 것이다. 애플리케이션이 read(), recv() 또는 recvfrom() 함수 호출을 발행한 후에, 시스템은 애플리케이션에 의해 지정된 버퍼 내의 데이터를 애플리케이션에 되돌려 준다.

본 발명의 바람직한 실시예에서, 데이터가 4K의 할당된 공간보다 클 경우, 데이터의 첫 번째 바이트들이 할당된 공간에 수신된 후에, 데이터를 획득하기 위하여 (345)에 도시된 바와 같이 read(), recv() 또는 recvfrom() 명령어가 발행되는데, 이는 인입되는 데이터의 전송 및/또는 복사를 위해 최대 길이 또는 다른 적절히 긴 공간을 할당한다. 그러나, 만일 수신될 데이터가 최초 할당된 4K의 공간에 포함될 수 있다면, (350)에 도시된 바와 같이, 앞의 경우의 read(), recv() 또는 recvfrom() 명령어 대신에 또 다른 activate_on_receipt 명령어가 발행된다. 이 두 번째 activate_on_receipt 함수 호출은 할당된 4K의 메모리에서 시스템에 의한 데이터의 프로세싱을 가능케 하여, 더 많은 메모리 공간을 더 할당할 필요가 없게 된다. 바꾸어 말하면, 보다 긴 데이터 바이트의 복사를 수용하기 위하여 최대 길이 공간이 할당되지 않는다.

이상과 같이, 본 발명에 따르면, 시스템 이용 가능성 및 성능이 증가되고, 또한 시스템이 다수의 트랜잭션들을 처리할 수 있게 되어 시스템 제약으로 인해 시스템을 정지시킬 필요가 없게 된다.

이상, 특정의 바람직한 실시예들에 따라서 본 발명을 상세히 설명하였지만, 당 기술분야의 숙련자들에 의해 많은 변형 및 변경이 이루어질 수 있다. 따라서, 첨부된 특허청구범위에 의해 본 발명의 진정한 사상 및 범위 내에 속하는 그런 변형 및 변경들을 포함하고자 한다.

Claims (14)

1. 호스트들 간의 통신을 위해 통신 프로토콜을 이용하는 멀티-호스트 컴퓨터 환경(multi-host computer environment)에서, 프로세싱 유휴 시간(processing idle time)을 발생시키지 않고서 데이터 전송 요구를 처리하기 위한 장치에 있어서, 상기 요구 데이터가 수신될 때까지 상기 시스템 환경이 프로세싱을 중지할 것을 요구하는 명령어를 상기 프로세서들 중 하나가 발행(issue)하는 경우 액티베이트_온_리시트 명령어(activate_on_receipt command)를 발행하기 위한 액티베이트_온_리시트 메커니즘, 상기 요구 데이터의 적어도 일부를 수신하기 위해 할당된 작은 임시 기억 위치(temporary storage location), 요구 프로세서, 그것의 실행 중인 애플리케이션들 및 그것의 관련된 통신 세션(communication session) 정보를 장차 추적(trace)하기 위해 메모리 위치에 제공되어 저장된 복수의 파라미터들, 요구 데이터의 첫 번째 바이트들이 상기 임시 기억 위치에 도달하고 수신되는 것을 알리기 위한 통지(notification) 메커니즘을 포함하며, 상기 액티베이트_온_메커니즘은, 상기 데이터가 수신되고 있다는 통지를 수신함과 동시에, 상기 시스템 환경 상에서 실행 중인 모든 연산들을 종료시키고 상기 요구 데이터를 처리하기 위한 새로운 프로세스를 생성하기 위한 수단을 구비하고, 상기 인입되는 데이터(in-coming data)가 상기 임시 기억 위치에 의해 할당된 상기 공간보다 크기가 큰지를 판정하기 위한 수단을 포함하는 데이터 전송 요구 처리 장치.
2. 제1항에 있어서, 상기 시스템 환경은 펜딩(pending) 중인 다른 연산들을 계속하여 처리할 수 있게 되고 상기 연산들은 상기 첫 번째 바이트들이 상기 할당된 임시 기억 위치에 도달하는 때에만 종료되는 데이터 전송 요구 처리 장치.
3. 제1항에 있어서, 상기 액티베이트_온_리시트 호출이 발행된 후에 시스템 자원들을 자유롭게(free up) 하기 위해 펜딩 중인 모든 연산들이 종료되고, 그 후에 상기 시스템 환경은 다른 프로세스들을 생성하고 착수할 수 있게 되며, 상기 할당된 임시 기억 위치에 상기 첫 번째 바이트들을 수신함과 동시에 상기 바이트들을 처리할 새로운 연산을 생성하기 위하여 실행 중인 모든 프로세스가 종료되는 데이터 전송 요구 처리 장치.
4. 제1항에 있어서, 상기 할당된 임시 기억 위치의 크기가 4K인 데이터 전송 요구 처리 장치.
5. 제1항에 있어서, 상기 데이터를 요구하는 상기 애플리케이션은 소켓 애플리케이션(socket application)이고 상기 컴퓨터 환경은 TCP/IP 통신 프로토콜을 이용하는 데이터 전송 요구 처리 장치.
6. 제3항에 있어서, 상기 프로세서 발행 명령어는 판독 함수 호출(read function call)인 데이터 전송 요구 처리 장치.
7. 제6항에 있어서, 상기 액티베이트_온_리시트 명령어 메커니즘은, 상기 데이터의 첫 번째 바이트들이 상기 할당된 임시 기억 위치에 수신된 후에 판독 명령어를 발행하는 데이터 전송 요구 처리 장치.
8. 제1항에 있어서, 상기 액티베이트_온_리시트 명령어 메커니즘은, 상기 인입되는 데이터의 상기 크기가 상기 할당된 임시 기억 위치의 크기를 초과하는 경우 인입되는 데이터 모두를 새로운 기억 위치에 복사하는 데이터 전송 요구 처리 장치.
9. 제1항에 있어서, 상기 액티베이트_온_리시트 명령어는 데이터그램(datagram) 또는 비접속(connectionless) 소켓을 위하여 발행되는 데이터 전송 요구 처리 장치.
10. 제9항에 있어서, 상기 프로세서 발행 명령어는 수신 함수 호출(receive function call)인 데이터 전송 요구 처리 장치.
11. 제9항에 있어서, 상기 프로세서 발행 명령어는 recvfrom() 함수 호출인 데이터 전송 요구 처리 장치.
12. 제9항에 있어서, 상기 통신 프로토콜은 UDP 프로토콜인 데이터 전송 요구 처리 장치.
13. 제11항에 있어서, 상기 메커니즘은, 데이터의 첫 번째 바이트들을 수신함과 동시에 recvfrom 함수 호출을 발행하는 데이터 전송 요구 처리 장치.
14. 제1항에 있어서, 상기 전달된 파라미터들은, 소켓 기술어(socket descriptor) 파라미터, 프로그램 명 포인터(program name pointer) 및 토큰 포인터(token pointer)를 포함하는 데이터 전송 요구 처리 장치.