Ad-Hoc Network

Ad-Hoc 네트워크는 분산형 무선통신 네트워크를 의미하며 특정 기지국에 의존하지 않고 무선 이동단말로만 구성된 네트워크를 말한다. 

송수신을 담당하는 단말들은 다른 단말기의 신호를 중계하는 기지국 역할까지 수행하고, 다양한 단말을 경유하는 네트워크를 구성한다.

기존 유선망 기반 무선 네트워크인 기지국 중심의 네트워크는 기지국 고장 시 네트워크 전체가 마비될 수 있고 기지국의 자체 용량 때문에 허용할 수 있는 사용자의 범위가 한정되지만, Ad-Hoc 네트워크는 응용 분야 측면에서 재해에 강하며 사용자 규모별로 네트워크의 크기를 자유롭고 용이하게 변경이 가능케 한 구조이다.

다만, Ad-Hoc 네트워크에 주소문제, 보안문제 등이 기술 확산 및 보급에 걸림돌이 되고 있는 실정이다. 따라서 Ad-Hoc 네트워크가 널리 보급되기 위해서는 모든 Ad-Hoc 단말기에 유일한 주소가 부여될 수 있는 환경이 마련되어야 하며 이러한 해결책으로 인터넷 주소를 기존 IPv4 체제인 32비트에서 128비트인 IPv6로 확장하면 주소 문제는 해결될 것으로 보인다.

보안문제는 Ad-Hoc 네트워크의 가장 큰 취약점으로 지적되고 있으며, 이를 해결하여 안전한 네트워크를 사용할 수 있는 완벽한 프로토콜의 개발이 요구되고 있는 실정이다. Ad-Hoc 네트워크의 응용분야로서는 초기 군사 네트워크에서 출발하였으나 향후 WPAN 및 센서 네트워크 등의 유비쿼터스 컴퓨팅의 여러 분야에 활용될 것으로 전망되며 이러한 Ad-Hoc 네트워크 구조상에서 컴퓨터, 주변기기, 카메라, 헤드셋 등 다양한 전자기기간 상호 독립적인 통신이 가능한 네트워크의 구성이 가능하다.

출처 :  지식인 오픈백과

http://kin.naver.com/open100/detail.nhn?d1id=1&dirId=1&docId=132289&qb=RGlzayBBbmQgRXhlY3V0aW9uIE1vbml0b3I=&enc=utf8&section=kin&rank=2&search_sort=0&spq=0&pid=RU3kLF5Y7uGssZZR/LZsssssstG-028613&sid=UX3bNnJvLC4AAEEU-JQ

Daemon은 Disk And Execution Monitor 를 줄인 말이라고 합니다. 그렇지만, 프로그래머들이 "악마"를 컴퓨터 세상 속에 창조해 놓고, 나중에 위와 같이 점잖은 의미를 부여했다는 설이 더 설득력이 있어 보입니다.

데몬은 사용자가 필요할 때 불러와서 사용하는 일반 응용프로그램과는 달리, 특정한 동작을 보여주지 않은 채 잠복해 있는 프로그램을 의미합니다. 프린터 스풀러가 좋은 예가 될 수 있습니다. 프린터 스풀러는 윈도우즈가 실행되는 동안 어딘가에 잠복해 있다가, 어떤 프로그램에서 인쇄를 해야 할 일이 생기면 실행되어서 인쇄와 관련된 작업을 수행하거나 지시합니다.

웹서버, FTP서버 등 많은 종류의 서버들은 "데몬"이 대표적으로 이용되는 분야라 할 수 있습니다. PC에 웹서버 프로그램을 설치하여 구동시키면 웹서버 데몬이 실행됩니다. 그렇지만, 달라진 것은 아무것도 없습니다. 다만, 그 데몬의 역할을 엿보는 모니터링 도구 같은 것을 이용하면 웹서버 데몬이 어떤 역할을 수행하고 있다는 것을 알 수 있습니다. 그렇지만, 예를 들어 외부에서 아무도 웹 서버에 접속하지 않는 동안은 웹서버 데몬은 그저 잠복해 있을 뿐입니다.

위에서 윈도우즈의 프린터 스풀러를 예로 들었는데, 데몬의 개념이 도입된 것은 유닉스 시스템이고, 데몬을 가장 널리 활용하는 운영체제도 유닉스라 할 수 있습니다.

