KR20020066283A - 네트웍 메모리 관리 방법 및 그를 이용한 네트웍 드라이브장치 - Google Patents

Abstract

본 발명은 네트웍 메모리 관리 방법 및 네트웍 드라이브 장치에 관한 것으로서, 네트웍으로부터 수신한 데이터 패킷을 저장하는 메모리 관리 방법은, 네트웍 통신에 이용되는 데이터 패킷의 가능한 크기별로 소정 갯수의 버퍼들을 할당하는 단계; 수신된 데이터 패킷의 크기에 따라 할당되어 있는 버퍼들 중 한 버퍼의 어드레스를 지시하는 단계; 및 수신된 데이터 패킷을 지시된 어드레스상의 버퍼에 저장하는 단계를 포함함을 특징으로 한다.

본 발명에 의하면, 메모리 탐색 시간과 메모리 낭비를 줄이고, 데이터 복사 동작을 없애 네트웍 메모리를 효율적으로 관리할 수 있다.

Description

네트웍 메모리 관리 방법 및 그를 이용한 네트웍 드라이브 장치{Method for managing NDD-memory and network driver using the method}

본 발명은 네트웍 드라이버의 메모리 관리 방법에 관한 것으로서, 보다 상세하게는 딕셔너리를 이용하여 네트웍 메모리를 효율적으로 관리하는 엔디디 메모리의 고효율 관리 방법 및 그를 이용한 네트웍 드라이버에 관한 것이다.

여러개의 작업이 시간적으로(time-bound) 다중 처리 시퀀스상에 매어 있는 실시간 어플리케이션에 있어서, 메모리 관리는 간단치 않은 이슈가 된다. 특히, 추가 서비스로서 네트웍 기능을 지원하는 실시간 시스템들에서, 드라이버의 메모리 관리에 대한 작업은 실제로 매우 일반적인 것이 된다. 어떤 어플리케이션에서는, 사용자가 운영 시스템에 의해 제공된 메모리 관리 서비스를 사용하는 것을 선호하지만, 이것은 전체적인 자원 관리 동작을 수행하는 커널(kernel)에 부담을 주게 된다. 또, 사용자 고유 메모리 사용 특성들은 독립적으로 통합될 수 없으며, 어떤 경우 이러한 것은 자원 차단(resource blocking)이나 프래그먼테이션(fragmentation)으로 인해 사용 가능한 자원의 낭비를 초래한다. 시스템 메모리가 매우 한정되어 있는 경우, 이러한 이슈는 보다 민감한 것이 된다.

일반적으로 실시간 운영체제(OS)(RTOS) 커널은 시동 초기화 단계 직후 자체용도를 위한 메모리 자원을 미리 할당한다. 초기 메모리 할당 이후에는 필요에 따른 동적 수요를 두번 다시 요구하지 않는다는 것에 주목해야 한다. 한편, 커널은 보통 영역(regions)이라 불려지는 메모리를 연속적인 블록들로서 취급한다. 영역이란 프로세스에 특징적인 함의적 속성(process distinctive implicit attribute) 일 수 있으며, 메모리 블록은 영역들로부터 그 프로세스에 대해 할당될 수 있다. pSOS 운영 시스템에 있어서, 네트웍 관리 소자는 pNA+이라 불려지며 세(트리플릿, triplet) 메시지 블록 단위로 메모리를 관리한다. 이 트리플릿 구조의 성분인 버퍼는 데이터를 포함하는 연속적 메모리 블록으로 이뤄진다. 각 네트웍 동작을 위한 메모리 관리 서비스에 대해 네트웍 장치 드라이버(NDD)로부터 요청이 있을 때,pNA+ 요소는 사용 가능한 메시지 블록 트리플릿을 할당하여 외부 버퍼로부터 데이터를 복사한다. 할당 프로세스시, 메모리 관리 알고리즘은 적합한 버퍼를 찾아 그 안에 데이터를 복사해 놓는다. 따라서 적어도 한번의 데이터 복사 동작에 따라 동일한 데이터에 대해 두개의 메모리가 사용되고, 또한 실제 데이터 길이를 초과하는 버퍼 사이즈를 할당할 가능성이 생긴다. 또, 광범위한 탐색 알고리즘은 관련된 탐색 프로세스에 대해 긴 시간과 복잡함을 유발한다.

