KR20030020819A

KR20030020819A - 프로세스간 통신방법 및 장치

Info

Publication number: KR20030020819A
Application number: KR1020020041671A
Authority: KR
Inventors: 윤영현
Original assignee: 삼성전자주식회사
Priority date: 2001-09-04
Filing date: 2002-07-16
Publication date: 2003-03-10
Also published as: KR100442688B1

Abstract

발신지로부터 목적지로 메시지를 전달하기 위한 통신방법에 있어서, 운영체제 독립형 액세스(OIA)계층에 의해서, 통신장치의 운영체제(OS)에 독립적으로 액세스 가능한 운영체제 통합 인터페이스 기능을 제공하는 과정과, 디바이스 독립형 액세스(DIA)계층에 의해서, 상기 통신장치의 피지컬 디바이스에 독립적으로 액세스 가능한 디바이스 통합 인터페이스 기능을 제공하는 과정과, 통합 프로세스간 통신(UIPC)계층에 의해서, 상기 발신지 타스크에 의해 제공되는 목적지 정보와 타스크의 기본적인 공통 제어 흐름을 가지는 공통타스크 아키텍처를 이용하여 상기 발신지로부터의 메시지를 상기 운영체제 독립형 액세스 계층 및 상기 디바이스 독립형 액세스 계층중 적어도 하나를 통해 상기 목적지로 전송하는 하는 과정으로 이루어진다.

Description

프로세스간 통신방법 및 장치{INTERPROCESS COMMUNICATION METHOD AND APPARATUS}

본 발명은 프로세스간 통신(InterProcess Communication: 이하 "IPC"라 칭함)을 수행하는 통신 시스템에 관한 것으로, 특히 통신 피지컬 디바이스(physical devices)와 운용체제(operating sys)에 종속되지 않는 통합형 프로세스 통신(Unified InterProcess Communication: 이하 "UIPC"라 칭함) 방법 및 장치에 관한 것이다.

프로세스간 메시지 통신을 하는 IPC는 파이프(pipe), 세마포어(semaphore), 메시지 큐(message queue), 공유 메모리(shared memory) 등 다양한 방법이 있으며, 모두는 운영체제(operating system)에 기반 되어 있다. 따라서 IPC 방법은 기반으로 하고 있는 운영체제에 따르는 다양한 형태로 제공되었다. 즉 IPC 방법은 운영체제에 의존적(dependent)이었다. 결과적으로 IPC 및 프로세스 구현시 통신 시스템에 사용되는 그 운용체제에 따라 어플리케이션 소프트웨어(application software)가 변경되어야 했다. 또한 하드웨어장치간 프로세스 통신의 경우에는 제공되는 피지컬 디바이스(physical devices)에 따라 디바이스 드라이버(physical devices driver)가 상이하므로, 디바이스 드라이버를 사용해야 하는 프로세스는 그 사용하는 디바이스 드라이버에 따라 IPC 기능을 변경해야만 했다.

상기와 같은 통신시스템에서의 IPC 방법은 운영체제와 피지컬 디바이스에 의존적이었다. 결과적으로 통신 시스템에 사용되는 운영체제 및 피지컬 디바이스의 변경에 따른 부가적이고 반복적인 오버헤드(overhead)를 야기 시키며, 이는 통신시스템의 개발 시간과 비용에 적지 않은 부담을 초래하였다. 또한 소프트웨어의 재사용성(reusability)과 이식성(portability)을 떨어뜨렸다.

따라서 본 발명의 목적은 통신시스템이 채택하는 운영체제와 피지컬 디바이스 종류에 의존적이지 않는 유연하고 통합된 프로세스 통신 방법 및 장치를 제공하는데 있다.

본 발명의 다른 목적은 통신 시스템에 사용되는 운영체제에는 상관없으며 소프웨어의 재사용성 및 이식성이 뛰어난 프로세스 통신을 수행하는 통합형 프로세스 통신 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 통신 시스템에 사용되는 피지컬 디바이스(physical devices)에는 상관없이 프로세스 통신을 수행하는 통합형 프로세스 통신 방법 및 장치를 제공하는데 있다.

본 발명의 또 다른 목적은 통신장치에 의해서 어떤 통신방법들(예를 들면, ATM, IP, SDH 등)이 사용되는지에 상관없이 발신지에서 착신지로 메시지를 전달하기 위한 통신장치를 제공함에 있다.

상기한 목적에 따라, 본 발명은, 발신지로부터 목적지로 메시지를 전달하기 위한 통신방법에 있어서, 운영체제 독립형 액세스(OIA)계층에 의해서, 통신장치의 운영체제(OS)에 독립적으로 액세스 가능한 운영체제 통합 인터페이스 기능을 제공하는 과정과, 디바이스 독립형 액세스(DIA)계층에 의해서, 상기 통신장치의 피지컬디바이스에 독립적으로 액세스 가능한 디바이스 통합 인터페이스 기능을 제공하는 과정과, 통합 프로세스간 통신(UIPC)계층에 의해서, 상기 발신지 타스크에 의해 제공되는 목적지 정보와 타스크의 기본적인 공통 제어 흐름을 가지는 공통타스크 아키텍처를 이용하여 상기 발신지로부터의 메시지를 상기 운영체제 독립형 액세스 계층 및 상기 디바이스 독립형 액세스 계층중 적어도 하나를 통해 상기 목적지로 전송하는 하는 과정으로 이루어짐을 특징으로 한다.

또한 본 발명은, 발신지로부터 목적지로 메시지를 전달하기 위한 통신 장치에 있어서, 통신장치의 운영체제에 독립적으로 액세스 가능한 운영체제 통합 인터페이스 기능을 제공하는 운영체제 독립형 액세스(OIA)계층부와, 상기 통신장치의 피지컬 디바이스에 독립적으로 액세스 가능한 디바이스 통합 인터페이스 기능을 제공하는 디바이스 독립형 액세스(DIA)계층부와, 상기 발신지 타스크에 의해 제공되는 목적지 정보와 타스크의 기본적인 공통 제어 흐름을 가지는 공통타스크 아키텍처를 이용하여 상기 발신지로부터의 메시지를 상기 운영체제 독립형 액세스 계층 및 상기 디바이스 독립형 액세스 계층중 적어도 하나를 통해 상기 목적지로 전송하는 통합 프로세스간 통신(UIPC)계층부로 구성함을 특징으로 한다.

본 발명의 실시 예에서는 "프로세스", "어플리케이션", "타스크"라는 용어가 혼재되어 사용될 것인데, 이들은 본 발명에서 구현된 UIPC의 상위에 존재하는 타스크를 의미함을 이해하여야 한다.

도 1은 본 발명의 실시 예에 따른 메시지 교환을 위한 각 셀프들간의 회로망 구성도,

도 2는 본 발명의 실시 예에 따른 UIPC기능이 적용된 통신 시스템의 구체적인 구성 일 예도,

도 3은 본 발명의 실시 예에 따른 UIPC를 일부 구성요소로서 가지고 있는 공통 소프트웨어 플랫폼(common software platform)의 블록 구성도,

도 4는 본 발명의 실시 예에 따른 카드별(유니트별) UIPC 구성을 보여주는 도면,

도 5는 공통 타스크 아키텍쳐의 구조를 사용하는 프로세스 즉 타스크의 기본적인 공통 제어 흐름도,

도 6은 본 발명의 실시 예에 따른 UIPC API 구성 및 공통 타스크 아키텍쳐를 설명하기 위한 도면.

이하 본 발명의 바람직한 실시 예들을 첨부한 도면을 참조하여 상세히 설명한다. 도면들 중 동일한 구성요소들은 가능한 한 어느 곳에서든지 동일한 부호들로 나타내고 있음에 유의해야 한다. 또한 본 발명의 요지를 불필요하게 흐릴 수 있는 공지 기능 및 구성에 대한 상세한 설명은 생략한다.

그리고 하기의 외국문헌들은 본 발명의 개념을 이해하기 위한 배경설명 및 부가적인 정보를 제공한다:

- Open Systems Interconnection, Basic Reference Model, ITU-T X. 200

- Open Systems Interconnection, Data Link Service Definition, ITU-T X. 212;

- Open Systems Interconnection, Network Service Definition, ITU-T X. 213;

- Open Systems Interconnection, Transport Service Definition, ITU-T X. 214;

도 1은 본 발명의 실시 예에 따른 메시지 교환을 위한 각 셀프들간의 회로망 구성도이다. 도 1의 회로망 토폴로지(topology)는, 구성요소 관리 시스템(Element Management System: EMS)(8), 카드(12)를 포함하는 복수개의 카드들을 구비하고 있는 시스템 제어기 셀프(10), 스마트 디바이스(smart device)(6)들 및 카드(22a)를 포함하는 복수개의 카드들을 구비하고 있는 확장셀프1(20a), 카드(22b)를 포함하는 복수개의 카드들을 구비하고 있는 확장셀프2(20b), 및 카드(22c)를 포함하는 복수개의 카드들을 구비하고 있는 확장쉘프3 (20c)을 포함하고 있다.