유닉스에서 대표적인 데몬 툴로는 웹서버, FTP 서버 이런 것들을 제외하고는 CRON 툴이 있습니다. 특정 시간에 지정한 명령을 실행시켜주는 이 툴은 데몬의 형태를 갖는 대표적인 유닉스의 기능이라 할 수 있습니다. 윈도우즈로 치자면 "예약 작업(Scheduled Task)"과 유사합니다.

다시 한번 반복하자면, 데몬은 특정한 동작을 하고 있지 않은 채, 어떤 동작에 대한 요청을 받아들이기 위해 잠복하고 있는 프로그램입니다. 이것은 위에서 예로 든 것처럼 운영체제 수준에서 제공되는 것들도 있지만, 특정 응용프로그램 내에서 사용되는 경우도 있습니다.

그 개념은 같지만, 운영체제 수준의 데몬을 Daemon, 응용프로그램 수준의 데몬을 Demon으로 구분하는 경우도 있으니, 참고하시기 바랍니다. 응용프로그램 수준의 데몬은 그 응용프로그램을 개발한 사람의 의사에 따라 Agent처럼 다른 명칭으로 불리기도 하구요.

끝으로 한 가지 사족을 달까 합니다. 최근에는 가상 CD-ROM/DVD-ROM 드라이브를 에뮬레이트하는 유틸리티들 중 하나의 이름이 "데몬툴(Daemon-Tools)"이라, 이것 때문에 입에 오르내리는 용어가 되기도 했습니다.

INSTANCE 란?

①일반적으로 어떤 집합에 대해서, 그 집합의 개별적인 요소. 객체 지향 프로그래밍(OOP)에서, 어떤 등급에 속하는 각 객체를 인스턴스라고 한다. 예를 들면 ‘목록(list)’이라는 등급을 정의하고 그 다음에 ‘본인 목록(my list)’이라는 객체를 생성(기억 장치 할당)하면 그 등급의 인스턴스가 생성된다. 또한 변수가 포함되어 있는 어떤 논리식의 변수에 구체적인 값을 대입하여 식을 만들면 원래 식의 인스턴스가 만들어진다. 이런 의미에서 인스턴스를 실현치라고 한다. 
②프로그램 작성 언어 에이다(Ada)에서 매개 변수를 사용해서 절차를 일반적으로 정의한 범용체(generic package)에 대해, 그것으로부터 도출한 구체적인 실체.

출처 : http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040201&docId=69718936&qb=aW5zdGFuY2U=&enc=utf8&section=kin&rank=1&search_sort=0&spq=0&pid=RU3RdU5Y7tosstowSPZsssssssC-287841&sid=UX3To3JvLCkAABa1kn8

-----------------------------------------------------------------------

instance란 자바뿐만 아니라... 객체지향형의 모든 툴에서 동일하지 않나요?
class로만 설명을 해보면...class는 단지 동작에 대한 서술만이 있을 뿐입니다. 실제 사용을 할 수가 없다는 거죠.실제 사용을 위해 인스턴스를 생성하는 겁니다.

즉, 클래스를 메모리에 로딩해서 사용가능하게 만든 상태라고 설명하면 될까요?

그러니깐... 클래스 자체는 기계의 도면일 뿐이고 이 도면을 갖고 실제 기계가 완성된 상태가 인스턴스라고 설명하면 되겠내요. ^^;

-------------------------------------------------------------------------

class는 단지 변수와(상태값) 변수(상태값)에 값을 넣기위한 동작에 대한 서술만이 있을 뿐입니다. 실제 사용을 위해 인스턴스를 생성하는 겁니다.

즉, 클래스( 기술해 놓은 구조) 를 메모리에 로딩해서 사용가능하게 만든 상태 따라서... 클래스를 사용하기 위해서는 반드시 생성하는 작업을 해야 합니다.
그리고 코드로 설명하면
Class c1 = new NewClass() ; ---> 이런코드가 있다면

c1은 instance variables 이 됩니다.
즉 인스턴스를 가리키고 있는 variable이 되는 거죠.

그리고 instance of a class 라는 거는 위에 설명되어있는 것처럼
클래스의 실체를 메모리에 생성한겁니다.

즉,

Class c1 = new NewClass() ; 
Class c2 = new NewClass() ; 
Class c3 = new NewClass() ; 
Class c4 = new NewClass() ; 
Class c5 = new NewClass() ; 