pNA+ 메모리 관리의 형태는 성능에 매우 결정적인 역할을 한다. 너무 적은 버퍼들이나 또는 틀린 사이즈로 버퍼를 형성하는 것은 성능 감소를 초래한다. 또 너무 많은 버퍼들을 구성하는 것은 상당한 정도의 메모리 낭비를 있게 한다.

도 1은 일반적인 pNA+ 소자의 소프트웨어적 구성도이다. pSOS와 같은 실시간 OS는 pNA+ 성분에 의해 네트웍 기능을 지원한다. pNA+ 성분의 소프트웨어 구조는 도 1에서와 같은 네 개의 서로 다른 계층들, 즉 소켓 계층(100), UDP/TCP 계층(110), IP(Internet protocol) 계층(120), 네트웍 인터페이스 계층(130)으로 이뤄진다. 도 1에 도시된 어플리케이션 계층(140)은 pNA+ 소자와 연계되는 커널에 속하는 소프트웨어 구성 요소로서 예를 들어 브라우저 등이 여기에 해당한다. 소켓(socket) 계층(100)은 하이 레벨 어플리케이션(어플리케이션 계층(140))과 TCP 또는 UDP 등의 기본 프로토콜(110) 사이의 인터페이스이다. TCP/UDP 계층(110)은 전송 계층(트랜스포테이션 계층)이라 불려지며 개별 패킷 버퍼에 대한 프로토콜 인터페이스를 지원한다. IP 계층(120)은 네트웍 인터페이스로의 데이터그램 전송에 관여하며 또한 패킷 조각화, 라우팅 메커니즘을 관리한다.

패킷이 도 1에 도시된 pNA+ 소자의 다양한 프로토콜 계층들을 통해 이동할 때, 각 패킷에 대해 여러 데이터 조작 동작이 일어난다. 이 동작은 다음과 같다:

a) 프로토콜 헤더의 추가/삽입

b) 패킷의 프래그먼테이션(fragmentation)/재배치

c) 패킷 복사

도 2는 한 메시지를 저장하기 위한 메시지 블록의 형태를 도시한 것으로서, 하나의 메시지는 트리플릿 구조의 세 블록에 나누어 저장된다. 각 메시지는 도 2와 같은 구조의 메시지 블록이 사슬처럼 연결되어 있는 메모리안에 차례로 저장된다. pNA+ 소자는 자가-구성 테이블(self-onfiguration table)을 보유하며 이 테이블 구조를 통해 메모리 관리를 지원한다. pNA+ 소자는 데이터 패킷들을 메시지로 불리는 기본 유니트로서 이해하고 그 메시지들은 테이블에 언급된 메시지 구조안에 보관된다. 메시지 구조는 도 2와 같이 단일-링크된 리스트를 통해 연관되어 있는 단일하거나 다중의 메시지-블록 트리플릿을 포함한다. 메시지 블록 트리플릿 각각은 연속적인 메모리 블록안에 전 메시지 중 일부를 포함한다. 메시지 블록은 트리플릿에 의해 규정된 부분적 메시지의 특징을 가진다. 데이터-블록(210)은 그것이 가리키는 버퍼(220)의 특징을 포함하며, 버퍼(220)는 데이터를 포함하는 연속적인 메모리 블록이다. 패킷이란 프로토콜 헤더와 그것이 요약한 데이터로 구성되는 네트웍 시스템의 기본 성분이다. 모든 패킷들은 메시지 구조(200)의 형태로 저장된다. pNA+ 소자는 필요시 메시지 블록 트리플릿을 할당하여 외부 버퍼로부터 추가 조작을 위한 프로토콜 계층들로 최종 패킷을 통과시키는 트리플릿과 관련된버퍼(210)로 데이터를 복사한다.

초기화 중에, pNA+ 소자는 메시지 블록(200)들, 데이터 블록(210)들 및 데이터 버퍼(220)들로 구성된 메모리 구조를 생성한다. 이 메모리 구조는 성능에 있어 중요한 것이다. 데이터 패킷 크기들이 급격하게 변화할 수 있기 때문에, 이 초기의 선구조화(pre-configuration)는 성능 감소나 메모리 낭비를 수반하게 된다. 동작의 최적성은 메모리 구성 패러미터들의 경험적인 튜닝에 달려있다. 따라서, 네트웍상에서 가변 패킷 길이에 대한 요구가 많으면, 가장 작은 적합한 버퍼를 다 써버리게 될 가능성이 크고 따라서 가장 큰 버퍼들의 할당으로 인해 메모리 낭비가 초래된다. 그러한 광범한 탐색을 행할 때 시간 문제는 응답 시간을 줄이는 우선권을 가지곤 한다.

