KR100441742B1 - 정보교환 버스를 이용한 프로세스간 통신 데이터 제어방법및 그 시스템 - Google Patents

Abstract

본 발명은 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 방법과 그 시스템에 관한 것이다.

본 발명에 따르면 세션 관리자가 정보교환 버스내에 하나의 공유 메모리를 생성하는 단계, 공유 메모리에 스케쥴러가 연동하는 단계, 세션 관리자가 해당 프로세스가 생성시 해당 프로세스를 정보교환 버스에 세션을 맺게 하는 단계, 정보교환 버스 애플리케이션 프로그래밍 인터페이스를 통하여 공유 메모리를 매개체로 프로세스와 스케쥴러가 연동하여 제1프로세스에서 제2프로세스로 필요한 데이터를 전달하는 단계로 구성된 프로세스간 통신 데이터 제어 방법과 그 시스템이 제공된다.

본 발명에 있어 뮤텍스나 세마포어 등을 사용하지 않고 정보교환 버스내에 하나의 공유 메모리만을 이용하여 데어터 제어 속도를 향상시킬 수 있는 효과를 제공한다.

Description

정보교환 버스를 이용한 프로세스간 통신 데이터 제어방법 및 그 시스템 {A METHOD FOR CONTROLLING INTER-PROCESS COMMUNICATION DATA USING AN INFORMATION EXCHANGE BUS AND THE SYSTEM THEREOF}

본 발명은 정보교환 버스를 이용한 프로세스간 통신 데이터 제어방법 및 그 시스템에 관한 것으로서, 좀 더 구체적으로는 프로세스간 통신 방법에 있어 정보교환 버스 애플리케이션 프로그래밍 인터페이스, 세션 관리자, 스케쥴러 및 하나의공유 메모리로 구성된 정보교환 버스를 이용한 프로세스간 통신 데이터 제어방법 및 그 시스템에 관한 것이다.

일반적으로 유선 또는 무선 통신 등에 관련한 대용량의 과금 데이터를 처리하는 과금 처리 시스템 등과 같은 복잡한 시스템은 기본적으로 다중 프로세스 및 다중 쓰레드 (multi-thread) 로 구성되며, 처리하는 데이터 속성에 따라 다양한 프로세스 및 쓰레드 경로를 흐르게 된다. 또한, 처리하는 데이터 양 등의 운영 환경에 따라 프로세스가 동적으로 생성 및 소멸되므로 시스템을 구성하는 프로세스가 유동적으로 연계되어 각 프로세스간에 데이터 전송 및 제어가 가능하여야 한다.

유닉스 계열의 운영체제에서는 이러한 여러 프로세스, 쓰레드 간에 데이터전달을 위하여 프로세스간 통신 (IPC : Inter-Process Communication) 방법, 즉 소켓 (Socket), 파이프 (Pipe), 메시지 큐 (Message Queue), 공유 메모리 (Shared Memory) 등의 방법이 사용되었다. 또 일반적으로 IPC 는 일대일 관계의 데이터 전달 기능을 제공한다.

특히 프로세스간 통신에 공유 메모리를 사용하는 경우에는 우선적으로 통신을 필요로 하는 각 프로세스간에 공유 메모리를 설정하고 각 프로세스간에 공유되는 자원인 공유 메모리의 일관성 (Consistency) 을 유지하기 위하여 뮤텍스 (Mutex), 세마포어 (Semaphore) 등을 이용한 동기화 (Synchronization) 기법을 사용하게 된다.

그러나 대용량의 데이터 전달을 위한 프로세스가 많아지는 경우 데이터 구성 및 흐름 제어가 복잡해 지며, 뮤텍스 등의 라이브러리를 사용함으로써 동기화에 대한 비용이 많아져서 성능이 저하되는 단점을 가지게 된다. 더욱이 동적인 프로세스간의 데이터 전달을 위해서는 프로세스 로직이 더욱 복잡해 지는 단점이 있다.

따라서, 본 발명의 목적은 상기의 문제를 해결하기 위하여 다수의 공유 메모리나 혹은 뮤텍스와 세마포어 등의 라이브러리의 사용없이, 정보교환 버스를 이용한 프로세스간 통신 제어방법 및 그 시스템을 제공하는 데 있다.

도 1 은 본 발명이 구체화된 소프트웨어가 실행하기 위한 컴퓨터 시스템의 일예를 도시한 도면이다.

도 2 는 본 발명이 구체화된 소프트웨어의 실행을 위한 컴퓨터 시스템의 시스템 블럭도이다.

도 3 은 본 발명에 따른 정보교환 버스를 이용한 프로세스간 통신 제어 시스템을 차징 게이트웨이에 적용하여 도시한 블럭도이다.

도 4 는 본 발명에 따른 차징 게이트웨이에 적용한 정보 교환 버스 (IX Bus : Information eXchange Bus) 의 구성도이다.

도 5 는 공유 메모리의 전체적인 구조를 도시한 구성도이다.

도 6 은 본 발명에 따른 CRB, PCB, OCB 블럭간의 관계를 도시하는 블럭도이다.

도 7 은 본 발명에 따른 IB 블럭의 논리적인 구조 및 IB 블럭들로 구성된 메시지 큐에 대한 구성도이다.

도 8 는 공유 메모리 접근에 대한 논리적인 구성도이다.

도 9 는 프로세스가 IX Bus 와 세션을 연결하는 과정을 도시한 구성도이다.

도 10 은 세션 설정시부터 프로세스간 데이터가 전달되는 과정을 도시한 도면이다.

도 11 은 IX Bus 에 메시지 전송을 도시하는 순서도이다.

도 12 는 IX Bus 에서 메시지를 읽는 과정을 도시한 순서도이다.

도 13 는 세션 종료에 대한 과정을 도시하는 순서도이다.

도 14 은 스케쥴러의 과정을 도시하는 순서도이다.

도 15 는 스케쥴러의 또 다른 데이터 전달을 도시하는 구성도이다.

도 16 및 도 17 은 본 발명에 따른 프로세스간의 데이터 전달을 도시하는 구성도이다.

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

100 : 컴퓨터 시스템 101 : 디스플레이

102 : 화면 103 : 본체

104 : CD-ROM 드라이브 105 : 키보드

106 : 마우스 107 : CD-ROM

201 : 프로세서 202 : 시스템 메로리

203 : 고정 디스크 204 : 착탈식 디스크

205 : 시스템 버스 206 : 디스플레이 어댑터

207 : 사운드 카드 208 : 스피커

209 : 네트워크 인터페이스 300 : 차징 게이트웨이

301 : GTP' 프로세스 302 : ASN.1 Parser 프로세스

303 : A/G (Aggregate) 프로세스 304 : C/R (Correlate) 프로세스