이렇게 다섯개의 instance variables 가 있다면
c1 ~ c5의 variable은 NewClass 라는 클래스의 instance가 되죠.
---> instance of a class

----------------------------------------------------------

이해하기 쉽게 예를 들어보겠습니다.

클래스를 붕어빵을 만드는 기계라고 생각해보세요.

인스턴스는 붕어빵 기계로 만든 "붕어빵"입니다.

클래스가 개념적인 형태라면 인스턴스는 실체입니다.

예) SampleClass sc = new SampleClass();

위에서 SampleClass 는 클래스이고, sc는 인스턴스이고 여기서는 new는 클래스에서

인스턴스를 만드는 생성자 함수입니다.

출처 : 

http://www.freedesktop.org/wiki/Software/dbus

먼저, freedesktop.org는 X윈도우 시스템 및 이를 기반으로 하는 데스크톱과 관련된 정보를 처리,상호운용하는 그리고 공용기술을 규격화하고 해당요소들을 사용하는 오픈소스 소프트웨어 프로젝트들을 호스팅하는 사이트이다. 

*X윈도우시스템 : GUI환경 구현을 위한 Software, Network Protocol 이다.

D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed.

D-Bus란 메세지 버스시스템이다. 이는 어플리케이션끼리 대화를 하는 간단한 방법이다. 칩셋에서 내부적인 통신뿐만 아니라 D-Bus는 상호적인 Lifecycle(생활주기?)을 도와준다.또한, 간단하고 신뢰성있는 single instance단위의 어플리케이션과 데몬을 코딩할수있게 만들어주며, 관련서비스가 실행되어야 할때 데몬과 어플리케이션이 실행될수있도록 도와준다. (즉, 데몬을 실현하는 시스템으로 이해)

D-Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per-user-login-session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one-to-one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon). Currently the communicating applications are on one computer, or through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories. (Help wanted with better remote transports - the transport mechanism is well-abstracted and extensible.)

The D-Bus low-level API reference implementation and protocol have been heavily tested in the real world over several years, and are now "set in stone." Future changes will either be compatible or versioned appropriately.

The low-level libdbus reference implementation has no required dependencies; the bus daemon's only *required* dependency is an XML parser (expat). Higher-level bindings specific to particular frameworks (Qt, GLib, Java, C#, Python, etc.) add more dependencies, but can make more assumptions and are thus much simpler to use. The bindings evolve separately from the low-level libdbus, so some are more mature and ABI-stable than others; check the docs for the binding you plan to use.

There are also some reimplementations of the D-Bus protocol for languages such as C#, Java, and Ruby. These do not use the libdbus reference implementation.

It should be noted that the low-level implementation is not primarily designed for application authors to use. Rather, it is a basis for binding authors and a reference for reimplementations. If you are able to do so it is recommended that you use one of the higher level bindings or implementations. A list of these can be found on the bindings page.

The list of projects using D-Bus is growing and they provide a wealth of examples of using the various APIs to learn from.

D-Bus is very portable to any Linux or UNIX flavor, and a port to Windows is in progress.

If you have any trouble with D-Bus or suggestions for improvement, bug reports and comments are very welcome.

Get on D-Bus today!

출처 : 지식인

http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040101&docId=103092664&qb=64Sk7J6E7Iqk7Y6Y7J207Iqk&enc=utf8&section=kin&rank=3&search_sort=0&spq=1&pid=RU1uQF5Y7t8sscUGc80sssssssV-370126&sid=UX1CcXJvLDYAAHLTaog

예를들어 서울이라는 사람과 부산이라는 사람이 프로그램을 개발합니다.

역할분담을 하여 개발을 해서 합치려고 보니까 함수 이름이 같게 되어 함수 이름 등을 다 뜯어 고쳐야 하는 상황이 올 수 있습니다.

이런 현상이 발생하는 이유는 함수 이름에도 규칙이 있기 때문입니다. 함수는 최소한의 기능을 수행해야 하며, 함수의 이름은 직관적으로 알 수 있도록 지어야 합니다.

예를들어 학생의 주소를 반환하는 함수라면 getStudentAddress() 이런 이름등이 되겠죠

이 뿐만 아니라 혼자서 프로그램을 개발하다 보면 이름의 충돌등이 발생할 수 있습니다.

이를 막기 위해 네임스페이스를 사용합니다.

namespace 서울

{

   getStudentAddress();

}

namespace 부산

{

   getStudentAddress();

}

