KR100487225B1

KR100487225B1 - How to check dependencies between tables in SNP Agent

Info

Publication number: KR100487225B1
Application number: KR10-1998-0061019A
Authority: KR
Inventors: 박재홍
Original assignee: 삼성전자주식회사
Priority date: 1998-12-30
Filing date: 1998-12-30
Publication date: 2005-06-08
Also published as: KR20000044520A

Abstract

본 발명에는 에스엔엠피(SNMP) 에이전트에서 테이블간의 의존도를 체크하는 방법이 개시되어 있다. 이러한 본 발명은 SNMP 에이전트에서 사용자로부터 NMS나 웹상에서 하나 또는 그 이상의 테이블에 대한 세트 요구가 들어왔을 때 값을 세트하기 이전에 먼저 테스트 함수에서 의존도를 체크해야 할 때 스트럭쳐를 이용하는 처리하는 방법을 제안한다. 본 발명에 따르면, 의존도 체크를 위해 필요한 값들이 들어왔는지 쉽게 알 수 있고, 이 값들을 쉽게 탐색해서 이용할 수 있게 한다. 그러면 각 테이블마다 만약 의존도가 변한다 해도 쉽게 변경할 수가 있다. 그리고 스트럭쳐를 만들어서 구현하기 때문에 여러 가지 다른 부가적인 정보도 이용할 수 있기 때문에 코딩하는데 있어서 훨씬 자유로울 수 있다. 또한 각 테스트 함수가 실행될 때 처리할 수도 있고 테스트 절차가 모두 끝난 후에 처리할 수가 있어서 더 융통적이다. The present invention discloses a method for checking dependency between tables in an SMP agent. The present invention proposes a method of processing using a structure when the SNMP agent needs to check a dependency in a test function before setting a value when a set request for one or more tables is received from a user on an NMS or the web. do. According to the present invention, it is easy to know whether the values required for the dependency check have come in and make it easy to search and use these values. Then you can easily change the dependencies for each table if they change. And because the structure is built and implemented, many other additional information is available, making it much more free to code. It is also more flexible because it can be processed when each test function is executed, or after the test procedure is finished.

Description

How to check dependencies between tables in SNP Agent

본 발명은 에스엔엠피(SNMP) 통신시스템에 관한 것으로, 특히 SNMP 에이전트에서 스트럭쳐(Structure)를 이용하여 테이블간의 의존도(Dependency)를 체크하는 방법에 관한 것이다. The present invention relates to an SMP communication system, and more particularly, to a method of checking dependency between tables using a structure in an SNMP agent.

일반적으로 라우터(Router), PC(Personal Computer) 등과 같은 네트워크 장비(Network Device)는 워크스테이션(Workstation) 등으로 구현되는 네트워크관리시스템(NMS: Network Management System)에 의해 관리되게 된다. 이때 장비를 관리하는 NMS와 관리의 대상이 되는 네트워크 장비들은 소위 에스엔엠피(SNMP: Simple Network Management Protocol)를 사용하여 통신을 행하는 시스템이다. In general, a network device such as a router or a personal computer is managed by a network management system (NMS) implemented as a workstation. At this time, the NMS that manages the equipment and the network equipment that is the target of the management are systems that communicate using a so-called Simple Network Management Protocol (SNMP).

도 1은 일반적인 SNMP 통신시스템의 구성을 보여주는 도면으로, NMS(10)는 SNMP 매니저(MANAGER)가 되고, 네트워크 장비(20)는 SNMP 에이전트(AGENT)가 된다. 상기 SNMP 에이전트(20)는 NMS(10)나 웹(WEB)상을 통한 사용자로부터 하나 또는 그 이상의 MIB(Management Information Base) 테이블에 대한 세트 요구(SET REQUEST)를 받게 된다. 이때 SNMP 에이전트(20)에 세트 요구와 같은 인덱스(Index)가 이미 존재하는 경우는, 새로운 값으로 변경(Modify)하는 경우에 해당한다. 이러한 경우에 테스트 절차(TEST Procedure)가 실행될 때 만약 이 오브젝트(Object)와 다른 오브젝트 사이에 의존도(Dependency)가 존재한다해도 실제의 데이터 스트럭쳐(Data Structure)에 있는 값을 가져와서 처리하면 된다. 이와 달리 들어온 인덱스와 동일한 인덱스(예: 인터페이스)가 아직 존재하지 않는 경우는, 새로이 열(Row)을 생성(Creation)하는 경우에 해당한다. 1 is a diagram illustrating the configuration of a general SNMP communication system, in which the NMS 10 becomes an SNMP manager and the network equipment 20 becomes an SNMP agent. The SNMP agent 20 receives a set request for one or more MIB (Management Information Base) tables from a user via the NMS 10 or the web. At this time, if an index such as a set request already exists in the SNMP agent 20, it corresponds to a case of modifying to a new value. In this case, when the test procedure is executed, even if there is a dependency between this object and another object, the value in the actual data structure can be obtained and processed. In contrast, if the same index (for example, interface) does not exist yet, it is a case of creating a new row.