305 : F/T (Filter) 프로세스 306 : D/T (Distributor) 프로세스

310 : SGSN(Serving GPRS Support Node)

320 : GGSN(Gateway GPRS Support Node)

330 : 빌링 시스템 340 : 통계 시스템

400 : 정보 교환 버스 (IX Bus : Information eXchange Bus)

401 : 공유 메모리

402 : 정보 교환 버스 에플리케이션 프로그래밍 인터페이스 (IX Bus API : IX Bus Application Programming Interface)

403 : 세션 관리자 404 : 스케쥴러

501 : 정보교환 공통 블럭 502 : 클래스 참조 블럭 (CRB)

503 : 프로세스 제어 블럭 (PCB) 504 : 오픈 제어 블럭 (OCB)

505 : 정보 블럭 (IB)

본 발명에 따르면 세션 관리자가 정보교환 버스내에 하나의 공유 메모리를 생성하는 단계, 공유 메모리에 스케쥴러가 연동하는 단계, 세션 관리자가 해당 프로세스가 생성시 해당 프로세스를 정보교환 버스에 세션을 맺게 하는 단계, 정보교환 버스 애플리케이션 프로그래밍 인터페이스를 통하여 공유 메모리를 매개체로 프로세스와 스케쥴러가 연동하여 제1프로세스에서 제2프로세스로 필요한 데이터를 전달하는 단계로 구성된 정보교환버스를 이용한 프로세스간 데이터 제어 방법이 제공된다.

공유 메모리는 정보교환 공통 블럭, 클래스 참조 블럭, 프로세스 제어 블럭, 오픈 제어 블럭 및 정보 블럭으로 구성되고, 블럭들 중 정보교환 공통 블럭은 프로세스 각각에 대하여 설정되며 나머지 블럭들은 미사용으로 설정되며, 세션을 맺는 단계는 프로세스의 요청 신호를 받아 세션 관리자가 오픈 제어 블럭을 할당하여 프로세스 제어 블럭과 연결된다.

또 데이터 전달 단계는 제1프로세스는 자기의 스케쥴 토큰에 쓰기 요청을 하여 스케쥴러가 스케쥴 토큰을 검색하여 요청된 쓰기 작업을 하고, 제2프로세스는 자기의 스케쥴 토큰에 읽기 요청을 하면 스케쥴러가 스케쥴 토큰을 검색하여 요청된 읽기 작업을 함으로써 이루어 진다.

본 발명에 따르면 정보교환 버스를 이용한 프로세스간 데이터 제어 시스템이 제공되는 데, 이 시스템은 정보교환 버스는 세션 관리자, 스케쥴러, 정보교환버스 애플리케이션 프로그래밍 인터페이스 및 공유 메모리로 구성되어 메모리상에 코딩되며, 세션 관리자가 정보교환 버스내에 하나의 공유 메모리를 생성하는 코드, 공유 메모리에 스케쥴러가 연동하는 코드, 세션 관리자가 해당 프로세스가 생성시 해당 프로세스를 정보교환 버스에 세션을 맺게 하는 코드 및 정보교환 버스 애플리케이션 프로그래밍 인터페이스를 통하여 공유 메모리를 매개체로 프로세스와 스케쥴러가 연동하여 제1프로세스에서 제2프로세스로 필요한 데이터를 전달하는 코드로 구성된 것을 특징으로 한다.

공유 메로리 코드는 정보교환 공통 블럭, 클래스 참조 블럭, 프로세스 제어블럭, 오픈 제어 블럭 및 정보 블럭으로 구성된 코드이고, 블럭들 중 정보교환 공통 블럭은 프로세스 각각에 대하여 설정되며 나머지 블럭들은 미사용으로 설정되는 코드이며, 세션을 맺는 코드는 프로세스의 요청 신호를 받아 세션 관리자가 오픈 제어 블럭을 할당하여 프로세스 제어 블럭과 연결시키는 코드이다.

또한, 데이터 전달 코드는 제1프로세스는 자기의 스케쥴 토큰에 쓰기 요청을 하여 스케쥴러가 스케쥴 토큰을 검색하여 요청된 쓰기 작업을 하고, 제2프로세스는 자기의 스케쥴 토큰에 읽기 요청을 하면 스케쥴러가 스케쥴 토큰을 검색하여 요청된 읽기 작업을 함으로써 이루어 지는 코드인 것을 특징으로 한다.

본 발명에 있어서는 프로세스가 쓰레드의 의미로 사용될 수 있으며, 경우에 따라서는 데이터, 메시지 또는 정보가 동일한 의미로 사용될 수 있다. 또한 컴퓨터 시스템에 대한 일반적인 내용은 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 자명한 사항이기 때문에 그 상세한 내용을 생략한다.

이하, 도면을 참조하여 본 발명을 설명하기로 한다.

도 1 는 본 발명이 구체화된 소프트웨어가 실행하기 위한 컴퓨터 시스템 (100) 의 일예를 도시한 도면이다. 도 1 의 컴퓨터 시스템은 디스플레이 (101), 화면 (102), 본체 (103), 키보드 (105) 와 마우스 (106) 를 포함한다. 마우스 (106) 는 GUI (Graphical User Interface) 와 동작하기 위한 하나 이상의 버튼을 가진다. 본체 (103) 는 CD-ROM 드라이브(104) 및 본 발명을 구현한 컴퓨터 코드와 본 발명에 필요한 데이터 등을 저장 및 검색을 위한 시스템 메모리, 하드 드라이브를 가진다. CD-ROM (107) 이 대표적인 컴퓨터 저장 매체로 표시 되었으나, 기타 플로피 디스크, 테이프, 플래쉬 메모리, 시스템 메모리, 하드 드라이브 등이 사용될 수 있다.

도 2 는 본 발명이 구체화된 소프트웨어의 실행을 위한 컴퓨터 시스템 (100) 의 시스템 블럭도이다. 도 2 의 컴퓨터 시스템 (100) 은 디스플레이 (101), 키보드 (105) 와 마우스 (106) 를 포함할 뿐만 아니라 중앙 프로세서 (201), 시스템 메모리 (202), 하드 디스크 등과 같은 고정 디스크 (203), CD-ROM 드라이브 등과 같은 착탈식 디스크 (204), 디스플레이 어댑터 (206), 사운드 카드 (207), 스피커(208), 네트워크 인터페이스 (209) 등과 같은 서브시스템을 가진다. 본 발명의 수행에 적합한 컴퓨터 시스템은 더 많거나 적은 서브시스템을 가질 수 있다. 예를 들면 두 개 이상의 프로세서를 가진 컴퓨터 시스템이 본 발명에 사용될 수 있다.