이렇게 된다면

두 함수의 이름이 같을지라도 얼마든지 구분하여 사용할 수 있습니다.

(이름이 같아도 함수의 역할이나 매개변수, 리턴값들이 다를 수 있습니다.)

네임 스페이스의 사용방법은 위의 경우처럼 선언을 하시면 되고

사용할때는

서울::getStudentAddress();  처럼 사용하시면 됩니다.

그리고 네임 스페이스를 별도로 정의하지 않아도 항상 존재하는 네임 스페이스가 있는데 이를 전역 네임 스페이스라고 합니다. 디폴트 네임 스페이스라고 볼 수 있는데 흔히 전역변수를 선언하는 영역, 그러니까 함수의 바깥쪽이 바로 이 영역입니다. 이 영역은 원래부터 존재하므로 별도의 이름은 없습니다.

다음은 네임 스페이스의 작성규칙입니다.

1. 네임 스페이스의 이름도 일종의 명칭이므로 다른 명칭과 중복되어서는 안된다.

2. 네임 스페이스는 반드시 전역 영역에 선언해야 한다.

3. 네임 스페이스끼리 중첩 가능하다. 즉, 네임 스페이스 안에 또 다른 네임 스페이스를 선언할 수 있다.

4. 네임 스페이스는 항상 개방되어 있다.그래서 같은 네임 스페이스를 여러 번 나누어 명칭을 선언할 수 있다. 꼭 한꺼번에 몰아서 네임 스페이스내의 모든 명칭을 일괄 선언해야 하는 것은 아니다.

5. 네임 스페이스가 이름을 가지지 않을 수 있다.

6. 단일 모듈 프로젝트에서는 별 상관이 없지만 다중 모듈 프로젝트에서는 함수의 본체를 어디에 작성할 것인가 주의해야 한다. 여러 개의 모듈로 나누어진 프로젝트를 개발할 때는 보통 헤더 파일과 구현 파일을 따로 작성한다. 네임 스페이스안에 함수를 정의할 때 헤더 파일에 원형만 선언하고 구현 파일에 함수의 본체를 작성한다

즉, 네임스페이스는 개발자들에게 편의를 제공하기 위한 용도이며, 개발된 프로그램간의 충돌을 방지하기 위한것이다. 예를들어, 개발회사에서 함수테이블의 제공은 소속된 프로그래머들간의 변수이름의 혼란을 막기위해서이다. 하지만 기 개발된 프로그램의 경우 모든 변수이름을 변경하기엔 시간과 자원적인 낭비이다. 이럴때 바로 네임스페이스를 사용하게 되면 대단히 편리할것이다.

http://m.ktword.co.kr/index.php

【   정보통신기술용어해설   】

모수의 개념을 알기위해서 아래의 2가지 개념이해가 선행되어야 함.

모집단 : 통계적 관찰이 되는 집단.

전수조사 : 모집단의 어떤 한부분이나 샘플(표본)을 조사하는 것이아니라 모집단 전체를 대상으로 조사하는 것.

모수란?

모수는 모집단의 특성(모평균,모분산 등..)을 나타내는 값으로, 이 값을 모집단을 전수조사해야만 알수있는 값이다. 그러나 실질적으로 모집단의 크기와 범위가 너무 방대하기에 전수조사를 실지하지 않고 표본조사를 하는데 표본평균,표본분산 등으로 모평균, 모분산등을 추정할수가 있다.

9.       Message Types

 OSI7 구조를 아시나요?   트랜스포트 층의 ‘세그먼트’는 네트워크 층에서는 ‘데이터’  가 된다. 라는 개념이 CAN처럼 하위 2계층만 쓰는 프로토콜에선 메세지로 불리게 됩니다. 아래는 메세지의 타입입니다.

1)       Data Frame

이전에 이미 언급한 부분이라서 넘어갑니다.

2)       Remote Frame

- Receiver가 transmitter에 data를 요청할 때 출력하는 frame

- Arbitration field에는 transmitter의 ID가 포함되며 data field가 없는 것이 특징

3)       Error Frame

- Error 상황을 알리기 위한 frame

- Error를 감지한 node가 6 dominant bit를 출력하면 다른 node는 이에 반응 (stuff error)하여 6 dominant 

bit를 출력

- 6~12 dominant bits (Error Flag) + 8 recessive bits (Error delimiter)로 구성