상기 도 1의 SNMP 에이전트(20)의 내부에 도 2에 도시된 바와 같은 2개의 테이블 - IP(Internet Protocol) 인터페이스 테이블(INTERFACE TABLE)(22), IP 통계 라우팅 테이블(STATIC ROUTING TABLE)(24)이 구비되어 있다고 가정할 때 이들 테이블간에는 다음과 같은 의존도가 존재할 수 있다. In the SNMP agent 20 of FIG. 1, two tables as shown in FIG. 2-an IP (Internet Protocol) interface table (INTERFACE TABLE) 22, and an IP statistical routing table (STATIC ROUTING TABLE) 24 Assuming that is provided, the following dependencies may exist between these tables.

첫째, IP 인터페이스 테이블(22)에서 MTU(Maximum Transmission Unit) 크기를 세트하려고 하면 들어온 인덱스와 같은 인터페이스가 미리 존재하여야 한다. 만약 존재하지 않으면 IP 어드레스 오브젝트가 PDU(Protocol Data Unit) 앞에 들어와야 된다. 왜냐하면, 이 오브젝트는 인터페이스를 생성하는 오브젝트이기 때문이다. 그래서 먼저 세트가 되면 인터페이스가 생겨서 그 다음 MTU 크기를 세트할 수 있기 때문이다. First, when attempting to set the size of the maximum transmission unit (MTU) in the IP interface table 22, an interface such as an index to be present must already exist. If not present, an IP address object must come before the PDU (Protocol Data Unit). This is because this object creates an interface. So if it is set first, then an interface will be created and then the MTU size can be set.

둘째, IP 통계 라우팅 테이블(24)에서 라우팅 인터페이스를 세트할 때도 인터페이스 유무와 그 값을 알아야 한다. 현재 만약 존재하지 않는다면, PDU 앞부분에 IP 어드레스를 세트하는 오브젝트가 같이 와야 한다. 즉 이때는 2개 테이블의 PDU가 와야 된다. Second, when setting the routing interface in the IP statistics routing table 24, it is necessary to know the existence of the interface and its value. If not currently present, the object that sets the IP address must come before the PDU. In other words, PDUs of two tables should come.

열 생성시 테스트 절차가 실행될 때 필요한 오브젝트가 들어왔는지 확인하기 위해서 종래에는 도 4에 도시된 흐름에 나타낸 바와 같이 전역 변수(Global Variable)를 사용한다. 필요한 오브젝트가 들어왔으면, 도 3에 도시된 바와 같이 테스트 함수(Function)에서 적당하게 값을 세팅한다. 그러나 이러한 방법을 사용하는 경우 다음과 같은 문제점이 있다. In order to check whether an object required when a test procedure is executed when generating a column, a global variable is conventionally used as shown in the flow shown in FIG. 4. When the required object is entered, the value is appropriately set in the test function as shown in FIG. 3. However, there are the following problems when using this method.

첫째, 프로그래밍을 하면서 필요한 오브젝트(열 생성하는 오브젝트, 비교하기 위해서 참조되는 오브젝트)를 정확히 알고 시작하여야 한다. 그러나 만약 프로토콜을 구현하는 사람과 SNMP 에이전트를 구현하는 사람이 다르다면 위와 같은 동작은 매우 어려운 일이다. First, as you program, you need to know exactly what objects you need (the objects that generate columns, and the objects that are referenced for comparison). However, if the person who implements the protocol is different from the person who implements the SNMP agent, the above behavior is very difficult.

둘째, 들어온 PDU에서 그 값을 찾을 때마다 처음부터 끝까지 탐색(Search)하는 함수를 사용해야 한다. 그러나 이러한 동작은 코드를 매우 복잡하게 만든다는 문제점이 있다. Second, whenever you find the value in the incoming PDU, you must use the search function from beginning to end. However, this behavior makes the code very complicated.