화살표 (205) 는 컴퓨터 시스템의 시스템 버스 구조를 표시한다. 이 화살표(205) 는 서브시스템을 연결하기 위한 모든 종류의 연결 방법을 나타낸다. 예를 들면, 로컬 버스는 중앙 프로세서 (201) 와 시스템 메모리 (202) 또는 디스플레이 어댑터 (206) 를 연결하기 위해 사용된다.

도 2 에 도시된 컴퓨터 시스템 (100) 은 본 발명에 사용되는 컴퓨터 시스템의 일예이며, 본 발명에 적합하도록 다른 다양한 서브시스템으로 구성된 컴퓨터 시스템이 사용될 수 있다. 예를 들어 이러한 컴퓨터 시스템에는 차징 게이트웨이 시스템 (Charging Gateway System), 미디에이션 시스템 (Mediation System) 또는 레이팅 시스템 (Rating System) 이 될 수 있다.

도 3 은 본 발명의 바람직한 실시예에 따른 정보교환 버스를 이용한 프로세스간 통신 제어 시스템을 차징 게이트웨이 (300) 에 적용하여 도시한 블럭도이다.

차징 게이트웨이 (300) 는 이동통신의 패킷망을 구성하는 네트워크 장비인 SGSN (Serving GPRS Support Node) (310) 과 GGSN (Gateway GPRS Support Node) (320) 으로부터 과금 데이터 레코드 (CDR : Charging Data Record) 를 수집하여 과금 데이터를 필요로 하는 빌링 시스템 (330) 또는 통계 시스템 (340) 에 맞도록 CDR 을 가공하여 배포하는 기능을 제공한다. 여기서 GPRS (general packet radio services) 는 패킷 기반의 무선통신 서비스로서, 휴대폰 및 컴퓨터 사용자들은 인터넷 접속과 화상회의에 참가할 수 있고 나아가 노트북컴퓨터는 물론 휴대용 장치를 사용하여 멀티미디어 웹사이트 등과 상호 통신을 가능케 하는 패킷 기반의 무선통신망을 말한다.

GGSN (320) 과 SGSN (310) 이 생성하는 CDR 종류는 외부 데이터 네트워크 사용에 관한 과금정보를 가지는 G-CDR, 내부 네트워크 사용에 관한 과금정보를 가지는 S-CDR, 단말기 이동정보를 가지는 M-CDR, 문자 메시지에 대한 과금 정보를 가지는 S-SMO-CDR 및 S-SMT-CDR 이 있으며, 이중 G-CDR, S-CDR, M-CDR은 시간 제한 등으로 인해 부분 (Partial) CDR 이 생성될 수 있다. 부분 CDR은 하나의 과금 정보가 하나의 CDR 에 포함되는 것이 아니라 여러 CDR 에 나누어져 생성되는 것을 의미한다.

위와 같은 환경에서 CDR 을 수집, 가공 및 배포하기 위하여 차징 게이트웨이(300) 는 GTP' 프로세스 (301), ASN.1 Parser 프로세스 (302), A/G (Aggregate) 프로세스 (303), C/R (Correlate) 프로세스 (304), F/T (Filter) 프로세스 (305) 및 D/T (Distributor) 프로세스 (306) 로 구성된다.

GTP' 프로세스 (301) 는 SGSN (310) 과 GGSN (320) 으로부터 GTP' (GPRS Tunneling Protocol Prime) 프로토콜을 통하여 CDR 을 수집하는 기능을 제공하고, ASN.1 Parser 프로세스 (302) 는 인코딩된 CDR 데이터를 디코딩하여 표준 포맷으로 변환하는 기능을 제공한다. A/G 프로세스 (303) 는 각 CDR 종류 별로 부분 CDR 을 하나의 CDR 로 합치는 기능을 제공하고, C/R 프로세스 (304) 는 하나의 세션에 속하는 S-CDR, G-CDR 을 하나의 CDR 로 생성하는 기능을 제공한다. F/T 프로세스(305) 는 빌링 시스템 (330) 또는 통계 시스템 (340) 에 맞도록 CDR 의 여러 필드 중 필요한 필드만 필터링 하는 기능을 제공하고, D/T 프로세스 (306) 는 과금 데이터를 필요로 하는 빌링 시스템 (330) 또는 통계 시스템 (340) 에 과금 데이터를 전송하는 기능을 제공한다.

CDR 의 종류 및 특성에 따라 CDR 은 상술한 다양한 프로세스 (301 - 306) 를 거치게 된다. 예를 들어 부분 CDR 이 아닌 경우, A/G 프로세스 (303) 가 필요 없으며, 문자 메시지에 관련된 S-SMO-CDR, S-SMT-CDR 은 A/G 프로세스 (303) 및 C/R 프로세스 (304) 가 필요 없다. 또한 처리되는 CDR 양에 따라 ASN.1 Parser 프로세스 (302) 등이 동적으로 생성 및 종료되게 된다.

도 4 는 본 발명의 바람직한 실시예에 따라 차징 게이트웨이에 적용한 정보 교환 버스 (IX Bus : Information eXchange Bus) (400) 의 구성도이다. 정보 교환 버스 (400) 는 세션 관리자 (403), 스케쥴러 (404), 정보 교환 버스 애플리케이션 프로그래밍 인터페이스 (IX Bus API : IX Bus Application Programming Interface) (402) 및 공유 메모리 (401) 로 구성된다. 세션 관리자 (403) 는 차징 게이트웨이 (300) 를 구성하는 프로세스 (301 - 306) 가 IX Bus (400) 와 세션을 맺도록 제공되며, 스케줄러 (404) 는 프로세스 (301 - 306) 간 메시지 라우팅 및 공유 메모리 (401) 관리 등의 메시지 처리 엔진 기능을 담당한다. IX Bus API (402) 는 프로세스 (301 - 306) 와 IX Bus (400) 간의 연동을 위한 인터페이스 기능을 하여 세션 연결을 위한 open( ), 세션 종료를 위한 close( ), 메시지 읽기를 위한 read( ) 및 메시지 쓰기를 위한 write ( ) 를 제공한다.

도 5 는 공유 메모리 (401) 의 전체적인 구조를 나타낸다. 공유 메모리 (401) 는 여러 응용 프로세스 (301 - 306) 에 사용되며, 정보교환 공통 블럭 (IX Common Block) (501), 클래스 참조 블럭 (CRB : Class Reference Block) (502), 프로세스 제어 블럭 (PCB : Process Control Block) (503), 오픈 제어 블럭 (OCB : Open Control Block) (504) 및 정보 블럭 (IB : Information Block) (505) 으로 구성된다. 공유 메모리 (401) 는 도 5 에 도시된 바와 같이 연속적인 블럭의 집합이며, 각 블럭별로 크기 및 개수는 한정되도록 구성될 수 있다. 각 블럭을 미리 한정시켜 할당함으로써 재사용을 통해 성능이나 처리속도를 향상시킬 수 있다.