- Superposition(중첩) : Node들이 출력하는 error flag의 순서에 따라서 중첩될 수 있음

- Error Delimiter : Error frame의 종료. 8 recessive bit로 구성

4)       Overload Frame

   - 다음의 상황에서 overload frame을 전송 (bus 상태를 안정화하기 위해서)

(1) Receiver의 내부 조건에 의해서 다음 data/remote frame 사이에 delay가 필요한 경우

(2) Frame 사이의 intermission의 1,2 bit가 dominant bit인 경우

(3) Error delimiter 또는 overload delimiter의 마지막 bit가 dominant bit인 경우

- 6 dominant bits (Overload Flag) + 8 recessive bits (Overload delimiter)로 구성

http://www.sigmobile.org/mobicom/

7.      The principle of CAN protocol  

CAN버스에서는 각각의 노드(ECU)가 CAN 버스에 흘러 다니는 데이터를 읽거나 쓰기 위해 액세스(access)할 때 전체 노드를 제어하는 마스터(master)가 없습니다. 따라서, 각 노드에서 데이터를 전송할 준비가 되면, 먼저 전송 준비가 되었는지를 버스에 확인하고 그 후 CAN 프레임을 네트워크에 전송하는데, 전송되는 CAN 프레임은 전송이나 수신 노드 중 어느 노드의 주소도 포함하고 있지 않으며, 대신, 고유한 ID를 통해 프레임을 분류하여 데이터를 인식하게 됩니다.

각 노드들이 동시에 메시지를 CAN 버스로 전송하려는 경우 최우선 순위를 가진 노드 (가장 낮은 중재 ID)가 자동적으로 버스에 액세스된다. (낮을수록 우선순위가 높은방식)

예를들어, CAN 통신을 통해 데이터를 액세스하는 과정은 아래와 같습니다.

① 먼저 CAN 버스라인이 사용 중인지를 확인한다.

② CAN 버스라인이 사용 중이 아니면, CAN 네트워크상의 모든 노드(ECU)는 메시지를 수신하여 자신에게 필요한 메시지인지를 식별자를 통해 확인한다.

③ 자신에게 필요한 메시지일 경우 입력받아 데이터를 분석하게 되고, 불필요 한 메시지는 무시하게 된다.

④ 여러 노드의 데이터가 동시에 자신의 노드로 유입되는 경우에, 식별자의 숫자를 비교하여 먼저 취할 메시지의 우선순위를 정한다. 식별자의 숫자가 낮은 경우가 우선순위가 가장 높다.

⑤ 각각의 CAN 메시지는 11비트의 식별자(CAN 2.0A) 또는 29비트의 식별자 (CAN 2.0B)를 가지며 CAN 메시지의 맨 처음 시작부분에 위치한다.

⑥ CAN 프레임의 식별자(ID)는 메시지의 내용을 식별시켜 주는 역할과 메시지 의 우선순위를 부여하는 역할을 한다.

⑦ 각 노드로부터 출력되는 데이터 메시지는 송신측이나 수신측의 주소를 가지 고 있지 않다. 대신 각 노드(ECU)를 식별할 수 있도록 각 노드마다 고유한 식별자를 가지고 있다.

8.      The arbitration of a Can Message

->결론적으로 말해서 CAN통신은 I^2C통신과 동일한 버스구조와 중재구조를 가집니다. 중재

가 필요한 이유는 CAN과 같은 동기식 통신에서 같은 시간 Time에 다른 메세지가 버스를 사용

할경우 충돌이 일어나게되는데 이를 해결하기위한 방법이 필요하기 때문이다.

CAN의 주요한 기능 중 하나인 중재는 11Bit 또는 18Bit의 Identifier(식별자)가 존재하기 때문에 가능한 기능입니다. 아래의 그림에서 보이는 CAN의 기본특성은 버스와 드라이버 입력 및 수신기의 출력간이 반대 로직 이라는 특성입니다. 보통의 버스에서 High신호는 1에 가깝고 Low신호는 0에 가깝지만 CAN버스 반대입니다.  

일단 CAN버스의 액세스는 event-driven형태이며 만약, 2개의 노드가 버스를 동시에 차지 할 경우, 액세

스의 형태는 중재(nondestructive, bit-wise arbitration)가 구현된다. Nondestructive의 의미는 중재의

형태가 메시지로 지속된다는 것을 의미한다. 이 말은 충돌이 일어났을 때 메시지는 다른 노드에 의해서