따라서 본 발명의 목적은 SNMP 에이전트에서 세트 요구가 들어왔을 때 테이블간의 의존도를 보다 간편하게 체크하는 방법을 제공함에 있다. Accordingly, an object of the present invention is to provide a method for more easily checking the dependencies between tables when a set request is received from an SNMP agent.

본 발명의 다른 목적은 SNMP 에이전트에서 세트 요구가 들어왔을 때 테이블간의 의존도를 체크할 시 코드를 매우 복잡하게 만들어야 하는 문제점을 해소하는 방법을 제공함에 있다. Another object of the present invention is to provide a method for solving the problem of making a code very complicated when checking a dependency between tables when a set request is received in an SNMP agent.

이러한 목적을 달성하기 위한 본 발명은 SNMP 에이전트에서 사용자로부터 NMS나 웹상에서 하나 또는 그 이상의 테이블에 대한 세트 요구가 들어왔을 때 값을 세트하기 이전에 먼저 테스트 함수에서 의존도를 체크해야 할 때 스트럭쳐를 이용하는 처리하는 방법을 제안한다. 이러한 본 발명은 의존도 체크를 위해 필요한 값들이 들어왔는지 쉽게 알 수 있고, 이 값들을 쉽게 탐색해서 이용할 수 있게 한다. 그러면 각 테이블마다 만약 의존도가 변한다 해도 쉽게 변경할 수가 있다. 그리고 스트럭쳐를 만들어서 구현하기 때문에 여러 가지 다른 부가적인 정보도 이용할 수 있기 때문에 코딩하는데 있어서 훨씬 자유로울 수 있다. 또한 각 테스트 함수가 실행될 때 처리할 수도 있고 테스트 절차가 모두 끝난 후에 처리할 수가 있어서 더 융통적이다. In order to achieve this purpose, the present invention utilizes a structure when a SNMP agent needs to check dependencies in a test function before setting a value when a set request for one or more tables is received from a user on the NMS or the web. Suggest ways to handle it. This invention makes it easy to see if the values needed for the dependency check have come in and make it easy to find and use them. Then you can easily change the dependencies for each table if they change. And because the structure is built and implemented, many other additional information is available, making it much more free to code. It is also more flexible because it can be processed when each test function is executed, or after the test procedure is finished.

이하 본 발명의 바람직한 실시예의 상세한 설명이 첨부된 도면들을 참조하여 설명될 것이다. 하기에서 본 발명을 설명함에 있어, 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 발명에서의 기능을 고려하여 정의내려진 용어들로서 이는 사용자 또는 칩설계자의 의도 또는 관례 등에 따라 달라질 수 있으므로, 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. DETAILED DESCRIPTION A detailed description of preferred embodiments of the present invention will now be described with reference to the accompanying drawings. In the following description of the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. In addition, the terms to be described below are terms defined in consideration of functions in the present invention, which may vary according to the intention or custom of the user or chip designer, and the definitions should be made based on the contents throughout the present specification.

도 5는 본 발명에 따라 도 1에 도시된 SNMP 에이전트(20)에서 테이블간의 의존도를 체크하는 처리흐름을 보여주는 도면이다. 이 처리흐름에 따르면, 사용자로부터 도 1에 도시된 NMS(10)나 웹상에서 하나 또는 그 이상의 테이블에 대한 세트 요구가 들어왔을 때 SNMP 에이전트(20)는 그 값(Value)을 세트하기 이전에 먼저 테스트 함수에서 의존도를 체크해야 할 때 스트럭쳐(Structure)를 이용하여 처리하는 것을 특징으로 한다. 5 is a flowchart illustrating a process of checking dependency between tables in the SNMP agent 20 shown in FIG. 1 according to the present invention. According to this process, when a user receives a set request for one or more tables on the NMS 10 shown in FIG. 1 or on the web, the SNMP agent 20 first checks before setting the value. It is characterized by processing by using structure when it is necessary to check dependency in test function.

상기 도 5에 도시된 처리흐름의 특징으로 살펴보면 다음과 같다. Looking at the characteristics of the processing flow shown in Figure 5 as follows.

첫째, 들어온 모든 테이블에 대해서 미리 정의된 스트럭쳐대로 메모리 할당(Memory Allocation)을 한다. First, memory allocation is performed for all the tables in the predefined structure.