도 1을 참조하면, 확장셀프3(20c)이 시스템 제어기 셀프(10)와 통신하기 위해서는, 상기 확장셀프3(20c)과 시스템 제어기 셀프(10) 사이의 통신이 물리적으로 확장쉘프2(20b)를 통과한다 할지라도 본 발명의 실시 예에 따라 구성되는 확장셀프3(20c)과 시스템 제어기 셀프(10) 사이에는 가상적인 직접통로가 존재한다.

도 1은 본 발명의 UIPC기능이 적용되는 네트워크 망 구조를 설명하기 위해 도시한 것이다. 본 발명의 실시 예에 따른 UIPC는, 도 2가 참조되어 보다 구체적으로 후술될 것이지만, 미리 개략적으로 설명하면 각각의 카드들내 타스크 간의, 동일한 셀프내의 서로 다른 카드들 상의 타스크 간의, 그리고 어떠한 셀프 및 부착된 스마트 디바이스(6)들(예컨대, 디지털 가입자 라인 모뎀 및 통합된 액세스 장치들)내의 타스크들 간의 메시지 교환을 지원한다. 필요하다면, 두 개의 셀프들 사이에 전달될 필요가 있는 메시지들이 시스템 제어기 셀프(10)를 통해 그의 경로가 정해진다고 가정한 것임을 유의하여야 한다. 이것은 프로토콜을 단순화하고, 더 일반화되어 있는 네트워크 토폴로지를 다루는 인터넷 프로토콜(IP)과 같은 프로토콜과 연관된 오버헤드를 감소시킨다. 구성요소 관리 시스템(8)도 UIPC를 경유해 통신한다는 점을 인식해야한다. 메시지들은 상기 구성요소 관리 시스템(8)과 어떠한 셀프내의 어떤 카드간의 경로로 보내질 수 있다. 하나의 구성요소관리시스템(8)은 UIPC에 관한 한 어떤 다른 셀프와 유사하게 보일 수 있다.

도 2는 본 발명의 실시 예에 따른 UIPC기능이 적용된 통신 시스템의 구체적인 구성 일 예도이다.

도 2에 도시된 확장셀프(20i)는 도 1에 도시된 복수개의 확장셀프(extending shelf)들(20a,b,c)중 하나이고, 시스템 제어기 셀프(10)는 복수개의 확장 셀프들(20a,b,c)을 제어하는 셀프이다. 셀프들(10,20i) 각각에는, 복수개의 제어 카드들(14,16, 24,26)과, 상기 복수개의 제어 카드들(14,16, 24,26)을 제어하기 위한 하나의 메인 제어카드(main control card)(12,22)가 구비되어 있다. 상기 제어카드들(14,16, 24,26) 각각 및 메인 제어카드(12,22)에는 프로세스간 메시지 통신을 하기 위한 UIPC(30)가 공통 소프트웨어 플랫폼(common software platform)(32)의 일부 구성요소로서 제공된다. UIPC(30)는 카드내, 카드간, 셀프내, 셀프간의 프로세스들 간의 메시지통신을 위한 경로를 제공하는 수단이 된다. 각 UIPC(30)에는 도 2에 도시된 예컨대 P1,P2와 같은 프로세스들(어플리케이션 타스크들)이 연결된다.

UIPC(30)는 도 2에서와 같이 "카드내 프로세스 통신(내부프로세스통신)", "셀프내 카드간 프로세스 통신(외부프로세스통신)", "셀프간 프로세스 통신(외부프로세스통신)"의 세 가지 형태로 제공된다. "셀프내 카드간 프로세스 통신"과 "셀프간 프로세스 통신"의 경우는 별도의 디바이스 드라이버(physical device driver)가 요구된다.

도 3은 본 발명의 실시 예에 따른 UIPC(30)를 일부 구성요소로서 가지고 있는 공통 소프트웨어 플랫폼(common software platform)(32)의 블록 구성도이다.

도 3에 도시된 공통 소프트웨어 플랫폼(32)은 다수의 서로 상이한 통신시스템에 공통적으로 응용할 수 있도록 하기 위해 일반적이며 공통적인 기능을 제공하는 소프트웨어이다. 상기 공통 소프트웨어 플랫폼(32)은 도 2에 도시된 일 예의 셀프(10,20)내 각 카드(12,14,16, 22,24,26)내에 존재하며 다수의 기능 단위로 그 구성성분들이 구분되어 있다.

상기 공통 소프트웨어 플랫폼(32)은 도 3에 도시된 바와 같이, 크게 수평방향으로 배열된 구성성분(이하 "수평 구성성분"이라 칭함)과 수직방향으로 배열된 구성성분(이하 "수직 구성성분"이라 칭함)으로 구분된다. 수평 구성성분들 예컨대, 공통 에이전트(common agent)(40), 공통 OAM(common Operation, Administration and Maintenance)(42), UIPC(Unified InterProcess Communication)(30), DIA계층(Device Independent Access layer)(46), 디바이스 드라이버(physical device drivers)(48), RTOS(Real Time Operating System)(50), 하드웨어(52)는 모든 통신시스템에서 요구되는 공통의 기능블록으로서, 수직 구성성분에 의해서 특정 기술적인 기능들이 제공된다. 수직 구성성분들 예컨대, ATM(Asynchronous Transfer Mode)(56), SDH(synchronous digital hierarchy)+PDH(Plesiochronous Digital Hierarchy)(58), VoP(Voice over Packet)(160)는 통신시스템에 따라 요구되는 기술적인 기능 블록으로서, 수평 구성성분에 대해 기술적인 기능들이 제공되며 통신시스템에 따라 변경되는 요소이다. 예를 들어, 수평 구성성분들중 하나인 공통 OAM(42)은 통신시스템의 유지 보수를 위해 경보 및 성능 데이터를 수집, 관리하는데 ATM 관련 통신 시스템을 위해 ATM 관련 알람(alarm), 성능(performance) 데이터는 ATM(56)이라는 수직 구성성분(vertical components)에 의해서 제공된다. 도 2에서, 빗금친 기능블록들(50,162,164,166,168,170)은 상용 소프트웨어(commercialsoftware)가 사용 또는 추가될 수 있는 경우의 기능블록이다.

도 3에서 "공통 에이전트(40)"에서부터 "공통 OAM(42)"까지의 상부 블록은 소프트웨어의 어플리케이션에 의존한다.

다양한 통신 시스템들은 도 3에 도시된 바와 같은 공통 소프트웨어 플랫폼(32)을 포함하게 되며, 또한 통신 시스템에서 구현하고자 하는 모든 어플리케이션들은 상기 공통 소프트웨어 플랫폼(32)에 의해서 제공되는 수평 구성성분들과 수직 구성성분들의 조합 기능으로 개발될 것이다.

도 3에 도시된 공통 소프트웨어 플랫폼(32)의 수평 구성성분들의 기능에 대해 보다 상세히 설명하면 하기와 같다.

1. 운영체제 독립형 액세스 계층(Operating System Independent Access Layer; OIA계층)(54)

- 어플리케이션 및 UIPC(30)를 구현하는데 있어 RTOS(50)와 같은 운영체제(OS)에 의존적이지 않고 독립적으로 OS액세스할 수 있도록 OS통합 인터페이스 기능을 제공하여, 어플리케이션 및 UIPC(30)의 이식성(portability)을 향상시킨다. 즉 통신시스템의 운영체제가 바뀌어도 소프트웨어 어플리케이션 및 UIPC(30)는 변경 없이 재사용 가능하게 된다.

2. 디바이스 독립형 액세스 계층(Device Independent Access Layer; DIA계층)(46)

- 디바이스 드라이버(physical Device Driver)(48)의 구체적인 부분을 은폐(hiding)시킴으로써 다양한 디바이스(Device)에 대한 공통의 모델 즉, 디바이스에 의존적이지 않고 독립적으로 디바이스 액세스할 수 있도록 디바이스 통합 인터페이스 기능을 제공한다. 그에 따라 도 3의 하드웨어(52)와 같은 하드웨어 칩들(hardware chips)이 바뀌어도 어플리케이션 및 UIPC(30)/OIA계층(54)은 DIA계층(46)에 의해서 변경 없이 재사용 가능하게 된다.

3. 통합형 프로세스간 통신(Unified Interprocess Communication; UIPC)(30)

- 프로세스 통신을 위해 운영체제에 따른 IPC 메카니즘 및 RTOS(50)와 같은 하위 소프트웨어 및 하위 하드웨어(52)에 대한 구체적인 정보를 은폐시킴으로써 어플리케이션 구현에 있어 운영체제 변경에 따른 별도의 작업이 필요치 않다.