이러한 상관 관계로부터, pNA+ 소자가 두 종류의 네트웍 인터페이스, 즉 pNA 종속적인 인터페이스와 pNA 독립적인 인터페이스를 지원한다는 것을 주목해야 한다. pNA 독립적인 시스템의 경우, 네트웍 인터페이스는 버퍼 풀(pool)을 유지하는데 관여하며 메모리 할당과 이들 패킷에 대한 할당 해제를 관리한다. 따라서, 이런 과정에 있어서, 메모리 관리 알고리즘은 네트웍 인터페이스와 밀접하게 관련되어 동작하며 필요시 pNA+에 서비스를 제공할 것이다. 따라서, 상술한 종래의 문제점들을 해결하기 위한 보다 효율적인 메모리 관리 알고리즘이 요구되고 있다.

본 발명이 이루고자 하는 기술적 과제는, 메모리 탐색 시간과 메모리 낭비를 줄이고, 데이터 복사 동작을 없앤 네트웍 메모리 관리 방법 및 네트웍 드라이브 장치를 제공하는데 있다.

도 1은 일반적인 pNA+ 소자의 소프트웨어적 구성도이다.

도 2는 한 메시지를 저장하기 위한 메시지 블록의 형태를 도시한 것이다.

도 3은 본 발명의 네트웍 메모리 관리 방법의 흐름도이다.

도 4는 상술한 딕셔너리의 구조를 도시한 것이다.

도 5는 본 발명의 네트웍 드라이브 장치의 구성을 도시한 것이다.

도 6은 운영체제와 네트웍 메모리 관리자를 결합한 소프트웨어 계층도를 도시한 것이다.

도 7은 DAT 생성에 관한 것을 도시하고 있다.

도 8은 일반적인 참조 오브젝트 레코드 북의 블록 구조를 도시하고 있다.

상기 과제를 해결하기 위한, 네트웍으로부터 수신한 데이터 패킷을 저장하는 메모리 관리 방법은, 네트웍 통신에 이용되는 데이터 패킷의 가능한 크기별로 소정 갯수의 버퍼들을 할당하는 단계; 수신된 데이터 패킷의 크기에 따라 상기 할당되어 있는 버퍼들 중 한 버퍼의 어드레스를 지시하는 단계; 및 상기 수신된 데이터 패킷을 지시된 어드레스상의 버퍼에 저장하는 단계를 포함함을 특징으로 한다.

상기 버퍼 어드레스 지시 단계는, 데이터 패킷 크기에 따라 해당 데이터 패킷을 수용할 수 있는 최적 크기의 버퍼들의 어드레스를 가리키는 어드레스 포인터 정보를 포함하도록 미리 형성된 딕셔너리를 이용함이 바람직하다.

상기 딕셔너리는 데이터 패킷 사이즈 별로 그 데이터 패킷을 수용할 수 있는 버퍼들의 어드레스를 가리키는 어드레스 포인터, 해당 버퍼의 상태를 나타내는 상태 플래그를 포함함이 바람직하다.

상기 상태 플래그는 해당 버퍼가 비어있는지 채워져 있는지를 나타내는 것임이 바람직하다.

수신된 데이터 패킷에 대해 상기 딕셔너리 상에서 해당 사이즈의 버퍼 어드레스 포인터들을 찾기 위해 해쉬(hash) 함수를 이용함이 바람직하다.

상기 과제를 해결하기 위한, 네트웍 드라이브 장치는 네트웍으로부터 수신된 데이터 패킷을 저장하는 여러가지 크기의 버퍼들로 이루어진 저장 메모리; 데이터 패킷이 수신되면 그 패킷이 저장되기 알맞은 상기 저장 메모리내 버퍼의 어드레스를 지시하는 딕셔너리; 및 상기 저장 메모리에 저장한 수신 데이터 패킷을 처리하는 프로세서를 포함함을 특징으로 한다.

상기 저장 메모리는, 65바이트 부터 1518바이트 까지의 데이터 패킷 크기 각각에 맞춰진 크기의 버퍼들로 구성됨이 바람직하다.