훼손되지 않으며, 오류를 발생시키지도 않는다는 것을 의미한다.

앞서 말했듯이, CAN의 특징 중 식별자에서 메시지의 우선 순위를 배치하는 특징이 존재한다고 하였다. 

이점이 바로 CAN을 실시간 제어 환경으로 만들어주며 우선적인 특정 이벤트를 먼저 실행시키는 기능을 

한다. 2진법 메시지 식별자 숫자가 더 낮을수록 우선순위는 더 높으며 만약 제로로 구성된 식별자는 네트

워크 상에서 가장 우선 순위의 메시지이다. 버스 도미넌트가 가장 긴 것을 가지고 있기 때문이다.

따라서 2개의 노드가 동시에 전송을 시작하면, 이 노드는 0(도미넌트: dominant)으로 전송하는 반면, 다

른 노드는 1(리세시브: recessive)로 전송해, CAN 버스를 제어하고 완벽한 메시지를 전송한다. 도미넌트 

비트는 CAN 버스에서 리세시브 비트에 겹쳐 쓴다.

[CAN BUS 의 LOGIC]

위 그림은 중재의 과정을 보여준다. 그림에서 하나의 노드라도 우성(Dominant)상태, 즉 Zero이게 되면

버스의 상태는 우성이 됩니다. 또한 어느 노드 하나라도 우성이 아니게 되면 그 버스의 상태는 열성 (recessive)상태 즉, one이 됩니다. 한마디로 해석하자면 CAN 버스 상에서는 우성비트는  열성비트를 무시하게 되는 것입니다. 따라서 버스의 상태가 우성이냐 열성이냐에 따라 데이터 전송을 제어할 수 있는 것입니다.

CAN 프로토콜은 "Carrier Sence Multiple Access With Collision Detection" 따라 버스 Access를 처리합니다. 만약 충돌이 발생하여도 메세지들은 결코 파괴되는 일이 발생하지 않고 충돌로 인해 낭비되는 대역폭도 생기지 않습니다. 이점으로 Ethernet과 달리 CAN에서는 충돌이 해결되는 부분이 되고 더 높은 우선순위를 가진 메시지가 버스에 접근할 수 있게 되는 것입니다. 그래서 각각의 노드들은 식별자를 가지고 있는 것입니다.

아래의 그림으로 CAN의 중재에 대해서 다시 설명한다면, 

먼저 제일 윗 줄에 있는 노드1, 그 밑에 있는 노드 2와 노드 3가 동시에 버스를 차지하기 위한 요청이 발생하였을 경우에 먼저 Start Of Frame을 시작으로하는데 이 부분은 무조건 우성으로 설정되 있어야 데이터 전송에 문제가 없을 것입니다. 다음에 나오는 것이 중재 필드 부분으로 데이터 프레임에 작성되어있습니다. 그림에서 왼쪽 갈색선이 첫번째 중재하는 영역으로 노드1과 노드3가 중재에서 승리하고 노드2는 열성비트로 인해 우선순위에서 최하위로 밀려나게 되고 다음 오른쪽 갈색선에서는 노드1과 노드2가 중재를 받게 되는데 여기서 노드1이 우성비트를 가지고 있으므로 우선순위 1위가 되어 제일 먼저 버스를 차지하게 되는 것입니다. 그 다음 노드2가 전송되고 마지막으로 대기상태였던 노드3이 전송되는 것이다. 비교적 간단한 개념이지만 이것으로 인해 CAN 통신의 신뢰성은 많이 향상될 수 있습니다.

이번에는 TI사에서 제공하는 report에 있는 그림으로 보겠습니다.

그림 5는 중재(arbitration) 과정을 보여줍니다. 노드가 지속적으로 자체 전송을 감시하기 때문에, 노드 B's recessive bit가 노드 C의 더 높은 우선 순위인 dominant bit에 겹쳐 쓰이는 경우, B는 버스 상태가 전송된 비트와 맞지 않는다는 것을 검출합니다. 따라서 노드 B는 전송을 중지시키는 동안, 노드 C는 메시지를 가지고 지속됩니다. 그리고 후에 버스가 노드 C에 의해 released 되면, 이전에 전송을 중지한 노드 B의 전송도 이루어집니다. 이 기능은 ISO 11898 물리 신호 계층의 일부로, CAN 컨트롤러 내에 포함되어 CAN 사용자들이 필수적으로 알아야합니다.