4. 공통 관리 및 유지 보수(Common Operation, Administration & Maintenance; 공통 OAM)(42)

- 다양한 통신시스템의 운용 유지 보수를 위한 공통의 방법을 제공한다.

5. 공통 에이전트 소프트웨어(Common Agent Software)(40)

- 통신시스템의 망 관리를 위해 외부 망 관리시스템과의 인터페이스를 제공한다.

상기에서와 같이 다양한 통신시스템을 구현하는데 있어 특정 기능의 구현에 얽매이지 않고 공통적인 기능들을 제공함으로써 다양한 통신시스템에 재사용이 가능하고 운영체제 및 하드웨어 디바이스 의존적이지 않는 소프트웨어 아키텍쳐(software architecture)를 구현하는 것이 공통 소프트웨어 플랫폼(32)의 존재 목적이다. 상기 공통 소프트웨어 플랫폼(32)의 구성성분중 일부로서 프로세스 메시지 통신방법을 구현한 것이 UIPC(30)이다.

이제까지 본 발명의 보다 전반적인 이해를 돕기 위해 공통 소프트웨어 플랫폼(32)에 대해 서술하였고, 지금부터 UIPC(30)의 구성 및 기능이 첨부 도면들과 함께 상세히 설명될 것이다.

UIPC(30)는 도 2에서와 같이 모든 제어 유니트(control unit) 즉 제어 카드들(12,14,16, 22,24,26) 각각에서 수행되는 요소로서 동일 카드 및 동일 셀프 또는 다른 셀프내의 프로세스간에 메시지 통신기능을 제공한다.

본 발명의 실시 예에 따른 UIPC(30)를 통한 메시지 통신을 위해서, 어플리케이션ID(application identifier) APP_ID와 네트워크 어드레스(network address) N_ADDR이 요구된다. 상기 어플리케이션ID APP_ID는 통신하고자 하는 해당 프로세스를 구분해 주기 위한 ID이며, 상기 네트워크 어드레스 N_ADDR은 해당 프로세스의 물리적 위치를 나타내는 주소 값이다. 상기 네트워크 어드레스 N_ADDR은 그 사이즈가 4-옥텟(octets)이며, 랙-셀프-슬롯-포트(Rack-Shelf-Slot-Port)의 정보로 구성된다. 그러므로 네트워크 어드레스 N_ADDR을 이용하면 해당 프로세스의 물리적인 위치를 찾아 낼 수 있게 된다. 네트워크 어드레스 N_ADDR은 상기 UIPC(30)를 위해서는 셀프와 슬롯(카드가 실장 되는 위치) ID만을 사용하며, 랙(rack)과 포트 ID는 다른 용도로서 사용한다. 도 2에서 시스템 제어기 셀프(10)의 메인 제어 카드(12)내 프로세스 P1에서 확장 셀프(20i)의 메인 제어카드(22)내 프로세스 P1로 메시지를 송신하는 경우를 살펴보도록 하자. 우선 시스템 제어기 셀프(10)의 ID를 "1", 확장 셀프(20)의 ID를 "2", 메인 제어카드(12,22)의 슬롯ID를 "2"로 가정한다. 먼저 발신지 및 목적지 어플리케이션ID APP_ID는 각각 P1이다. 그리고 발신지 네트워크 어드레스 N_ADDR은 16진수(hexadecimal)로 "0x00010200"(랙-셀프-슬롯-포트)이 되고 목적지 네트워크 어드레스 N_ADDR은 16진수(hexadecimal)로 "0x00020200"(랙-셀프-슬롯-포트)이 된다. 상기 네트워크 어드레스 N_ADDR과 어플리케이션ID APP_ID를 인터넷 프로토콜(internet protocol: IP)에 대응시켜 비교했을 때, 네트워크 어드레스 N_ADDR은 IP어드레스에, 어플리케이션ID APP_ID는 TCP(Transmission Control Protocol)의 포트번호에 유사하게 대응시킬 수 있다.

본 발명의 실시 예에 따른 UIPC(30)가 제공하는 기능은 하기와 같다.

-UIPC(30)는 네트워크 구성요소에 있는 어느 곳에서나 타스크들간의 쌍방향 메시지 전달을 제공한다.

- UIPC(30)는 어플리케이션이 비동기적으로 메시지들을 전송하는 것을 허락한다. API(Application Program Interface)는 블로킹 없이 즉각적인 응답을 준다.

- UIPC(30)는 타스크들이 메시지들을 전송하며 타임아웃을 가지고 동기적으로 응답함을 허락한다.

- UIPC(30)는 하위의 물리적 전달 메카니즘(underlying physical transport mechanism)을 추출해 낸다.

- UIPC(30)는 메시지들이 브로드캐스트(broadcast)될 수 있는 메카니즘을 제공한다.

- 하위레벨 UIPC 프로토콜은 상위계층 프로토콜의 변경 없이도 변경될 수 있게 하며, 그 반대로도 될 수 있게 한다.

- UIPC(30)는 링크 대 링크 기반상에서의 전송 에러를 검출하고 에러된 패킷들에 대한 재시도를 수행한다. 이것은 각 링크를 핸들링 하는 프로토콜의 데이터 링크계층이 링크를 신뢰성 있게 만들어야 함을 의미한다.

- 동일 UIPC API는 내부프로세스통신과 외부프로세스통신을 위해 사용된다.

- 동일 UIPC(30)는 대용량 메시지들의 분할과 재조립을 수행한다.

- UIPC(30)는 디버그 출력(debug output)을 인에이블 시키는 메카니즘을 제공한다.

- UIPC 프로토콜 파라미터는 동작수행시간(run-time)에서도 세팅 가능하다.

- UIPC(30)는 각 링크에 대해서 최대 전송단위를 설정하는 메카니즘을 제공한다.

- UIPC(30)는 가변적인 최대 전송단위들을 가지는 링크를 수용한다.

- UIPC(30)는 실시간 중요 메시지들(real-time critical messages)에 대한 메시지 우선순위를 지원한다.

- UIPC(30)는 OS(operating system) 독립적이다.

- UIPC(30)는 제어기로부터의 메시지가 투명하게 통과되어 카드에 부착된 디바이스들에게 가도록 한다.

UIPC(30)는 메시지를 발신지에서 목적지로 전달하는 역할을 갖고 있으나 메시지의 내용에 대해서는 어플리케이션의 역할이기 때문에 특정 시스템 메시지의 표현 메카니즘을 제공하지는 않는다. 상기 시스템 메시지의 표현 메카니즘은 표현계층(presentation layer)의 역할인데, 본 발명의 실시 예에 따른 UIPC(30)에서는 실시간 프로토콜을 지향하므로 상기 표현계층을 포함하지 않는 것이다.

도 4는 본 발명의 실시 예에 따른 카드별(유니트별) UIPC 구성을 보여주는 도면이다. 도 4에서 타스크(task)는 프로세스와 동일한 개념으로 간주함을 이해하여야 한다.

도 4를 참조하면, 각 카드(유니트)에 구비된 본 발명의 실시 예에 따른 UIPC(30)는, 크게 UIPC API(Application Program Interface)(60)와 UIPC 프로토콜 스택(protocol stack)(70)의 두 부분으로 구분된다. 그 이유는 UIPC 프로토콜 스택(70)을 필요로 하는 외부프로세스통신(interprocessor communication)과 UIPC 프로토콜 스택(70)을 필요로 하지 않는 내부프로세스통신(intraprocessor communication)을 효율적으로 구분하기 위함이다. 외부프로세스통신(interprocessor communication)은 네트워크 어드레스 N_ADDR이 자기 자신이 아니기 때문에 메시지가 자기 카드에서 다른 카드로 전달되어야 하는 경우이고, 내부프로세스 통신(intraprocessor communication)은 네트워크 어드레스 N_ADDR이 자기 자신이기 때문에 카드 내부의 해당 타스크로 메시지가 직접 전달될 수 있는 경우이다. UIPC API(Application Program Interface)(60)는 타스크로부터 호출되는 라이브러리 형태로 제공된다. 타스크는 메시지를 송수신하기 위해 UIPC API(60)를 호출하며 외부프로세스통신을 위해서는 UIPC 프로토콜 스택(70)과 통신하며 메시지를 처리한다.

먼저 본 발명의 실시 예에 따른 UIPC API(60)에 대하여 도 4를 참조하여 보다 상세히 설명하면 하기와 같다.

UIPC API(60)