상기 딕셔너리는, 데이터 패킷 크기를 나타내는 인덱스; 및 상기 인덱스가 나타내는 데이터 패킷 크기에 알맞은 크기의 버퍼들의 어드레스를 지시하는 각각의 어드레스 포인터들을 포함함이 바람직하다.

상기 딕셔너리는, 어드레스 포인터와 나란히 해당 어드레스에 있는 버퍼가 비어있는지 채워져 있는지를 나타내는 상태 플래그를 더 포함함이 바람직하다.

이하에서 첨부된 도면을 참조하여 본 발명을 상세히 설명한다.

도 3은 본 발명의 네트웍 메모리 관리 방법의 흐름도이다. 단말에서, 네트웍으로부터 수신한 데이터 패킷을 저장하는 메모리 관리 방법은, 먼저 네트웍 통신에 이용되는 데이터 패킷의 가능한 크기별로 소정 갯수의 버퍼들을 할당해 놓는다(300단계). 수신된 데이터 패킷의 크기에 따라 상기 할당되어 있는 버퍼들 중 한 버퍼의 어드레스를 지시한다(310단계). 이 단계의 수행은, 수신된 데이터 패킷 크기에 알맞는 버퍼를 찾기 위해, 데이터 패킷 크기에 따라 해당 데이터 패킷을 수용할 수 있는 최적 크기의 버퍼들의 어드레스를 가리키는 어드레스 포인터 정보를 포함하도록 미리 형성된 딕셔너리를 이용할 수 있다. 수신된 데이터 패킷을 지시된 어드레스상의 버퍼에 저장한다(320단계).

도 4는 상술한 딕셔너리의 구조를 도시한 것으로서, 딕셔너리는 데이터 패킷사이즈를 나타내는 인덱스(i₁~i_n) 영역(400), 각각의 인덱스가 가리키는 크기의 데이터 패킷을 수용할 수 있는 버퍼들의 어드레스를 가리키는 어드레스 포인터(a₁~a_m) 영역(410)로 구성되며, 하나의 인덱스마다 사용자가 할당한 갯수만큼의, 해당 인덱스가 가리키는 데이터 패킷 크기를 최적의 용량으로 저장할 수 있는 동일한 용량의 버퍼들에 대한 어드레스가 대응되어 있다. 어드레스 포인터와 나란하게 해당 어드레스 포인터가 가리키는 버퍼가 채워졌는지 비어있는지를 나타내는 상태 플래그(SF₁~SF_m) 영역(420)이 더 포함된다. 네트웍으로부터 네트웍 장치에 데이터 패킷이 수신되면, 그 데이터 패킷의 크기를 토대로 딕셔너리의 해당 인덱스를 빠르게 찾기 위해 해쉬(hash) 함수가 이용된다.

도 5는 본 발명의 네트웍 드라이브 장치의 구성을 도시한 것으로서, 네트웍 드라이브 장치는 저장 메모리(500), 딕셔너리(510) 및 프로세서(520)를 구비한다. 저장 메모리(500)는 인터넷 등과 같은 소정 네트웍(530)으로부터 수신된 데이터 패킷을 별도의 복사나 임시 저장 없이 한번에 저장하는 메모리로서, 데이터 패킷 저장을 위해, 데이터 패킷의 크기별로 해당 패킷을 최적으로 저장가능한 버퍼들로 이루어진다. 딕셔너리(510)는, 데이터 패킷이 수신되면 그 패킷이 저장되기 알맞은 상기 저장 메모리내 버퍼의 어드레스를 지시하도록 된 것이다. 딕셔너리의 구조는 도 4에 도시된 바와 같다. 프로세서(520)은 네트웍과의 통신 및 수신된 데이터 패킷의 저장 및 제어 동작을 수행한다. 일반적으로 인터넷 등과 같은 네트웍에서 다루는 데이터 패킷의 크기는 65바이트에서 1518바이트까지 아므로, 저장메모리(500)를 이루는 버퍼 역시 그 크기를 반영한 용량을 가진 것들이어야 한다.