IX 공통 블럭 (501) 은 CRB (502), PCB (503), OCB (504) 및 IB (505) 각각에 대하여 블럭 시작 위치와 미사용 (free) 블럭 인덱스를 가지며 공유 메모리의 전체적인 구조에 대한 정보를 유지한다. 여기서 미사용 (free) 블럭 인덱스는 미사용 CRB 인덱스, 미사용 PCB 인덱스, 미사용 OCB 인덱스 및 미사용 IB 인덱스를 말한다.

도 6 은 본 발명에 따른 CRB, PCB, OCB 블럭간의 관계를 도시하는 블럭도이다. CRB 블럭 (502) 은 IX Bus 와 연동되는 차징 게이트웨이 프로세스 (301 - 306) 각각에 대한 템플릿을 제공하게 되며, 해당 프로세스가 생성시 이에 해당하는 PCB 블럭 (503) 이 할당된다. 동일 프로세스가 또 생성되는 경우에는 이에 해당하는 다른 PCB 블럭 (503a) 이 할당된다. 처음 프로세스에서 메시지 전달을 위하여 세션을 연결시 이를 위해 하나의 OCB 블럭 (504) 이 할당된다. 동일 프로세스에서 세션을 연결시 이에 해당하는 다른 하나의 OCB 블럭 (504a) 이 할당된다. 이와 같이 PCB블럭은 IX Bus 와 연동되는 프로세스를 표현하며, OCB 블럭은 프로세스와 IX Bus 간의 실제적인 인터페이스를 표현한다. 이러한 논리적인 구조를 위해 각 CRB, PCB, OCB 블럭의 구조는 다음과 같다.

CRB 블럭은 클래스 아이디, PCB 블럭 인덱스, 입력 큐 헤더 (header) 인덱스, 입력 큐 테일 (tail) 인덱스, 인접 CRB 인덱스 등과 같은 정보를 유지한다.

PCB 블럭은 CRB 블럭 인덱스, OCB 블럭 인덱스, 논리적인 프로세스 아이디, 물리적인 프로세스 아이디 등과 같은 정보를 유지한다. OCB 블럭은 PCB 인덱스, 입출력 모드, 입력 큐 헤더 인덱스, 입력 큐 테일 인덱스, 출력 큐 헤더 인덱스, 출력 큐 테일 인덱스, 스케줄 토큰 (Schedule Token) 등과 같은 정보를 유지한다.

이와 같이 CRB 블럭과 PCB 블럭이 분리함으로써 동일 프로세스가 다중으로 생성되는 것을 지원할 수 있다. 또한 메시지 큐를 CRB 와 OCB 블럭에 둠으로써, 프로세스의 동적인 생성 및 소멸을 지원할 수 있다. 예를 들면, 프로세스 종료시 해당 OCB 블럭에 메시지가 존재하는 경우 OCB 블럭을 포함하는 CRB 블럭의 메시지 큐에 메시지를 전달한다.

정보교환 버스 (400) 를 도 4 및 도 5 를 참조하여 자세히 설명하면, 우선 세션 관리자 (403) 에 의해 공유 메모리 (401) 가 생성 (초기화) 된다. 공유 메모리 (401) 가 생성될 때에는 환경 정보 화일에서 CRB, PCB, OCB 및 IB 블럭에 대한 정보 (할당된 블럭 개수 등) 를 읽어서 도 5 와 같이 공유 메모리에 IX 공통 블럭, CRB, PCB, OCB 및 IB 블럭이 설정되고, 프로세스에 연동되는 CRB 블럭은 프로세스에 각각 설정되며 나머지 블럭은 프리 리스트 (free list) 로 관리된다.

그리고, 스케쥴러 (404) 가 기동되어 도 13 과 같이 무한 루프를 돌면서 OCB 블럭을 검사하여 요청된 사항을 처리하도록 한다.

상기와 같이 IX BUS가 실행되기 위한 과정, 즉 공유 메모리가 생성되고 스케쥴러가 기동되는 과정을 초기화 과정이라 하고, 초기화 과정이 생성된 후에야 비로소 프로세스가 IX BUS 를 사용할 수 있게 된다. 프로세스가 IX BUS 를 억세스 가능하므로 프로세스간에 데이터 전달 내지는 제어가 가능하게 되어 목적하는 바를 본 발명에 따라 달성있다.

초기화 과정이 끝나면 의도한 작업이 프로세스에 따라 프로세스간 데이터 통신을 통해 프로세스, 세션 관리자 및 스케쥴러의 유기적 관계에 의해 이루어 진다. 즉 초기화 과정이 끝난 후 특정 프로세스, 예를 들면 GTP' 프로세스, ASN.1 Parser 프로세스 등이 정보교환 버스와 세션을 맺도록 기동된다. 이는 해당 프로세스가 IX BUS API 의 open() 을 호출함으로써 open() 함수 내부에서는 소켓 (UDP) 을 통하여 세션 관리자와 연동된다. 그러면 세션 관리자는 요청된 세션을 위한 OCB 블럭을 할당한다. 즉 세션 연결후 공유 메모리의 구성은 도 6 에 도시된 바와 같이 CRB (502), PCB (503) 및 OCB (504) 의 구성처럼 된다. 그리고 세션을 맺는 과정은 도 8 에서 후술되는 바와 같이 A/G 프로세스 (303) 를 예를 들어 상세히 설명되는 바와 같다.

논리적인 정보교환 버스의 이해를 돕기 위해 도 7 내지 도 9 를 설명한 후에 차징 게이트웨이의 프로세스 중 2 개의 프로세스간에 데이터 전달이 공유 메모리를 통해 어떻게 진행되는지를 살펴본다.

도 7 은 본 발명에 따른 IB 블럭의 논리적인 구조 및 IB 블럭들로 구성된 메시지 큐에 대한 구성도이다. 전체 IB 블럭은 IX Bus 에 전달된 메시지를 저장하기 위한 메시지 버퍼 풀 (pool) 영역을 제공하며, 각 IB 블럭 (601 - 603) 은 일정 크기의 바이트로 할당된다. IX Bus 에 전달된 메시지의 크기는 가변적이기 때문에 할당된 일정 크기의 바이트를 넘는 경우 IB 블럭은 두 가지 타입의 구조를 가지게 된다. 메시지를 저장하는 첫 번째 IB 블럭 (601) 은 메시지 길이, 인접 IB 인덱스, 다음 IB 인덱스, 메시지 버퍼를 가진다. 메시지 크기가 하나의 IB 블럭에 할당된 것 보다 큰 크기의 바이트인 경우에는 다른 IB 블럭 (602) 이 할당되며 이 블럭은 인접 IB 인덱스 (604) 에 의하여 연결되어 하나의 메시지 버퍼 (606) 를 가진다. 즉 메시지를 저장하기 위한 충분한 저장 공간을 확보할 때까지 반복하여 IB 블럭이 할당된다. 하나의 메시지를 구성하는 첫 번째 IB 블럭 (601) 의 다음 IB 인덱스 (605) 에 의하여 다음 메시지 (603) 를 지칭하게 된다.