UIPC API(60)는 어떤 타스크(프로세스)에서도 이용될 수 있는 공유형 라이브러리이며, UIPC(30)에서 제공되는 모든 외부 기능에 대한 인터페이스를 제공한다. 요컨대, UIPC API(60)는 어떠한 어플리케이션 타스크가 UIPC 기능을 사용할 수 있도록 인터페이스를 제공한다. 또한 네트워크 어드레스 N_ADDR 및 어플리케이션ID APP_ID에 근거하여 외부 및 내부 프로세스통신 경로를 결정한다. UIPC API(60)는 내부프로세스통신(intraprocessor communication)을 위해서는 UIPC 프로토콜 스택(70)을 사용하지 않는다. UIPC API(60)는 해당 어플리케이션 타스크(프로세스)의 물리적 위치를 나타내는 네트워크 어드레스 N_ADDR을 조사하여, 만약 내부프로세스통신(intraprocessor communication)일 경우에는 도 3의 OIA계층(54)에서 제공하는 OIA API 라이브러리를 통해 직접 해당 타스크(프로세스)의 메시지 큐(queue)로 메시지를 전달한다. 만약 외부프로세스통신(interprocessor communication)일 경우에는 UIPC API(60)는 목적지를 찾는 라우팅을 위해 UIPC 프로토콜 스택(70)의 메시지 큐로 메시지를 전달한다.

UIPC API(60)가 타스크(어플리케이션)에게 제공하는 외부 기능중 가장 중요한 것이 타스크가 UIPC를 사용할 수 있도록 하기 위한 공통 소프트웨어 플랫폼(32)의 공통 타스크 아키텍쳐(common task architecture)를 제공하는 것이다. 본 발명의 실시 예에 따른 공통 타스크 아키텍쳐(common task architecture)의 대표적인 기능은 다음과 같다.

1. 개발자들은 타스크 구조(task structure)를 재설계(redesign)할 필요가없다.

2. 비동기 콜백(asynchronous callback) 기능이 발신자(caller)의 타스크에서 수행된다.

3. 개발자들이 공통 구성성분(common components)(예컨대, 공통OAM 등)과 어플리케이션을 합치기(integrate) 위한 작업이 필요 없다.

4. 메시지 큐 방식을 사용하여 타스크간 통신을 한다. 이는 모든 운영체제가 제공하는 공통의 IPC 메카니즘이기 때문이다.

공통 소프트웨어 플랫폼(32)의 모든 구성성분(수평 구성성분 + 수직 구성성분)들중 UIPC계층(30)의 상위 블록의 소프트웨어 어플리케이션 예컨대, 공통 에이전트 타스크(40), 공통 OAM 타스크(42) 등은 UIPC API(60)가 제공하는 본 발명의 실시 예에 따른 공통 타스크 아키텍쳐가 사용되어 구현된다. 상기 4가지 기능의 공통 타스크 아키텍쳐의 구조를 사용하는 타스크(프로세스)의 기본적인 공통 제어 흐름은 도 5와 같다.

도 5를 참조하면, 타스크는 큐를 이용해 메시지 수신을 기다린다. 타스크는 비동기적(Asychronous)으로 메시지를 수신하면(100단계), 수신된 메시지를 디코드하여 분석 후(102단계), 메시지 처리를 수행한다(104단계). 만약 타스크 별도의 처리가 요구되면 기타 특정한 해당 기능을 수행(other application specific processing)한 후(106단계), 다시 100단계로 되돌아가 메시지 수신을 기다린다.

종래의 레가시(legacy) 타스크 아키텍쳐와 본 발명의 실시 예에 따라 도 5와 같은 기본적인 공통 제어 흐름을 갖는 타스크의 공통 타스크 아키텍쳐를 하기 표 1및 표 2의 테이블에서 비교하였다. 표 1의 테이블에 기재된 일 예와 같은 종래의 레가시 타스크는 공통의 구조가 아니기 때문에 개발자 및 타스크 기능에 따라 상이한 형태로 개별 설계가 된다. 이는 개발시간에 상당한 오버헤드이었고 유사기능을 가진 타스크일 경우라도 재설계 되어야 했다. 한편 하기 표 2의 테이블에 기재된 바와 같은 본 발명의 실시 예에 따른 공통 타스크 아키텍쳐는 도 5와 같은 타스크의 기본적인 공통 제어 흐름을 가지도록 구현되어 종래의 오버헤드를 제거한다. 그래서 개발시간 단축에 상당한 효과가 있다.

표 2에 도시된 공통 타스크 아키텍쳐에 대해서는 도 6이 참조되어 상세히 설명될 것이다.

도 6은 본 발명의 실시 예에 따른 UIPC API 구성 및 공통 타스크 아키텍쳐를 설명하기 위한 도면이다. 도 6을 참조하면, 각 카드의 메인 타스크는 UIPC 내부에 하기 표 3과 같은 글로벌 정보 테이블을 생성하며, 고유의 기능(예컨대, 알람 타스크 , 성능 타스크 등)을 하는 서브 타스크 task1,task2를 생성한다.

타스크ID	어플리케이션 ID	타스크의 동적 메시지 핸들러 테이블에 대한 포인터	타스크의 정적 메시지 핸들러 테이블에 대한 포인터	타스크의 동적 메시지 클래스 테이블에 대한 포인터	타스크의 아이들 메시지 핸들러에 대한 포인터	Uipc_RcvLoop()내에 사용된 대기시간

<<UIPC 글로벌 정보 테이블>>

UIPC 내부에 있는 UIPC 글로벌 정보 테이블에 대해서 보다 상세히 설명하면 하기와 같다. 상기 글로벌 정보 테이블은 특정한 카드에서의 모든 타스크들에 대한 정보를 포함한다. 글로벌 정보 테이블에서의 각 엔트리는 타스크 제어블록(Task Control Block: TCB)이다. 각각의 타스크 제어블록은 타스크가 일정하게 지정된 정보를 보유할 것이다.

상기 타스크 제어블록의 제1필드는 '타스크ID'이다. 상기 타스크 제어블록의 제2필드는 '어플리케이션 ID'이다. 이것은 타스크의 '메인 큐(Main Queue)'의 '어플리케이션 ID'일 것이다.

각 타스크는 동적 메시지 핸들러 테이블(dynamic message handler table), 정적 메시지 핸들러 테이블, 및 동적 메시지 클래스 테이블을 보유할 것이다. 타스크가 Uipc_RegisterOneTimeApi()을 일으킬 때마다 언제나 타스크의 동적 메시지 핸들러 테이블에서 엔트리가 만들어진다. 이러한 동적 메시지 핸들러 테이블에서의 엔트리는 영구적인 것이 아니다. 상기 엔트리는 한 번의 API의 응답이 도달하자마자 삭제된다. 상기 동적 메시지 핸들러 테이블은 밸런스드 바이너리 트리(balancedbinary tree)들을 사용하여 구현될 수 있다. 타스크가 Uipc_RegisterMsgHandler()를 일으킬 때마다 정적 메시지 핸들러 테이블에서 엔트리가 이루어질 것이다. 상기 정적 메시지 핸들러 테이블은 감시자의 API에 대해 전용이다. 동적 메시지 핸들러 테이블과는 달리, 정적 메시지 핸들러 테이블에 있어서의 엔트리는 영구적일 것이다. 정적 메시지 핸들러 테이블은 어레이(array)들을 사용하여 구현될 것이다.

타스크가 Uipc_GenerateTempMsgClass()를 유발할 때마다 메시지 클래스는 상기 타스크로 다시 복귀할 것이며, 그리고 동적 메시지 클래스 테이블에서 필요한 업데이팅(updating)이 이루어져 특정한 메시지 클래스가 사용중(busy)일 것이다. 상기 타스크가 Uipc_FreeTempMsgClass()를 일으킬 때마다 상기 UIPC는 특정한 메시지 클래스가 장차 사용될 수 있도록 상기 동적 메시지 클래스 테이블에서 필요한 변경을 수행할 것이다. 상기 동적 메시지 클래스 테이블은 또한 하나의 어레이로서 구현될 것이다.

상기한 글로벌 정보 테이블은 모든 상기한 테이블들에 대한 포인터들을 포함한다. 이에 더하여, 상기 글로벌 정보 테이블은 타스크의 '아이들 메시지 핸들러(Idle Message Handler)' 함수에 대한 포인터를 또한 포함한다. 상기 글로벌 정보 테이블은 각 타스크에 대하여 Uipc_RcvLoop() 내에서 사용되어야만 하는 대기시간을 포함할 것이다. 상기 Uipc_RcvLoop API내에서 매번 상기 글로벌 정보 테이블은 대기시간에 대해 질문될 것이다. 상기 글로벌 정보 테이블은 모든 타스크들에 의해 액세스될 것이기 때문에 소정의 세마포어(semaphore) 신호가 상기 글로벌 정보 테이블을 보호할 것이다. 이러한 세마포어 신호는 Uipc_InitCardCentext() 동안에 생성될 것이다.