둘째, 의존도 체크가 필요한 오브젝트는 이 스트럭쳐의 값(flag, value)을 이용하여 체크한다. Second, objects that require dependency checking are checked using the value of the structure (flag, value).

셋째, 다른 테스트 함수에서도 의존도 체크가 필요할 경우 이 테이블의 스트럭쳐를 이용한다. Third, if other test functions require dependency checking, the structure of this table is used.

넷째, 세트 함수에서는 스트럭쳐에 있는 타입(Type)에 따라서 각각 코딩을 한다. 이때 타입으로는 생성(CREATE), 변경(MODIFY), 완료(DONE)가 있다. Fourth, in the set function, each coding is performed according to the type in the structure. Types include CREATE, MODIFY, and DONE.

다섯째, 의존도 체크 루틴만 따라 테스트 함수에서 분리해서 테스트 절차가 끝난 후 실행되게 할 때 의존도 체크 스트럭쳐를 이용한다. Fifth, the dependency check structure is used to separate the test function from the test function and execute it after the test procedure is finished.

상기 도 5에 도시된 바와 같이 본 발명에서는 의존도 헤더(Dependency Header)와 각 테이블의 스트럭쳐(Structure)를 만든다. 여기서 있는 변수들은 의존도 체크시 또는 세트 함수 실행시 유용하게 사용될 수 있다. 첫 번째 테스트 함수에서 들어온 값을 체크해서(501단계∼503단계) 유효하면 의존도 리스트의 해당 변수에 유효한 것으로 체크된 값과 플래그를 함께 라이트한다(505단계). 그러면 다른 오브젝트를 테스트할 때 이 값과 의존도가 있으면 참조할 수 있다(504단계). As shown in FIG. 5, the present invention creates a dependency header and a structure of each table. The variables here can be useful when checking dependencies or executing set functions. If the value entered from the first test function is checked (steps 501 to 503), if it is valid, the flag and the value checked as valid for the variable of the dependency list are written together (step 505). This value and dependency can then be referenced when testing other objects (step 504).

상기 도 5에 도시된 바와 같은 처리흐름을 예를 들어 설명하면 다음과 같다. Referring to the processing flow as shown in FIG. 5 by way of example.

IP 인터페이스의 MTU 크기를 세트하려고 하는데 만약 들어온 인덱스와 같은 인터페이스가 실제의 데이터 스트럭쳐에 존재하지 않으면 세트할 수가 없다. 그러나 IP 인터페이스 어드레스 오브젝트가 같이 들어왔다면 이 오브젝트는 테이블의 인터페이스를 만들 수 있기 때문에 먼저 세트가 된다면 그 다음 MTU 크기를 세트하는 것이 가능하다. 이때 스트럭쳐의 해당 플래그를 보면 쉽게 알 수가 있다. If you try to set the MTU size of an IP interface, you cannot set it if the same interface as the incoming index does not exist in the actual data structure. However, if the IP interface address object comes in together, it can create an interface for the table, so it is possible to set the next MTU size if it is set first. This can be easily seen by looking at the flag of the structure.

이것은 두 번째 테스트 함수에서도 사용된다. 왜냐하면 라우팅 인터페이스를 세트하기 위해서는 만약 그 인터페이스가 현재 존재하지 않는다면 이 오브젝트가 같이 들어 왔는지 확인이 필요하기 때문이다. 즉 이러한 스트럭쳐를 이용하면 어느 테스트 함수에서나 쉽게 값이 들어왔는지 확인할 수 있고, 그 값을 비교할 때 참조할 수 있다. This is also used in the second test function. This is because setting up a routing interface requires checking that this object is present if the interface does not currently exist. This structure makes it easy to see if a value is coming from any test function and to refer to it when comparing values.