상술한 발명은 종래의 pNA를 개선한 것으로서, 데이터 카피 동작을 필요로 하지 않고, 패킷 사이즈에 따른 인덱스별로 구분된 테이블을 만들어, 하나의 인덱스안에, 해당 인덱스의 패킷 데이터가 저장가능한 블록 크기를 가진 메모리 블록들 각각의 점유 상태와 해당 블록이 위치된 장소의 어드레스 포인터를 그 내용으로 가지도록 미리 만들어진 테이블을 이용함으로써, 데이터 카피 동작 없이, 즉 일시적인 저장 개념 없이 패킷 크기에 적합한 메모리 블록을 찾아 안정적으로 패킷을 저장할 수 있고, 패킷 입력시 그 크기에 맞는 메모리 블록을 빠르게 찾아 낼 수 있다.

pNA+ 독립적 네트웍 인터페이스의 경우, 메모리 관리 계층은 커널과 네트웍 드라이버 사이에서 동작한다. 그래서, 이 소프트웨어 계층은 그 두 단말을 시각적으로 분리하지만 동작에 있어 일체성을 유지한다. 전체 구조가 도 6에 도시된다.

인터페이스 정의는 pNA+(620)와 네트웍 인터페이스(600)에 대해 매우 고유한 것이다. 네트웍 인터페이스(600)의 위에 있는 가상 관리자(610)의 통합은 통신 채널을 바꾸지만 가상 관리자(610)는 소자들(600, 620)간 기능적 일체성이 유지되도록 지원한다.

딕셔너리 개념에 대해 이하에서 설명한다. 많은 어플리케이션이 메모리 요구에 대한 동적 집합을 필요로한다. 패킷 크기들이 예측할 수 없는 방식으로 광범위하게 변하는 네트웍 드라이버의 경우가 바로 그렇다. 메모리 관리 인터페이스 계층의 설계에 있어, 그러한 집합들은 딕셔너리 동작에 의해 지원된다. 채택되는세 기본 동작들은 다음과 같다:

a) 삽입

b) 검색,

c) 갱신

딕셔너리 생성자는 처음부터 페이지들을 미리 생성하지 않는다는 것에 주목한다. 딕셔너리의 크기는 허용되는 레벨까지 점진적으로 증가된다. 메모리 관리자(610)는 커널 자원 풀로부터 점유된 메모리 안에서 딕셔너리를 구축한다. 이러한 자원의 동적 생성은 자원이 한정된 시스템에 매우 도움이 되며 어떤 점에서든 불필요한 자원의 소비를 방지한다. 동적 집합을 생성하기 위해, 다음과 같이 나타내어지는 직접-어드레스-테이블(DAT)이 형성된다:

(DAT)^l=T{0,1,2,....,m-1}, l=m.

여기서 T는 같은 성질을 가진 원소들의 한정된 주문 집합(finite ordered set)이다.

DAT의 원소에 대한 각 인덱스는 전체집합 U로부터 뽑아온 키(key)이다.

도 7은 DAT 생성에 관한 것을 도시하고 있다.

네트웍 인터페이스 계층의 경우, 드라이버 어플리케이션은 각 원소가 전체집합 U로부터 뽑힌 키를 포함하는 동적 집합을 필요로한다. 그러므로, 고유한 네트웍 인터페이스 드라이버(NID) 어플리케이션에 있어서, U 안의 영역은 다음과 같은 구획된 영역을 가진다:

U|_NID={0,1,....,m-l}, l≥m

이러한 설계 방식에 있어서, 키 인덱스화된 오브젝트들은 인덱스화된 위치에 직접적으로 저장되므로 메모리 공간을 효과적으로 절약하게 된다. 실제로, 오브젝트의 인덱스가 DAT에 상주하고, 그래서 해당 키가 검색될 수 있기 때문에, 오브젝트의 U로부터 뽑힌 키-필드를 저장하는 것은 불필요하다. T에는 인덱스화된 원소에 대해 두 개의 가능한 상태, 즉 비었거나 찬 두 상태가 있을 수 있다. 원소가 비어있다면, 요청시, 하나의 레코드가 동적으로 형성될 것이고 자원은 풀로부터 할당될 것이며, 이런 방식에 따라 레코드 북은 미리 점유함이 없이 필요에 따라 형성될 것이다.

전체집합 U가 크기는 하지만, 키 시퀀스 가능성은 다음과 같은 k_i로 한정된다.