다시 도 6을 참조하면, UIPC API에서, Uipc_InitCardContext()는 본 발명의 실시 예에 따라 UIPC(30)를 초기화하도록 요청된다. 메인 타스크에 의해서 수행된 Uipc_InitCardContext()는 UIPC(30)를 사용하기 위해 UIPC 사용할 메모리 할당 및 내부 데이터 구조체(data structure)를 생성한다. Uipc_InitCardContext()는 카드(유니트)마다 한번만 호출되어야 한다.

상기 메인 타스크의 의해서 생성된 종속 타스크들 task1,task2의 공통 타스크 아키텍쳐에 대해서 보다 상세히 설명하면 하기와 같다.

공통 타스크 아키텍쳐에서, Uipc_InitTaskContext()는 여러 타스크들이 UIPC(30)를 사용해 통신할 수 있도록 각 타스크 생성시마다 글로벌 정보 테이블을 할당하여 글로벌 테이블 엔트리에 등록해준다. Uipc_InitTaskContext()는 타스크마다 한번만 호출되어야 한다.

Uipc_CreateQueue(TASK1_APP_ID,&hTask1Queue)는 각 타스크에서 UIPC를 사용해 메시지를 수신하기 위해 큐를 생성한다. Uipc_CreateQueue(TASK1_APP_ID,&hTask1Queue)는 타스크의 어플리케이션ID에 대한 큐 테이블에 생성된 큐ID를 등록한다.

Uipc_SetmainQueue(hTask1Queue)는 타스크에서 해당 큐를 메시지 수신을 위한 메인 큐로서 등록한다. 메인 큐로 등록되면 Uipc_RcvLoop() 내부에서 메시지 대기(wait)를 위한 큐로서 사용된다.

Uipc_RegisterMsgHandler(TASK1_MSG_CLASS,&Task1MessageHandler)는 타스크에서 수신된 메시지 처리할 메시지 종류(메시지 클래스)와 메시지 처리를 위한 핸들러 함수를 글로벌 정보 테이블에 등록하여 Uipc_RcvLoop()내부에서 수신된 메시지를 처리할 때 사용한다.

Uipc_RegisterIdleHandler(&Task1IdleHandler)는 타스크가 수신된 메시지 처리 기능외에 부가적인 기능을 수행하고자 할 때 핸들러 함수를 글로벌 정보 테이블에 등록하여 Uipc_RcvLoop() 내부에서 수신된 메시지가 없을 때 부가적인 작업을 수행한다.

Uipc_RcvLoop()는 타스크가 메인 큐로부터의 메시지 수신 및 수신된 메시지 처리를 수행하는 부분으로서 절대 리턴하지 않고 내부적으로 무한 루프를 수행한다. 이곳에서 메시지 수신/ 메시지 디코드 / 메시지 처리/ 부가적인 작업을 수행하게 된다.

다음으로 UIPC(30)의 UIPC 프로토콜 스택(protocol stack)(70)에 대해서 다시 도 4를 참조하여 상세히 설명하면 하기와 같다.

UIPC 프로토콜 스택(protocol stack)(70)

UIPC 프로토콜 스택(70)은 외부프로세스통신(interprocessor communication)을 위한 것이다. 외부 프로세스통신은 UIPC API(60)에서 UIPC프로토콜 스택(70)의 큐로 메시지를 송신함에 따라 수행된다. UIPC 프로토콜 스택(70)은 메시지 루트를 결정하기 위해 라우팅 라이브러리(routing library)를 필요로 하는데, 이때 어플리케이션ID APP_ID와 네트워크 어드레스 N_ADDR를 근거로 한다. 라우팅을 위해UIPC API(60)는 어플리케이션ID APP_ID와 네트워크 어드레스 N_ADDR를 갖고 라우팅 라이브러리(routing library)에서 제공하는 API를 호출하여 내부프로세스통신 메시지(intraprocessor message)인지 외부프로세스통신 메시지(interprocessor message)인지를 판단한다. 만약 외부프로세스통신 메시지(interprocessor message)이면 UIPC API(60)는 메시지를 UIPC 프로토콜 스택(70)의 큐로 송신한다. 통상적인 프로토콜 스택은 OSI(Open System Interconnection)모델에 따르지만 본 발명의 실시 예에 따른 UIPC 프로토콜 스택(70)은 7계층 전부를 지원하지는 않으며 하기와 같은 3계층만을 지원한다. 요컨대, 본 발명의 실시 예에 따른 UIPC 프로토콜 스택(70)은 데이터 링크 계층(link layer)(72), 네트워크 계층(network layer)(74), 및 전달 계층(transport layer)(76)을 지원한다. 상기 데이터 링크계층(72)에는 데이터링크 큐가 존재하며, 네트워크 계층(74)에는 네트워크 큐가 존재하고, 전달계층(76)에는 전달 큐가 존재한다.

본 발명에 따른 3가지 계층들의 기능은 하기에서 상세히 설명될 것이다. 그러나, 각 계층의 세부사항을 언급하기 전에 다음의 일반적인 필요조건들이 각 계층에 적용된다. 이것들은 상기 계층들의 구현자를 위한 가이드라인으로서 의도된다.

각 계층에 대한 헤더는 프로토콜 식별자(discriminator)를 포함하여야 한다. 상기 식별자는 어떤 프로토콜 또는 그들의 조합이 메시지에 수반되고 있는지를 나타낸다. 이것은 통상 헤더 내부의 2 또는 3비트로 이루어진다. 이것은 상이한 프로토콜들이 다른 프로토콜들로의 변경없이 앞으로도 구현되어질 것이다. 예를 들면, 네트워크 계층(74)에 의해 처리되고 있는 수신 메시지는 어느 프로토콜 모듈이 그메시지를 처리할 다음 차례이어야 하는가를 지시하는 네트워크 계층 헤더에 프로토콜 식별자를 보유할 것이다. 상기 UIPC가 TCP(Transmission Control Protocol) 또는 UDP(User Datagram Protocol)와 같은 전달계층 프로토콜들을 지원하고자 한다면, 상기 프로토콜 식별자는 상기한 TCP 또는 UDP 모듈에 상기 메시지를 전달할지 또는 아닐지를 상기 네트워크 계층(74)에게 알려줄 것이다. 상기 UDP는 인터넷 표준 네트워크 계층, 전달 계층, 및 데이터그램(datagram) 서비스를 제공하는 세션 계층 프로토콜들을 참조한다. 상기 UDP는 TCP와 마찬가지로 IP의 최상위 계층에 있는 비연결형 프로토콜이다.

어떤 프로토콜 계층들은 다른 계층들에 의존할 수도 있으며, 독립적으로 사용될 수 없을지도 모른다. 예를 들어, 물리 HDLC(High level Data Link Control)계층에 의존하는 데이터링크계층 프로토콜인 LAPD를 고려해볼 수 있다. 두문자를 딴 "LAPD"는 D채널 상의 링크 액세스 절차(link access procedure)를 나타낸다.

각 계층은 메시지의 우선도(priority)를 간직할 것이다. 높은 우선순위의 메시지들 또는 세그먼트(segments - 조각화될 필요가 있는 긴 메시지의 경우)는 다른 메시지들 또는 세그먼트들에 앞서서 항상 전송될 것이다. 단지 두 개의 우선도, 즉 '정상' 및 '높음'의 두 가지의 우선도가 본 발명에서 지원되는 것이 추천된다. 더 이상의 구분은 혼란만 초래할 수 있다. 하지만 그 이상으로 추가적인 우선도 구분에 대해서도 본 발명에 의해 지원될 수 있다.

각 계층은 엔드포인트(endpoint)에서 동일계층들간에 교환되는 특정 제어 메시지들을 정의할 수도 있다. 이러한 제어 메시지들은 어느 한 쪽이 프로토콜 파라미터에 대해서 협상하거나 또는 흐름제어를 수행하는 것을 허락한다.

이하의 부분은 각 프로토콜 계층의 특성들 및 책임들이 기술될 것이다. 각 부분은 또한 상기 계층이 제공해야만 하는 프리미티브(primitive) 리스트를 포함한다. 이 프리미티브들은 다른 소프트웨어에 제공되는 외부 인터페이스(즉, 그 다음 프로토콜 계층)를 보여주는 것으로 의도된다. 그들은 두 개의 엔드포인트들간에 통과되는 실제 메시지들을 설명하지는 않는다. 그 메시지들 및 그에 관련된 상태도(state machine)들의 정의는 여기서 설명되지 않을 것이다. 그러한 것은 구체적인 설계가 수행될 때 정의되어질 것이다.

상기한 프리미티브들은 ITU(International Telecommunication Uion)의 용어체계를 사용하여 이름붙여질 것이고, "Request", "Response", "Indication", 및 "Confirm"으로서 범주가 나누어질 것이다.