또 에이전트가 라이브러리로 구현되지 않았다면, 다시 말해서 테스트 절차가 모두 끝나고 세트 절차로 들어가기 전에 어떤 루틴을 추가할 수 있다면 의존도 체크 루틴을 모듈화하여 쉽게 구현할 수가 있다. 상기 도 5의 세트 함수에서는 타입 변수(Type Variable)를 이용해서 생성(CREATE)일 때 들어온 모든 오브젝트 값을 한꺼번에 세트할 수 있고 타입을 완료(DONE)로 바꾸어서 그다음 세트 함수가 실행되면 생략하고 넘어갈 수 있다. 상기 도 5에서 500단계 내지 509단계의 동작은 테스트 함수가 실행되는 동작에 해당하고, 나머지의 단계인 510단계 내지 513단계의 동작은 세트 함수가 실행되는 동작에 해당한다. If the agent is not implemented as a library, in other words, if you can add some routine before the test procedure is finished and before entering the set procedure, you can easily implement the dependency check routine by modularizing it. In the set function of FIG. 5, all object values that are entered at the time of creation using a type variable can be set at once, and the type can be changed to DONE so that the next set function can be skipped and skipped. have. In FIG. 5, operations 500 through 509 correspond to operations in which a test function is executed, and operations 510 through 513, which are the remaining steps, correspond to operations in which a set function is executed.

상술한 바와 같이 본 발명은 다음과 같은 이점이 있다. As described above, the present invention has the following advantages.

첫째, 의존도 체크시 함께 들어온 값들중에서 필요한 값을 언제 어디서나 쉽게 참조할 수 있다. 둘째, 부가적인 변수를 사용함으로써 코딩이 간단해진다. 셋째, 테스트 절차가 끝나고 세트 절차가 시작되기 전에 모듈로써 의존도를 체크할 수 있고 해당 테스트 함수에서 구현될 수도 있어서 탄력성이 있다. 넷째, 의존도 체크를 위해서 참조되는 값을 미리 전역변수로 잡지 않아도 된다. 다섯째, 라이브러리로 된 에이전트를 사용한다면 할당된 의존도 리스트를 개방시켜야 하는데 그 시점을 쉽게 확인할 수 있다. 즉 세트 함수에서 모든 값이 세트되었으면 완료(DONE)으로 세트되는데 이때 의존도 리스트를 개방시키면 된다. 여섯째 각각의 세트 절차에서 세트할 필요없이 한꺼번에 세트하는 것이 가능하다. 따라서 코딩이 더 간단해진다. First, it is easy to refer to the required values anytime, anywhere among the values that come with the dependency check. Second, coding is simplified by using additional variables. Third, the dependencies can be checked as modules and implemented in the test function before the test procedure is finished and the set procedure begins. Fourth, it is not necessary to hold the value referred to for the dependency check as a global variable. Fifth, if you are using a library-based agent, you need to open the list of dependencies that are assigned. In other words, if all the values are set in the set function, it is set to DONE. Sixth, it is possible to set at once without having to set in each set procedure. This makes coding simpler.

한편 본 발명의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 발명의 범위에서 벗어나지 않는 한도내에서 여러가지 변형이 가능함은 물론이다. 그러므로 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 않되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다. Meanwhile, in the detailed description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

도 1은 본 발명이 적용되는 에스엔엠피(SNMP) 통신시스템의 구성을 보여주는 도면. 1 is a view showing the configuration of an SMP (SNMP) communication system to which the present invention is applied.

도 2는 도 1에 도시된 SNMP 에이전트에 구비된 테이블의 일예를 보여주는 도면. 2 is a view showing an example of a table provided in the SNMP agent shown in FIG.

도 3은 도 1에 도시된 SNMP 에이전트에 의한 테스트 및 세트 절차를 보여주는 도면. 3 shows a test and set procedure by the SNMP agent shown in FIG.

도 4는 종래기술에 따라 SNMP 에이전트에서 테이블간의 의존도를 체크하는 처리흐름을 보여주는 도면. 4 is a flowchart illustrating a process of checking dependency between tables in an SNMP agent according to the related art.

도 5는 본 발명에 따라 SNMP 에이전트에서 테이블간의 의존도를 체크하는 처리흐름을 보여주는 도면. 5 is a flowchart illustrating a process of checking dependency between tables in an SNMP agent according to the present invention.

Claims

In the method of checking the dependency between tables in the SMP agent,

A first step of determining whether a set request for one or more tables is received from a network management system (NMS) or the web;

A second step of determining whether a value according to the request is valid in a test function when it is determined that the set request comes in;

A third step of writing the value in the structure of the table when the value according to the request is valid;

A fourth step of checking an object for which dependency checking is required by using the value of the written structure;

And a fifth process of coding according to the type in the structure in the set function.

The method of claim 1, wherein in the third step, a flag is written with a value according to the request determined to be valid for the structure.

The method of claim 1, wherein the structure of the table is used when dependency checking is required in other test functions.