특히, T에서 한 원소를 검색하는 것이 여전히 θ(1) 시간만을 필요로하기는 하지만, 저장용량의 필요성은 θ(|k|)까지 감소된다. 효율성의 측면에서 해쉬 함수 'h'가 선택되어 해쉬함수 처리된 키 'k'는 자기 인덱스를 도로 참조할 것이다. 따라서, 그것은 충돌 방지를 구현하는 개방 어드레스 해슁(hashing)의 한 방법이다. 이것은 다음과 같이 표현될 수 있다:

if K={k_i} and I={i_n} then h(K)∈ I,

즉, h(k_i)→i_n, ∀ k_i∈ K

이러한 구조는 충돌 없이 보다 빠른 검색과 함께 보다 빠른 인덱싱을 제공할 것이다.

어드레스 포인터에 해당하는 참조 오브젝트(도 7에서 "Ref."로 표현됨)의 개념에 대해 이하에서 설명한다.

참조 오브젝트는 동적 메모리 풀과 자원 딕셔너리 사이의 링크를 나타낸다. 이 오브젝트들은 외부 메모리 풀과 그 상태에 대한 개별적 참조를 포함하는 고유의 내부 레코드 북 구조를 포함한다. 따라서, DAT는 외부로부터 보이지 않는 레코드-북을 가진 직접 인덱스화된 오브젝트 스택으로서 보여질 수 있다.

도 8은 일반적인 참조 오브젝트 레코드 북의 블록 구조를 도시하고 있다.

드라이버로부터의 자원 요청시 동적으로 상기 오브젝트들을 생성하고 그리고나서 고유하게 요청된 패킷 길이의 외부 메모리 풀을 첨부하라고 지시하도록 알고리즘화된다. 매시간 참조 오브젝트에 작용하는 자원 할당 또는 할당 해제 방법은 레코드 북을 생성할 때 버퍼에 'Ref' 필드를 부착한 후 버퍼 풀 할당이나 할당 해제시 레코드 북의 상태 플래그(SF)를 동적으로 갱신할 수 있다. 이것은 레코드 북의 상태 플래그가 '잠금' 또는 '잠금해제'의 어느 때에나 이진 값이라는 것만을 추측할 수 있다. 직접 인덱스화된 레코드 북 구조는 할당 및 할당 해제 메커니즘을 매우 신속하게 처리할 것이기 때문에, 자원의 재할당은 점유된 자원의 해제후에 매우 빨라질 것이다. 개별적 레코드 북들의 길이는 적합한 버퍼 마크 값을 설정함으로써 초기화시 사용자 구성가능한 것으로서 만들어 질 수 있다.

메모리 풀(memory pool)에 대해 이하에서 설명한다.

메모리 풀은 최대 구성 가능 크기를 가지며 드라이버로부터의 요청시 엄밀하게는 서로 다른 크기로 동적으로 할당된다. 메모리 풀의 각 버퍼는 레코드 북에 표시된 상태와 관련된다. 버퍼 풀의 수는 0에서 필요에 따른 사용자 구성 가능 최대 한도까지 커질 수 있다. 자원 딕셔너리의 직접 인덱스 원소가 특정 풀 길이에 비례할 것이라는 것과 모든 인덱스화된 참조 오브젝트에 대해 풀이 내부 경계에 인접할 것임을 가정할 수 있다는 것에 주목한다. 불필요한 데이터 복사 동작은 직접 버퍼 후킹(hooking) 메커니즘으로 없앨 수 있다. 클라이언트는, 패킷 버퍼에 대한 요청시 풀에 연결된다(hooked). 첫번째 프로세스에 걸려 있을 때, 두번째 프로세스는 레코드 북 마크당 동일한 길이의 어느 비어있는 풀에 연결될 수 있다. 상이한 길이에 대한 다른 풀의 요청에 대해, 다른 인덱스화된 오브젝트가 메모리 할당을 위해 사용될 것이다.

이하에서 비상시의 메모리 자원에 대해 설명할 것이다.

메모리 관리자는 고정된 버퍼 길이의 비상 메모리 풀을 구축하기 위해 고정되어 인덱스화된 레코드 북을 유지한다. 그 레코드 북의 구조는 약간의 대체 사항들을 빼고는 이전에 설명한 바와 동일하다. 그 레코드 북의 길이는 고정되고 사용자 구성가능하며, 각 버퍼 길이는 동일할 것이다. 특정한 버퍼 길이에 대해, 딕셔너리의 모든 페이지들이 어느 순간 가득 차 있으면, 일시적 위기를 해소하기 위해 관리자에 의해 비상 풀이 사용될 것이다. 일단 위기가 지나면, 버퍼는 적합한 위치로 돌아올 것이다. 이 비상 풀은 클라이언트가 일반 풀(common pool)의 과도한 블록화로 인해 갑자기 결핍을 겪는 것을 방지한다.