Request: 이것은 그 계층이 지원해야만 하는 하나의 기능을 의미하며, 어떤 동작을 요구하기 위하여 그 계층 상위의 다음 계층에 의해 유발(invoke)되는 것으로 의도된다.

Response: 이것은 하나의 응답을 필요로 하는 지시가 수신될 때 먼 쪽의 단말에 의해 유발된다. 결과적으로 상기한 'Request'의 요청자(requestor)가 확인을 접수할 것이다.

Indication: 이것은 하나의 이벤트가 일어났다는 통지이다. 이것은 다음 계층 오름 또는 나중에 생성한 코드가 이러한 지시들을 받는다는 것으로 의도된다. 대부분의 'Indication'들은 하나의 'Request'를 통해 어떤 동작을 개시하는 상기먼 쪽 단말의 결과이다.

Confirm(확인): 이것은 상기한 'Request'가 응답되어지는 확인(confirmation)이다.

각각의 프리미티브는 그에 관련된 프리미티브가 지정된 데이터를 갖는다. 계층들 사이에 프리미티브를 통과시키는 메커니즘은 그것이 계층들의 상세 설계의 일부이기 때문에 여기서는 구체적으로 설명되지 않는다.

최대 전송단위(Maximum Transmission Unit: MTU)가 정의되어야 한다는 점을 유념하는 것은 매우 중요하다. 최대 전송단위(MTU)는 최대 메시지 사이즈를 정의한다. 상기 사이즈 아래의 어떤 메시지들도 단일 메시지로서 전송된다.

최대 전송단위를 결정하는 것은 어플리케이션 설계의 일부이다. 따라서 그것은 상기 UIPC의 일부로서 정의되지는 않는다. 그러나, UIPC는 상기 최대 전송단위를 설정하기 위하여 UIPC의 구성요소에만 가시적인 내부의 API를 정의한다. 상기 최대 전송단위는 어플리케이션 작업수행 필요조건들, 하나의 메시지가 취하도록 예상되는 홉(hop: 라우터와 라우터 사이의 마디를 일컬음)의 숫자, 및 사용되고 있는 통신링크의 속도에 의해 결정된다.

하나의 노드에서 다음 노드로 메시지들의 경로를 안내하는 네트워크들로부터 일어나는 복잡한 문제가 존재한다. 만일 각각의 홉(hop)에 대한 상기 최대 전송단위(MTU)가 같지 않다면, 이러한 불균형을 해소하기 위하여 무엇인가가 행해져야만 한다. 여기서 문제는, 하나의 노드가 큰 MTU를 갖는 메시지를 전송할 때, 그리고 상기 메시지가 작은 MTU를 갖는 홉을 넘어서 한 노드를 통해 중계될 때 발생된다.하나의 메시지가 이동하는 모든 링크들의 모든 MTU들을 어느 한 노드가 안다는 것은 매우 어려울 것이다. 사실상, 발신 노드는 어떤 링크들에 이동될 것인지를 알지조차 못할 수가 있다. 그것이 아는 모든 것은 단지 다음 노드로 메시지를 어떻게 보내주는 하는 방법이다. 따라서, 각 노드의 프로토콜 스택은 해당 노드에 연결된 링크들 상의 MTU 사이즈에 있어서의 차이를 해결해야만 한다. 본 명세서에서 후술하는 "네트워크 계층(74)"이라는 부분에서 설명한 바와 같이, 네트워크 계층(74)은 메시지 분할(segmentation) 기능을 갖는다. 이것은 더 큰 MTU를 더 작은 MTU로 분할함에 이용되어야 한다. 만일 네트워크 계층이 각 노드에서 이것을 수행하지 않고자 한다면, 대안은 단 대 단(end-to-end) 연결을 구현하여 모든 노드들을 통해서 최대 MTU가 어떤 것이어야 하는지를 협의하여 결정하는 것이다. 그러나, 이 방법은 오버헤드를 발생하고 비연결형(connectionless) 메시지들에 대해서는 효과가 없을 것이다.

데이터 링크 계층(72)

먼저 UIPC 프로토콜 스택(70)이 지원하는 3계층중 먼저 데이터 링크 계층(72)에 대해서 설명하면 하기와 같다. 데이터 링크계층(72)은 엔드포인트(endpoints)간에 데이터 링크를 연결하고 링크간 무에러(error-free) 데이터 전송을 책임지며 다음과 같은 기능을 제공한다.

1. 데이터 우선순위를 제공하여 큐잉(queuing)한다.

2. 흐름 제어(flow control)를 제공하여 데이터의 원활한 송수신을 지원한다.

3. 무에러 데이터(error-free data) 전송을 지원한다.

4. 비연결형 모드(connection-less mode) 및 연결형 모드(connection -oriented mode)를 제공하며 연결형(connection-oriented)일 경우 데이터 링크를 연결 및 해제한다.

5. 에러 발생 시 해당 데이터에 대한 재전송이 가능하다.

하기 표 4는 연결형 데이터 링크들을 위해 최소한 요구되는 데이터링크계층(72)에서의 연결형 모드 프리미티브 및 그 설명을 요약한 것이고, 표 5는 비연결형 데이터 링크들을 위해 최소한 요구되는 데이터 링크 계층(72)에서의 비연결형 모드 프리미티브 및 그 설명을 요약한 것이다.

서 비 스	프리미티브	설 명
링크설정	DL-CONNECT request	원격 단 또는 물리 채널과의 연결을 시작.
	DL-CONNECT indication	원격 단이 당신에게 연결을 시작할 때 수신.
	DL-CONNECT response	연결을 수락하기 위해 DL-CONNECT indication의 수신측에 의해 유발됨.
	DL-CONNECT confirm	원격 단이 연결을 수락했다고 연결을 시작한 측에 알림.
정상 데이터 전송	DL-DATA request	송신측이 데이터를 송신하기 위해 사용함.
정상 데이터 전송	DL-DATA indication	수신측이 데이터 수신시에 이것을 취함.
링크해제	DL-DISCONNECT request	어느측이든 연결해제를 시작 가능. 응답은 없음.
링크해제	DL-DISCONNECT indication	원격 단이 연결해제를 할 때 수신.

<<데이터링크 계층(72)에서의 연결형 모드 프리미티브 및 그 설명>>

서 비 스	프리미티브	설 명
링크설정	DL-DATA request	송신측이 데이터를 송신하기 위해 사용함.
링크설정	DL-DATA indication	수신측이 데이터 수신시에 이것을 취함.

<<데이터링크 계층(72)에서의 비연결형 모드 프리미티브 및 그 설명>>

다음으로 UIPC 프로토콜 스택(70)이 지원하는 3계층중 네트워크 계층(74)에 대해서 설명하면 하기와 같다. 네트워크 계층(74)은 외부프로세스통신(interprocessor communication)시 프로세스들 사이의 메시지 라우팅을 책임진다. 네트워크 계층(74)은 하기와 같은 기능을 제공한다.

1. 메시지 라우팅 기능을 제공한다.

네트워크 어드레스 N_ADDR에 입각해 메시지 경로를 결정한다. 네트워크 계층은 메시지가 수신된 프로세스의 메시지로서 전달계층으로 보내져야할지 아니면 최종 목적지에 도달하기 위해 다른 인터페이스를 통해 전달될 필요가 있는지 결정한다.

2. 메시지의 분할(segmentation)과 재조립(reassembly)을 지원한다.

메시지 라우팅시 데이터 링크 계층의 최대 전송단위(maximum transport unit : MTU)가 상이한 인터페이스로 메시지를 전달할 경우 메시지의 분할 및 재조립이 이루어진다.

3. 무상태 동작(stateless operation)을 수행한다.

네트워크 계층(74)은 메시지 재전송 기능을 지원하지 않기 때문에 상태 천이도(state machine)가 없는 무상태 동작(stateless operation)을 수행한다. 일단 메시지가 송신되면 수신측의 수신여부와 관계없이 송신 메시지는 저장되지 않고 없어진다. 만약 엔드포인트간에 신뢰성 있는 송수신이 요구된다면 이는 전달계층(76)에서 수행해야 한다.

UIPC(30)에서는 상기한 네트워크 계층(74)의 기능을 수행하는 인터페이스를 갖도록 부가적인 어드레스 관련 프리미티브를 정의한다. 하기 표 6은 네트워크 계층(74)의 프리미티브 및 그 설명을 요약한 것이다.

서 비 스	프리미티브	설 명
정상 데이터 전송	N-DATA request	송신측이 데이터를 송신하기 위해 사용함.
정상 데이터 전송	N-DATA indication	수신측이 데이터 수신시에 이것을 취함.

<<네트워크 계층(74)에서의 프리미티브 및 그 설명>>