IB 블럭은 이와 같은 방식으로 메시지의 리스트를 구성하면서 큐 헤더 인덱스는 리스트의 처음 메시지의 IB 블럭 (601) 을 가리키며 큐 테일 인덱스는 리스트의 마지막 메시지 IB 블럭 (603) 을 지정함으로써 메시지 큐를 구성한다. 이와 같은 구성을 통하여 IB 블럭은 가변 길이의 메시지 저장을 지원하는 메시지 큐를 위한 저장 영역을 제공한다.

도 8 는 공유 메모리 접근에 대한 논리적인 구성도로서, 그 이해를 돕기 위해 2 개의 프로세스만을 도시하였다. 본 발명의 GTP' 프로세스 (301) 와 D/T 프로세스 (302) 등의 프로세스들은 비용이 높은 운영체계가 지원하는 세마포어 등의 라이브러리를 이용한 동기화 방법을 사용하지 않고서 하나의 공유 메모리 (401) 를 사용하여 각 프로세스 별로 접근하는 영역을 논리적으로 분리시킨 것을 도시하고 있다.

즉 GTP' 프로세스 (301) 는 IX Bus API (402) 를 통하여 할당된 일부 공유 메모리인 OCB (504) 영역과 이 OCB (504) 영역에 할당된 IB (504') 영역만을 사용하며, D/T 프로세스 (306) 는 이에 할당된 OCB (505) 영역과 이 OCB (505) 영역에 할당된 IB (505') 영역을 사용하게 된다.

GTP' 프로세스 (301) 는 원하는 작업 (메시지 읽기, 쓰기 등) 을 해당 OCB (504) 블럭의 스케쥴 토큰 (405) 에 설정함으로써 요청하게 되고 요청이 완료되기를 대기한다. 스케쥴러 (404) 는 OCB 의 스케쥴 토큰 (405) 을 통하여 요청된 사항을 수행한 후 이에 대한 수행 여부를 스케쥴 토큰에 지정하는 방식으로 동작한다. 상기와 같이 스케쥴 토큰에 의해서 스케쥴러 (404) 와 GTP' 프로세스 (301) 는 상호간의 충돌을 배제한다. 스케쥴 토큰 (405) 에 요청되는 것은 스케쥴러 서비스 요청 (Scheduler Service Requested), 스케쥴러 서비스 완료 (Scheduler Service Done), 읽기 요청 (Read Request), 쓰기 요청 (Write Request), 자유 블럭 할당 요청 (Free Block Allocation Request), 읽기 완료 요청 (Read Done Request) 및 종료 요청 (Close Request) 이 있으며 동시에 하나 이상의 요청이 지정될 수 있다. 각 요청은 스케줄 토큰 (405) 의 특정 비트를 설정함으로써 이루어 진다.

도 9 는 프로세스가 IX Bus 와 세션을 연결하는 과정을 도시한 구성도이다. 예를 들어 A/G 프로세스 (303) 가 타 프로세스와 메시지 전달을 위해서는 IX Bus와 세션을 연결하여야 한다. A/G 프로세스 (303) 가 IX Bus API (402) 의 Open ( ) 을 호출함으로써 수행되며, 내부적으로 TCP/UDP 등과 같은 요청의 직렬 (Serialization) 을 보장하는 방법에 따른다. 세션 연결 요청은 요청을 대기하고 있는 세션 관리자 (403) 에 의해 수신되며, 연결 요청 수신시 해당 프로세스를 위한 OCB 블럭을 생성하고 이를 해당 프로세스의 PCB 블럭과 연결한다. 세션 연결 요청이 순서대로 들어와야 하는 이유는 여러 프로세스에서 동시에 세션 연결 요청이 동시에 들어오는 경우, OCB 블럭의 충돌을 방지하기 위함이다.

지금까지는 도 7 내지 도 9 을 통하여 정보 블럭과 공유 메모리의 논리적인 구성, 그리고 세션을 맺는 과정에 대하여 각각 살펴 보았다.

이하 차징 게이트웨이 시스템상에서, GTP' 프로세스에서 ASN.1 Parser 로의 데이터 전달을 도 10 에 도시된 예를 들어 설명한다.

상술한 바대로 공유 메모리 초기화시 해당 프로세스에 대한 CRB 블럭이 이미 설정되고, 각 프로세스는 데이터 통신을 위하여 IX BUS API 의 open() 함수를 호출함으로써 세션을 설정한다. 세션 설정이 이루어 지면, 세션을 위한 PCB, OCB 블럭이 설정된다 (도 10a 참조).

GTP' 프로세스는 GGSN 및 SGSN 으로부터 수집한 CDR 데이터를 디코딩하기 위하여 ASN.1 PARSER 에 전달해야 한다. 이를 위하여 GTP' 프로세스는 IX BUS API 의 write() 함수를 호출한다. write() 함수 내부에서는 OCB 블럭의 스케쥴 토큰을 검사하여, 자신이 사용할 수 있는 경우 메시지를 해당 OCB 의 output queue 에 저장한 후, 스케쥴 토큰에 쓰기 요청을 설정한다. write() 한 후의 공유 메모리 상태를보면 도 10b 와 같고, 그 상세한 과정은 도 11 의 흐름도와 같이 처리된다.

계속해서, 스케쥴러는 OCB 블럭을 루프를 돌면서 반복적으로 검사하며, 요청사항이 있는 경우 처리한다. 위의 예에서는 OCB for GTP' 스케쥴 토큰을 검사하여 쓰기 요청이 설정되어 있으므로 OCB for GTP' 의 output 큐에 설정된 메시지를 목적지 프로세스 (ASN.1 PARSER) 로 input 큐로 메시지를 전달한다. 메시지 전달 후의 공유 메모리 상태를 보면 도 10c 에 도시된 바와 같고, 메시지를 라우팅한 후에 OCB for GTP' 스케쥴 토큰에 서비스 완료를 설정한다. 이를 설정함으로써 GTP' 프로세스는 IX BUS API 를 통하여 다시 메시지를 write() 할 수 있다.

ASN.1 PARSER 는 자신에게 전달된 메시지를 처리하기 위하여 IX BUS API 의 read() 함수를 호출하면, read() 함수는 내부적으로 OCB for ASN.1 PARSER 의 input 큐에 있는 메시지를 읽어서 반환한다. 그리고 IB for Msg(메시지) 를 해제하기 위하여 OCB for ASN.1 PARSER 의 스케쥴 토큰에 읽기 완료 요청을 설정한다. 논리적인 공유 메모리 구성도를 보면 도 10c 에 도시된 바와 같고 그 흐름은 도 12 에 도시된 바와 같다. 읽기 요청이 끝나면 스케쥴러는 스케쥴 토큰에서 읽기 완료 요청을 검색하여 IB for Msg 에 대한 해제를 하여 free IB 리스트에 넣는다. 해제 후 논리적인 공유 메모리 구성도는 도 10a 와 같이 된다.

프로세스가 종료시 IX BUS API의 close()를 호출함으로써 도 13 과 같은 과정을 거쳐 세션을 종료시킨다.

스케쥴러는 해당 OCB 스케쥴 토큰 검사시 종료 요청이 존재하면, 해당 OCB 블럭의 input 큐에 메시지가 존재하는 경우 해당 CRB의 input 큐로 메시지를 전달하며 해당 OCB 블럭을 해제한다.

다음은 상술한 내용을 도 11 내지 도 13 의 흐름도를 통해 읽기, 쓰기 및 종료 과정에 대하여 살펴본다.

도 11 은 IX Bus 에 메시지 전송을 도시하는 순서도이다. 이는 프로세스가 IX Bus API 의 Write ( ) 를 호출함으로써 수행되며, Write ( ) 함수의 내부적으로 다음과 같은 절차를 따른다. 해당 OCB 블럭의 스케쥴 토큰이 스케쥴러 서비스완료 상태인지 확인한다 (801). 완료 상태인 경우에는 스케쥴러 서비스가 완료될 때까지 대기하고, 완료 상태가 아닌 경우에는 전송할 메시지 크기와 OCB 블럭에 할당된 큐 크기를 비교하여 (802), 큐에 공간이 부족한 경우에는 스케쥴 토큰에 자유 블럭 할당 요청을 설정한다 (803). 여기서 완료 상태란 스케쥴러가 그 전에 요청 명령에 따라 이미 작업을 종료하여 새로운 요청을 기다린다는 것을 의미한다.

그 다음 요청이 스케쥴러에 의해 수행되었는지 루프를 돌면서 확인하는 데, 이는 스케쥴 토큰이 스케쥴러 서비스 완료 상태인지 확인함으로써 알 수 있다 (804). 큐의 공간이 부족하지 않는 경우, 즉 공간이 보장되면 OCB 블럭의 출력 큐에 입력된 메시지를 복사한 후 (805), OCB 블럭의 스케쥴 토큰에 쓰기 요청을 설정 (806) 하고 반환한다.

도 12 는 본 발명에 따른 IX Bus 에서 메시지를 읽는 과정을 도시한 순서도이다. 이는 프로세스가 IX Bus API 의 Read () 를 호출함으로써 시작되며, Read( ) 함수는 내부적으로 다음과 같은 과정을 가진다.

프로세스에 할당된 OCB 블럭의 스케쥴 토큰이 스케쥴러 서비스 완료 상태를확인하여 (901), 완료가 아닌 경우에는 OCB 블럭의 입력 큐에 메시지가 존재하는지를 판단한다 (902). 스케쥴 토큰이 스케쥴러 서비스 완료 상태가 되지 않았다는 의미는 해당 프로세스가 어떤 요청을 하였고, 아직 스케쥴러가 이를 처리하지 않았음을 의미한다.

OCB 블럭의 입력 큐에 메시지가 존재하는 경우는 단순히 메시지를 복사하여 반환하고 (909), 스케쥴 토큰에 읽기 완료 요청을 설정한다 (910). 이를 설정함으로써 추후 스케쥴러에 의해 큐잉된 메시지를 해제하게 된다.

그러나 902 단계에서 메시지가 존재하지 않는 경우에는 스케쥴러 토큰에 읽기 요청을 설정하고 (903), 스케쥴러 토큰이 스케쥴러 서비스 완료 상태가 될 때까지 대기한다 (904). 그 다음 요청이 처리된 후 입력 큐에 메시지가 존재 (905) 하면 909 단계로 진행한다. 그러나 입력 큐에 메시지가 존재하지 않으면 입출력 모드를 검사하여 블럭킹 모드인지를 확인하여 (906) 블럭킹 모드가 아닌 경우 곧장 반환하고, 블럭킹 모드인 경우에는 스케쥴러 서비스 완료 상태시까지 대기한다 (907). 그 다음 입력 큐에 메시지가 존재하는 지를 판단하여 (908), 존재하는 경우에는 909 단계로 진행된다.

도 13 는 세션 종료에 대한 과정을 도시하는 순서도이다. 세션의 종료는 프로세스가 IX Bus API 의 Close ( ) 를 호출함으로써 시작되며, Close ( ) 함수 내부적으로는 다음과 같은 흐름을 따른다.

프로세스에 할당된 OCB 블럭의 스케쥴 토큰이 스케쥴러 서비스 완료 상태를 판단하여 (1001), 완료인 경우 스케쥴러 서비스 완료 상태가 될 때까지 루프를 돌면서 대기한다. 스케쥴러 서비스 완료 상태가 아닌 경우에는 해당 OCB 블럭의 스케쥴 토큰에 종료 요청을 설정한다 (1002). 그러면 세션이 종료된다.

다음은 스케쥴러가 프로세스 밍 스케쥴 토큰과 어떤 상호관계를 가지고 작용하는지를 살펴보기로 한다.

도 14 은 스케쥴러의 과정을 도시하는 순서도이다. 기본적으로 스케쥴러는 시스템에 활성화된 OCB 블럭에 대하여 무한 루프를 돌면서 각 프로세스가 요청한 사항을 처리한다 (1101). 프로세스가 요청하는 사항은 쓰기 요청, 읽기 요청, 메시지 읽기 완료 요청, 자유 블럭 할당 요청 및 종료 요청이 존재한다. 스케쥴러는 각 활성화된 OCB 블럭의 스케줄 토큰을 검사한다. 스케줄 토큰이 스케쥴러 서비스 완료 상태, 즉 요청이 없는 상태이면 다음 OCB 블럭을 검사한다 (1102). 쓰기 요청이 설정된 경우 (1103), 메시지를 전달할 목적지 프로세스의 OCB 블럭을 판단한다 (1104). 이때 목적지 OCB 블럭의 입력 큐에 메시지가 존재하면, 해당 OCB 블럭을 가지고 있는 CRB 블럭의 입력 큐에 메시지를 큐잉한다 (1105). OCB 블럭의 입력 큐에 메시지가 존재하지 않으면 해당 목적지 OCB 블럭에 메시지를 큐잉한다 (1106). 이렇게 메시지 큐를 이중화 함으로써, 동일 프로세스의 다중화시 부하 분산을 지원할 수 있으며, 프로세스가 동적으로 생성 및 소멸될 수 있다. 스케쥴 토큰이 읽기 요청 상태인 경우 (1107), 해당 OCB 블럭을 부모 CRB 블럭의 입력 큐에 메시지가 큐잉된 경우 한 개의 메시지를 OCB 블럭의 입력 큐에 큐잉한다 (1108). 스케쥴 토큰이 읽기 완료를 판단하여 (1109), 요청인 경우 OCB 블럭의 입력 큐에 존재하는 프로세스가 읽은 메시지를 해제하여 자유 블럭에 반환한다 (1110). 그 후, 해당OCB 블럭의 부모 CRB 블럭의 입력 큐에 큐잉된 메시지가 존재하는 경우, OCB 블럭의 입력 큐에 큐잉 시킨다 (1111). 스케쥴 토큰이 자유 블럭 할당 요청 상태인 경우 (1112), 자유 IB 블럭 풀에서 요청된 개수의 자유 블럭을 OCB 블럭에 할당해 준다 (1113). 스케쥴 토큰이 종료 요청인 경우 (1114), OCB 블럭의 입력 큐에 메시지가 존재하는 경우 메시지를 해당 CRB 블럭의 입력 큐로 이동 후 OCB 블럭을 해제한다 (1115). 각 요청을 순차적으로 처리 후, 해당 OCB 블럭의 스케쥴 토큰을 스케쥴러 서비스 완료 상태로 설정한다 (1116).

상술한 스케쥴러의 기능을 두 개의 프로세스를 기준으로 도 15 를 참조하여 좀 더 살펴보기로 하자.

프로세스에서 다른 하나의 프로세스로 메시지가 전달될 때에는 메시지간에 서로 충돌이 발생할 수 있고, 어떤 명령을 수행하는 데 있어 그 대상이 없어 충돌이 발생할 수 있다. 이와 같은 에러를 없애는 것이 프로세스간 통신, 특히 빌링 시스템 (billing system) 에 있어서는 필수적이다. 에러가 발생하면 빌링이 이루어지지 않거나 지연되기 때문이다.

메시지 전달시 목적지 OCB 의 input 큐에 메시지가 존재하는 경우 또는 OCB 가 존재하지 않는 경우에는 그 메시지는 우선적으로 CRB input 큐로 전달된다.

그래서 read() 시에 해당 OCB 의 input 큐에 메시지가 존재하지 않는 경우에는 CRB 의 input 큐에 메시지가 존재하면 이 메시지를 읽어서 반환한다. 이러한 구조를 채택함으로써 메시지를 큐잉 할 수 있다. 또한, 동일 프로세스가 여러개 생성된 경우 각 프로세스가 메시지를 read() 시 OCB 의 input 큐에 메시지가 없는 경우에는 CRB의 input 큐에서 메시지를 가져감으로써 효율적인 부하 관리가 가능해 진다.

나아가, 스케쥴러가 데이터를 전달함에 있어, 스케쥴러가 기동하면 라우팅 정보를 읽어서 메모리에 저장한 후 메시지 전달 요청이 왔을 경우 메모리의 라우팅 정보를 트리방식에 의해 검색한 후 검색한 라우팅 정보에 따라 메시지를 전달한다. 즉 메시지가 전달될 대상 프로세스를 찾게 된다.

본 발명에 따른 또 다른 실시예를 도 16 및 도 17을 참조하여 살펴 보도록 한다.

도 16에는 GTP' 프로세스가 1개, ASN.1 Parser 프로세스가 2개, Aggregate 프로세스가 1개, 그리고 Filter 프로세스가 1 개 있고, 도달되는 메시지가 M01 부터 M10 까지 BER(Basic Encoding Rule)에 의해 암호화된 메시지가 10 개가 있고 이중 M04, M05 및 M09 는 Hot Billing 메시지이고 나머지는 보통의 메시지라고 가정하자.

GTP' 프로세스 (301-1) 는 들어온 Data 가 ASN.1 메시지이므로 이에 대한 조건값과 함께 M01 에서 M10 을 IXBUS API (402-1) 를 통해 공유 메모리 (401) 에 쓴다. 스케쥴러 (404) 는 GTP' 프로세스로부터 도달한 메시지의 header 를 검사하여 ASN.1 Parser 프로세스 (302-1) 가 처리할 수 있도록 Class Queue 에 Queuing 한다. 이때 첫 번째 ASN.1 Parser 프로세스 (302-1) 가 메시지를 처리 (M01) 하고 있을 때에는 두 번째 ASN.1 Parser 프로세스 (302-2) 가 해당 메시지 (M02) 를 처리하고, 두 번째 ASN.1 Parser 프로세스 (302-2) 가 메시지를 처리 (M02) 하고 있을경우에는 첫 번째 ASN.1 Parser 프로세스 (302-1) 가 해당 메시지 (M01) 를 처리하고, 두 개의 ASN.1 프로세스 (302-1, 302-2) 가 모두 메시지 처리 (M01, M02) 하고 있어 바쁜 경우에는 공통 Queue 인 ASN.1 Class Queue 에 큐잉한다(M06, M03). 그 다음 먼저 메시지 처리가 끝난 프로세스가 다시 읽기를 할 경우에는 공통 Queue 에서 메시지를 읽어간다.

이때 공유 메모리 (401) 에 대하여 GTP' 프로세스 (301-1), ASN.1 Parser 프로세스 (402-1, 402-2), 스케쥴러 (404) 간에 공유 메모리에 쓰기 및 읽기를 하기 위하여 충돌이 일어나지만 내부의 충돌 회피 알고리즘에 인하여 세마포 또는 뮤텍스 록을 사용하지 않고 이를 해결하며 여러 개의 같은 일을 처리하는 프로세스중에 제일 한가한 프로세스가 도달된 메시지를 처리하는 다중 프로세싱 구조이다.

도 17 을 보면, ASN.1 Parser 프로세스 (302-1, 302-2) 는 처리된 메시지와 이에 대한 조건 결과를 IXBUS API (402-2) 를 통해 공유 메모리 (401) 에 쓰기를 한다. 스케쥴러 (404) 는 ASN.1 Parser 프로세스 (302-1, 302-2) 로부터 도달한 메시지 조건을 검사한다. M01 - M03, M06 - M08 및 M10 은 보통의 메시지이므로 Aggregate 프로세스 (303)의 Class Queue 에 큐잉하고 M04, M05 및 M09 는 Hot Billing 메시지이므로 Filter 프로세스 (305) 의 Class Queue 에 큐잉한다.

각 프로세스에서 처리하는 방법은 도 16 의 설명과 같으며 각각의 메시지에 표시된 조건에 따라 전달되는 목적지가 가변적으로 변경되는 것이 이 시스템의 특징이다.

이상으로 본 발명을 도면을 통해 상세히 알아 보았다.

본 발명은 상술한 바와 같이 차징 게이트웨이 시스템상에서 여러 프로세스를 예로 들어 설명하였지만, 모든 컴퓨터 시스템상의 프로세스간 데이터 전달 또는 제어에 당업자가 적용할 수 있음은 자명하다.

본 발명에 따르면 동적인 다중 프로세스 환경에서 프로세스간 메시지를 라우팅 할 수 있는 범용적인 기능을 제공함으로써 유무선 통신 과금 시스템 등과 같은 대규모의 복잡한 시스템 개발을 용이하게 하는 효과를 제공한다.

또 본 발명에 따르면 프로세스간 데이터 제어에 있어 뮤텍스나 세마포어 등을 사용하지 않고 정보교환 버스내에 하나의 공유 메모리만을 이용하여 데어터 제어 속도를 향상시킬 수 있는 효과를 제공한다.

Claims (10)

1. 정보교환버스를 이용한 프로세스간 통신 데이터 제어 방법에 있어서,

   세션 관리자가 정보교환버스내에 하나의 공유 메모리를 생성하는 단계,

   상기 공유 메모리에 스케쥴러가 연동하는 단계,

   상기 세션 관리자가 해당 프로세스가 생성시 해당 프로세스를 상기 정보교환 버스에 세션을 맺게 하는 단계,

   정보교환 버스 애플리케이션 프로그래밍 인터페이스를 통하여 상기 공유 메모리를 매개체로 상기 프로세스와 상기 스케쥴러가 연동하여 제1프로세스에서 제2프로세스로 필요한 데이터를 전달하는 단계로 구성된 것을 특징으로 하는 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 방법.
2. 제 1 항에 있어서, 상기 공유 메모리는 정보교환 공통 블럭, 클래스 참조 블럭, 프로세스 제어 블럭, 오픈 제어 블럭 및 정보 블럭으로 구성되고, 상기 블럭들중 정보교환 공통 블럭은 상기 프로세스 각각에 대하여 설정되며 나머지 블럭들은 미사용으로 설정되는 것을 특징으로 하는 정보교환버스를 이용한 프로세스간 통신 데이터 제어 방법.
3. 제 1 항에 있어서, 상기 세션을 맺는 단계는 상기 프로세스의 요청 신호를 받아 상기 세션 관리자가 상기 오픈 제어 블럭을 할당하여 상기 프로세스 제어 블럭과 연결시키는 것을 특징으로 하는 정보교환버스를 이용한 프로세스간 통신 데이터 제어 방법.
4. 제 1 항에 있어서, 상기 데이터 전달 단계는 상기 제1프로세스는 자기의 스케쥴 토큰에 쓰기 요청을 하여 상기 스케쥴러가 스케줄 토큰을 검색하여 요청된 쓰기 작업을 하고, 상기 제2프로세스는 자기의 스케쥴 토큰에 읽기 요청을 하면 상기 스케쥴러가 스케쥴 토큰을 검색하여 요청된 읽기 작업을 함으로써 이루어 지는 것을 특징으로 하는 정보교환버스를 이용한 프로세스간 통신 데이터 제어 방법.
5. 제 4 항에 있어서, 상기 스케쥴러가 제1프로세스로부터 전달되는 데이터를 검색하여 제2프로세스가 메시지를 처리하고 있을 때에는 제2프로세스와 동일한 프로세스의 또 다른 프로세스가 처리하도록 하고 제2프로세스와 또 다른 프로세스가 메시지를 처리하고 있을 때에는 클래스 참조 블럭에 메시지를 큐잉하는 것을 특징으로 하는 정보교환버스를 이용한 프로세스간 통신 데이터 제어 방법.
6. 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 시스템에 있어서, 상기 정보교환 버스는 세션 관리자, 스케쥴러, 정보교환버스 애플리케이션 프로그래밍 인터페이스 및 공유 메모리로 구성되어 메모리상에 코딩되며, 상기 세션 관리자가 상기 정보교환 버스내에 하나의 공유 메모리를 생성하는 코드, 상기 공유 메모리에 상기 스케쥴러가 연동하는 코드, 상기 세션 관리자가 해당 프로세스가 생성시해당 프로세스를 상기 정보교환 버스에 세션을 맺게 하는 코드 및 상기 정보교환 버스 애플리케이션 프로그래밍 인터페이스를 통하여 상기 공유 메모리를 매개체로 상기 프로세스와 상기 스케쥴러가 연동하여 제1프로세스에서 제2프로세스로 필요한 데이터를 전달하는 코드로 구성된 것을 특징으로 하는 제1항 내지 제4항 중 어느 한 항을 수행하기 위한 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 시스템.
7. 제 6 항에 있어서, 상기 공유 메로리 코드는 정보교환 공통 블럭, 클래스 참조 블럭, 프로세스 제어 블럭, 오픈 제어 블럭 및 정보 블럭으로 구성된 코드이고, 상기 블럭들 중 정보교환 공통 블럭은 상기 프로세스 각각에 대하여 설정되며 나머지 블럭들은 미사용으로 설정되는 코드인 것을 특징으로 하는 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 시스템.
8. 제 6 항에 있어서, 상기 세션을 맺는 코드는 상기 프로세스의 요청 신호를 받아 상기 세션 관리자가 상기 오픈 제어 블럭을 할당하여 상기 프로세스 제어 블럭과 연결시키는 코드인 것을 특징으로 하는 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 시스템.
9. 제 6 항에 있어서, 상기 데이터 전달 코드는 상기 제1프로세스는 자기의 스케쥴 토큰에 쓰기 요청을 하여 상기 스케쥴러가 스케줄 토큰을 검색하여 요청된 쓰기 작업을 하고, 상기 제2프로세스는 자기의 스케쥴 토큰에 읽기 요청을 하면 상기 스케쥴러가 스케쥴 토큰을 검색하여 요청된 읽기 작업을 함으로써 이루어 지는 코드인 것을 특징으로 하는 정보교환 버스를 이용한 프로세스간 통신 데이터 제어 시스템.
10. 제 9 항에 있어서, 상기 스케쥴러가 제1프로세스로부터 전달되는 데이터를 검색하여 제2프로세스가 메시지를 처리하고 있을 때에는 제2프로세스와 동일한 프로세스의 또 다른 프로세스가 처리하도록 하고 제2프로세스와 또 다른 프로세스가 메시지를 처리하고 있을 때에는 클래스 참조 블럭에 메시지를 큐잉하는 것을 특징으로 하는 정보교환버스를 이용한 프로세스간 통신 데이터 제어 시스템.