본 발명에 의하면, 메모리 탐색 시간과 메모리 낭비를 줄이고, 데이터 복사 동작을 없애 네트웍 메모리를 효율적으로 관리할 수 있다.

Claims (10)

1. 네트웍으로부터 수신한 데이터 패킷을 저장하는 메모리 관리 방법에 있어서,

   네트웍 통신에 이용되는 데이터 패킷의 가능한 크기별로 소정 갯수의 버퍼들을 할당하는 단계;

   수신된 데이터 패킷의 크기에 따라 상기 할당되어 있는 버퍼들 중 한 버퍼의 어드레스를 지시하는 단계; 및

   상기 수신된 데이터 패킷을 지시된 어드레스상의 버퍼에 저장하는 단계를 포함함을 특징으로 하는 네트웍 메모리 관리 방법.
2. 제1항에 있어서, 상기 버퍼 어드레스 지시 단계는,

   데이터 패킷 크기에 따라 해당 데이터 패킷을 수용할 수 있는 최적 크기의 버퍼들의 어드레스를 가리키는 어드레스 포인터 정보를 포함하도록 미리 형성된 딕셔너리를 이용하는 것임을 특징으로 하는 네트웍 메모리 관리 방법.
3. 제2항에 있어서,

   상기 딕셔너리는 데이터 패킷 사이즈 별로 그 데이터 패킷을 수용할 수 있는버퍼들의 어드레스를 가리키는 어드레스 포인터, 해당 버퍼의 상태를 나타내는 상태 플래그를 포함함을 특징으로 하는 네트웍 메모리 관리 방법.
4. 제3항에 있어서,

   상기 상태 플래그는 해당 버퍼가 비어있는지 채워져 있는지를 나타내는 것임을 특징으로 하는 네트웍 메모리 관리 방법.
5. 제2항에 있어서,

   수신된 데이터 패킷에 대해 상기 딕셔너리 상에서 해당 사이즈의 버퍼 어드레스 포인터들을 찾기 위해 해쉬(hash) 함수를 이용함을 특징으로 하는 네트웍 메모리 관리 방법.
6. 네트웍으로부터 수신된 데이터 패킷을 저장하는 여러가지 크기의 버퍼들로 이루어진 저장 메모리;

   데이터 패킷이 수신되면 그 패킷이 저장되기 알맞은 상기 저장 메모리내 버퍼의 어드레스를 지시하는 딕셔너리; 및

   상기 저장 메모리에 저장한 수신 데이터 패킷을 처리하는 프로세서를 포함함을 특징으로 하는 네트웍 드라이브 장치.
7. 제6항에 있어서, 상기 저장 메모리는,

   65바이트 부터 1518바이트 까지의 데이터 패킷 크기 각각에 맞춰진 크기의 버퍼들로 구성됨을 특징으로 하는 네트웍 드라이브 장치.
8. 제7항에 있어서, 상기 저장 메모리는,

   패킷 크기별로 최적화된 일반 버퍼들과, 수신된 데이터 패킷을 저장할 때 일반 버퍼들이 모두 채워져 있는 경우 일시적으로 상기 데이터 패킷을 저장하는 소정 용량의 비상 버퍼들을 포함함을 특징으로 하는 네트웍 드라이브 장치.
9. 제7항에 있어서, 상기 상기 딕셔너리는,

   데이터 패킷 크기를 나타내는 인덱스; 및

   상기 인덱스가 나타내는 데이터 패킷 크기에 알맞은 크기의 버퍼들의 어드레스를 지시하는 각각의 어드레스 포인터들을 포함함을 특징으로 하는 네트웍 드라이브 장치.
10. 제9항에 있어서, 상기 어드레스 포인터와 나란히 해당 어드레스에 있는 버퍼가 비어있는지 채워져 있는지를 나타내는 상태 플래그를 더 포함함을 특징으로 하는 네트웍 드라이브 장치.