마지막으로 UIPC프로토콜 스택(70)이 지원하는 3계층중 전달 계층(transport layer)(76)에 대해서 설명하면 하기와 같다. 전달계층(76)은 타스크들간의 단 대 단(end-to-end) 통신에 대한 책임을 갖는다. 전달계층(76)은 다음과 같은 기능을 갖는다.

1. 메시지 라우팅기능을 제공한다.

수신된 메시지를 목적지 어플리케이션에 전달한다. 이를 위해 상기 전달계층(76)은 어플리케이션ID APP_ID를 기반으로 라우팅 테이블을 구축할 책임을갖는다. 상기 라우팅 테이블에 대한 접근은 UIPC API(60)에서 사용될 수 있도록 내부의 API를 통해 제공된다.

2. 비연결형 모드(connection-less mode) 및 연결형 모드(connection-oriented mode)를 제공한다. 비연결형 모드는 통신시 오버헤드를 줄이기 위해 하위계층(예컨대, 데이터링크 계층)들이 단 대 단간에 신뢰성을 보장한다는 가정 하에 사용하기 때문에 비연결형 모드에서는 데이터 링크 계층(72)과 동일하게 메시지 전송시 목적지 어플리케이션의 메시지 수신여부를 조사하지 않는다. 연결형 모드에서는 단 대 단(end-to-end)의 어플리케이션간에 연결이 설정되어야 메시지 송수신이 가능하며 이는 TCP(Transmission Control Protocol)의 소켓(socket)과 기능 면에서 유사한 것이다. 연결형 모드(connection-oriented mode)는 연결설정 및 해제시 부가적인 오버헤드와 복잡성이 존재하므로 이러한 모드는 하위계층의 신뢰성이 예상되지 않을 때나 실시간 통신에 대한 요구가 비교적 크지 않을 때에 사용하는 것이 바람직하다.

3. 메시지 다중화(multiplexing) 기능을 제공한다.

여러 어플리케이션으로부터 다수의 메시지가 수신되면 상기 전달계층(76)은 발신지의 네트워크 어드레스 N_ADDR을 기반으로 메시지를 조합하여 해당 어플리케이션으로 전달한다.

하기 표 7은 외부 인터페이스 기능을 위해 요구되는 전달계층(76)에서의 연결형 모드 프리미티브 및 그 설명을 요약한 것이고, 표 8은 외부 인터페이스 기능을 위해 요구되는 전달계층(76)에서의 비연결형 모드 프리미티브 및 그 설명을 요약한 것이다.

서 비 스	프리미티브	설 명
링크설정	T-CONNECT request	어플리케이션과의 연결을 시작. 응답은 큐 핸들러와 관련됨.
	T-CONNECT indication	원격 단이 어플리케이션에 대한 연결을 시작할 때 수신됨.
	T-CONNECT response	연결을 수락하기 위해 T-CONNECT indication의 수신측에 의해 유발됨.
	T-CONNECT confirm	연결이 지금 이루어진다고 그 연결을 시작한 측에 알림.
정상 데이터 전송	T-DATA request	송신측이 데이터를 송신하기 위해 이것을 사용함.
정상 데이터 전송	T-DATA indication	수신측이 데이터 수신시에 이것을 취함.
링크해제	T-DISCONNECT request	어느측이든 연결해제를 시작 가능함. 응답은 없음.
링크해제	T-DISCONNECT indication	원격 단이 연결해제를 할 때 수신.

<<전달계층(76)에서의 연결형 모드 프리미티브 및 그 설명>>

서 비 스	프리미티브	설 명
정상 데이터 전송	T-DATA request	송신측이 데이터를 송신하기 위해 이것을 사용함.
정상 데이터 전송	T-DATA indication	수신측이 데이터 수신시에 이것을 취함.

<<전달계층(76)에서의 비연결형 모드 프리미티브 및 그 설명>>

지금부터 본 발명의 실시 예에 따른 발신지 타스크로부터 목적지 타스크로 메시지 데이터를 전달하는 개략적인 과정을 도 1 내지 도 6을 참조하여 설명하면 하기와 같다.

발신지 타스크는 목적지 타스크로 메시지를 전달하기 위해서, 상기 목적지타스크의 네트워크 어드레스 N_ADDR과 어플리케이션ID APP_ID와 아울러 메시지 데이터를 담을 수 있는 Uipc_SendMsg(data, destinationAddress) 함수를 UIPC API 라이브러리로부터 호출한다. 그에 따라 타스크는 Uipc_SendMsg(data, destinationAddress) 함수에 목적지 타스크의 네트워크 어드레스 N_ADDR과 어플리케이션ID APP_ID, 및 메시지를 실게 되고, UIPC API(60)는 목적지 주소 즉 네트워크 어드레스 N_ADDR이 자기 카드의 네트워크 어드레스인지를 판단한다. 목적지 주소인 네트워크 어드레스가 자기 카드의 네트워크 어드레스이면 목적지까지의 메시지 전달은 내부프로세스통신(intraprocessor communication) UIPC에 의해서 수행될 것이고, 자기 카드의 네트워크 어드레스가 아니면 목적지까지의 메시지 전달은 외부프로세스통신(interprocessor communication) UIPC에 의해서 수행될 것이다. 상기 UIPC API(60)는 Uipc_SendMsg(data, destinationAddress) 함수에 실린 네트워크 어드레스 N_ADDR이 자기 카드의 네트워크 어드레스이면 즉 내부프로세스통신 UIPC이면, 도 3의 OIA계층(54)에 의해서 제공되는 OIA API 라이브러리를 통해 직접 카드 내에 있는 목적지 타스크의 메시지 큐(queue)로 메시지를 전달한다. 상기 내부프로세스통신 UIPC일 경우에는 프로토콜 스택(70)을 이용하지 않는다. 메시지를 수신받은 목적지 타스크는 Uipc_RcvLoop() 함수를 이용해서 도 5 및 도 6에 도시된 공통 타스크 아키텍쳐의 기본적인 공통 제어 흐름에 의거하여 메시지 수신, 메시지 디코드, 메시지 처리, 타스크 별도의 처리가 요구되면 해당 기능 수행하는 제어를 수행한다.

한편 목적지 주소인 네트워크 어드레스 N_ADDR이 자기 카드의 네트워크 어드레스가 아니면 즉, 외부프로세스통신 UIPC이면 UIPC API(60)는 외부 목적지를 찾는 라우팅을 위해 UIPC 프로토콜 스택(70)의 메시지 큐로 메시지를 전달한다. 보다 구체적으로 설명하면, UIPC 프로토콜 스택(70)의 전달 큐로 메시지를 전달한다. 전달 계층(76)에서는 전달 큐에 수신된 메시지에 대해서 전술한 바와 같은 전달계층 고유의 동작을 수행한 후 메시지를 처리한 후 네트워크 계층(74)의 네트워크 큐로 전달한다. 네트워크 계층(74)에서는 네트워크 큐에 수신된 메시지를 전술한 바와 같은 네트워크 계층 고유의 동작을 수행한 후 데이터 링크 계층(72)의 데이터링크 큐로 전달한다. 데이터 링크 계층(72)에서도 데이터링크 큐에 수신된 메시지를 전술한 바와 같은 데이터링크 계층 고유의 동작을 수행한 후 DIA계층(도 3의 46), 디바이스 드라이버(48)를 통해 목적지 카드의 DIA계층(도 3의 46), 디바이스 드라이버(48)로 전달을 하게 된다.

목적지 카드의 DIA계층(도 3의 46), 디바이스 드라이버(48)로 수신된 메시지는 프로토콜 계층(70)의 데이터링크 계층(72), 네트워크 계층(74), 전달계층(76)을 통해 목적지 타스크로 전달된다. 목적지 카드 및 목적지 타스크에 대해서는 네트워크 어드레스 N_ADDR 및 어플리케이션ID APP_ID를 이용해서 알 수 있다. 그에 따라 목적지 타스크는 UIPC API라이브러리에 의해서 제공되는 Uipc_RcvLoop() 함수를 이용해서 도 5 및 도 6에 도시된 공통 타스크 아키텍쳐의 기본적인 공통 제어 흐름에 의거하여 메시지 수신, 메시지 디코드, 메시지 처리, 타스크 별도의 처리가 요구되면 해당 기능 수행하는 제어를 수행한다.

하기 표 9는 UIPC API(60)로부터 타스크내에 호출되어 수행되는Uipc_SendMsg(data, destinationAddress) 함수에 대한 프로그램 일 예이다.

하기 표 10은 UIPC API(60)로부터 타스크내에 호출되어 수행되는 Uipc_RcvLoop() 함수에 대한 프로그램 일 예이다.

상술한 본 발명의 설명에서는 구체적인 실시 예에 관해 설명하였으나, 여러 가지 변형이 본 발명의 범위에서 벗어나지 않고 실시할 수 있다. 따라서 본 발명의 범위는 설명된 실시 예에 의하여 정할 것이 아니고 특허청구범위와 특허청구범위의 균등한 것에 의해 정해 져야 한다.

상술한 바와 같이 본 발명은 UIPC가 공통 타스크 아키텍쳐라는 구조를 통해 모든 어플리케이션(프로세스)이 공통의 구조를 갖음으로써 개발의 용이함을 향상 시키고 개발기간의 단축을 보장한다. 또한 공통 소프트웨어 플랫폼이라는 수평 구성성분들과 수직 구성성분들의 조합을 통해 UIPC에서는 프로세스 통신에 있어 운영체제와 디바이스의 변경에 따른 작업을 없애게 해주는 장점이 있다.

Claims

발신지로부터 목적지로 메시지를 전달하기 위한 통신방법에 있어서,

운영체제 독립형 액세스(OIA)계층에 의해서, 통신장치의 운영체제(OS)에 독립적으로 액세스 가능한 운영체제 통합 인터페이스 기능을 제공하는 과정과,

디바이스 독립형 액세스(DIA)계층에 의해서, 상기 통신장치의 피지컬 디바이스에 독립적으로 액세스 가능한 디바이스 통합 인터페이스 기능을 제공하는 과정과,

통합형 프로세스간 통신(UIPC)계층에 의해서, 상기 발신지 타스크에 의해 제공되는 목적지 정보와 타스크의 기본적인 공통 제어 흐름을 가지는 공통타스크 아키텍처를 이용하여 상기 발신지로부터의 메시지를 상기 운영체제 독립형 액세스 계층 및 상기 디바이스 독립형 액세스 계층중 적어도 하나를 통해 상기 목적지로 전송하는 하는 과정으로 이루어짐을 특징으로 하는 프로세스간 통신방법.
제1항에 있어서, 상기 통합형 프로세스간통신 계층은,

상기 타스크가 UIPC 기능을 사용할 수 있도록 인터페이스를 제공하며, 상기 목적지 정보에 근거하여 상기 목적지 정보에 의거하여 외부 및 내부 프로세스통신 경로를 결정하는 UIPC 어플리케이션 프로그램 인터페이스(API)와,

상기 UIPC API에 의해 경로 결정된 메시지중 외부 프로세스통신을 위해 유니트간 라우팅을 수행하는 UIPC 프로토콜 스택으로 구성됨을 특징으로 하는 프로세스간 통신방법.
제1항에 있어서, 상기 UIPC 프로토콜 스택은,

엔드포인트간에 데이터 링크를 연결하고 링크간 무에러 데이터 전송을 책임지는 데이터 링크 계층과,

외부프로세스통신시 타스크들간의 메시지 라우팅을 책임지는 네트워크 계층과,

타스크들간의 단 대 단 통신을 책임지는 전달계층으로 이루어짐을 특징으로 하는 프로세스간 통신방법.
제1항에 있어서, 상기 목적지 정보는, 통신하고자 하는 해당 타스크를 구분하기 위한 어플리케이션 인식자와, 상기 해당 타스크의 물리적 위치를 나타내는 네트워크 어드레스로 구성함을 특징으로 하는 통신방법.
제4항에 있어서, 상기 네트워크 어드레스는 랙-셀프-슬롯-포트(Rack-Shelf-Slot-Port)의 정보로 구성되어 있음을 특징으로 하는 통신방법.
제4항에 있어서, 상기 UIPC API는 어떠한 타스크에서도 이용될 수 있는 공유형 라이브러리임을 특징으로 하는 프로세스간 통신방법.
제1항에 있어서, 상기 공통 타스크 아키텍처의 기본적인 공통 제어 흐름은, 메시지 수신, 메시지 디코드, 메시지 처리, 타스크 별도의 처리 요구시 기타 특정한 해당 기능을 수행 작업으로 이루어짐을 특징으로 하는 프로세스간 통신방법.
발신지로부터 목적지로 메시지를 전달하기 위한 통신 장치에 있어서,

통신장치의 운영체제에 독립적으로 액세스 가능한 운영체제 통합 인터페이스 기능을 제공하는 운영체제 독립형 액세스(OIA)계층부와,

상기 통신장치의 피지컬 디바이스에 독립적으로 액세스 가능한 디바이스 통합 인터페이스 기능을 제공하는 디바이스 독립형 액세스(DIA)계층부와,

상기 발신지 타스크에 의해 제공되는 목적지 정보와 타스크의 기본적인 공통 제어 흐름을 가지는 공통타스크 아키텍처를 이용하여 상기 발신지로부터의 메시지를 상기 운영체제 독립형 액세스 계층 및 상기 디바이스 독립형 액세스 계층중 적어도 하나를 통해 상기 목적지로 전송하는 통합형 프로세스간 통신(UIPC)계층부로 구성함을 특징으로 하는 프로세스간 통신 장치.
제8항에 있어서, 상기 통합형 프로세스간통신 계층부는,

상기 타스크가 UIPC 기능을 사용할 수 있도록 인터페이스를 제공하며, 상기 목적지 정보에 근거하여 상기 목적지 정보에 의거하여 외부 및 내부 프로세스통신 경로를 결정하는 UIPC 어플리케이션 프로그램 인터페이스(API)와,

상기 UIPC API에 의해 경로 결정된 메시지중 외부 프로세스통신을 위해 유니트간 라우팅을 수행하는 UIPC 프로토콜 스택으로 구성됨을 특징으로 하는 프로세스간 통신 장치.
제8항에 있어서, 상기 UIPC 프로토콜 스택은,

엔드포인트간에 데이터 링크를 연결하고 링크간 무에러 데이터 전송을 책임지는 데이터 링크 계층과,

외부프로세스통신시 타스크들간의 메시지 라우팅을 책임지는 네트워크 계층과,

타스크들간의 단 대 단 통신을 책임지는 전달계층으로 구성함을 특징으로 하는 프로세스간 통신 장치.
제8항에 있어서, 상기 목적지 정보는, 통신하고자 하는 해당 타스크를 구분하기 위한 어플리케이션 인식자와, 상기 해당 타스크의 물리적 위치를 나타내는 네트워크 어드레스로 구성함을 특징으로 하는 통신장치.
제11항에 있어서, 상기 네트워크 어드레스는 랙-셀프-슬롯-포트(Rack-Shelf-Slot-Port)의 정보로 구성되어 있음을 특징으로 하는 통신장치.
제9항에 있어서, 상기 UIPC API는 어떠한 타스크에서도 이용될 수 있는 공유형 라이브러리임을 특징으로 하는 프로세스간 통신장치.
제8항에 있어서, 상기 공통 타스크 아키텍처의 기본적인 공통 제어 흐름은, 메시지 수신, 메시지 디코드, 메시지 처리, 타스크 별도의 처리 요구시 기타 특정한 해당 기능을 수행 작업으로 이루어짐을 특징으로 하는 프로세스간 통신 장치.
발신지로부터 목적지로 메시지를 전달하기 위한 통신방법에 있어서,

타스크의 기본적인 공통 제어흐름을 가지는 공통 타스크 아키텍쳐를 통합형 프로세스간통신(UIPC)을 위한 인터페이스로서 제공하는 과정과,

상기 공통 타스크 아키텍쳐를 이용하여 발신지 타스크가 메시지와 목적지 정보를 제공하면, 상기 목적지 정보에 근거하여 카드내의 내부프로세스통신 메시지인지 카드간의 외부프로세스통신메시지인지를 판단하는 과정과,

상기 카드간의 외부프로세스통신 메시지이면 라우팅을 위해 UIPC 프로토콜 스택의 큐로 메시지를 송신하는 과정과,

상기 내부프로세스통신이면 운영체제 독립형 액세스(OIA)계층에서 제공하는 어플리케이션 프로그램 인터페이스(API) 라이브러리를 통해 카드내의 해당 타스크의 메시지 큐로 메시지를 전달하는 과정으로 이루어짐을 특징으로 하는 프로세스간 통신방법.
제15항에 있어서, 상기 UIPC 프로토콜 스택은,

엔드포인트간에 데이터 링크를 연결하고 링크간 무에러 데이터 전송을 책임지는 데이터 링크 계층과,

외부프로세스통신시 타스크들간의 메시지 라우팅을 책임지는 네트워크 계층과,

타스크들간의 단 대 단 통신을 책임지는 전달계층으로 구성함을 특징으로 하는 프로세스간 통신방법.
발신지로부터 목적지로 메시지를 전달하기 위한 통신 장치에 있어서,

상기 장치의 운영체제와는 독립적으로 상기 장치 내에서 내부적인 통신을 처리하는 운영체제 부분과,

상기 장치에서의 하드웨어 디바이스들과는 독립적으로 상기 장치에 또는 그로부터 외부적인 통신을 처리하는 하드웨어 부분을 포함함을 특징으로 하는 프로세스간통신 장치.