[독서] 아키텍트 이야기

by Blogger 하얀쿠아
2017. 5. 10. 01:13 NULL ptr/ NULL ptr

아키텍트 이야기


지은이 : 야마모토 케이지
출판사 : 인사이트
출판년 : 2007년


나는 10년후에 개발자로 살아남기 위해선 아키텍트가 되어야 된다는 말에 공감이간다.

최고 개발자로서 시스템을 전반적으로 다루며 문제의 근원을 해소하고 프로젝트를 기술적으로 이끌어나가는

이상적인 개발자로서의 모델이 될수 있다. 

아직 현실에서는 그 사람의 능력보다는 이력을 중시 여기지만 

점점 효율과 효과를 중시하는 분위기로 가고 있기때문에 능력을 갖추고 준비해 나간다면 

충분한 가능성이있다. 

아키텍트가 되기위해선 두가지 능력이 선행되어야 한다.. 

소프트웨어의 설계, 프로그래밍 능력이다. 이두가지는 단시간내에 끌어올릴수 있는 능력이 아니다.

많은 프로젝트의 경험과 자기 수양이 뒷받침되어야한다.

그러기 위해선 지금 주어진 일에 안주하지 말고 공격적으로 모든일에 새로운 시도와 

창의적인 생각들을 일속에 주입시킬 필요성이 있다.

어떻게 하면 좀더 개선할수 있을까? 이번에 나온 기술을 어떻게 하면 우리 프로젝트에 적용시켜

좀더 안정되고 효율적인 시스템을 만들수 있을까? 같은 능동적인 행동이 

아키텍처로 가는 지름길이 아닌가 생각해본다.



책의 목록이다.

1. 아키텍쳐의 역활

산출물 목록정의 =>산출물 정의 =>개발표준정의 => 아키텍쳐설계 => 프레임웍구축


2. 아키텍쳐의 주요업무

다양한 템플릿 설계 : 팀원들의 역량에 맞게 용어정의, 개념설계, 상세설계등의 표준화를 준비한다.

그리고 그 지침을 전달하여 개발에 적용되도록한다.


3. 개발 방법론

폭포수 모델, 프로토 타입방법론, RAD, RUP, 익스트림 프로그래밍, 애자일 방법론 등이 있는데 

익스트림프로그래밍은 '최고의 가치를 가장 빠르게' 를 기치로 고객에게 전달하고자 만든 경량화된 방법론이다.

이것은 애자일 방법론의 한 종류이다.


4. 요구사항 분선단계

요구사항에 의해서 아키텍처가 결정되는데 기술사항을 그게 2가지로 나눌수 있다.

기능요구 사항과 비기능요구 사항이다.

기능요구 사항은 비지니스 로직이 되며 , 비기능요구 사항은 보안, 플래폼의 한계,특성 등

눈에 보이지 않는 전문적인 기술을 요구하는 기능들이다.


5. 아키텍처 설계서 목차

 1. 아키텍쳐 개요

   1.1. 시스템개요

   1.2. 미들웨어

   1.3. J2EE

   1.4. 스트럿츠

   1.5. EJB

 2. 서브시스템 분할 방침

 3. 클래스 분할 방침

   3.1. 시스템 내 공통 모듈 추출

   3.2. 배포단위

   3.3. 서브 시스템 내 공통 모듈 추출

 4. 패키징 규칙

   4.1. 시스템 공통 

   4.2. 서브시스템

   4.3. 배포

 5. 코딩규칙

   5.1. 기본규칙

   5.2. 들여쓰기 규칙

   5.3. 명명규칙

   5.4. 범위

   5.5. 주석처리

 6. 예외사항

   6.1. 예외사항 분류

   6.2. 예외사항을 throw 했을경우

   6.3. 예외사항을 catch 했을경우

 7. 로그

   7.1. 로그 출력 형식

   7.2. 로그 출력 수순

 8. DB 접속 프레임워크

   8.1. 주요 컴퍼넌트

   8.2. 애플리케이션의 이용

   8.3. 예외사항 처리



이 댓글을 비밀 댓글로
    • 2017.05.14 21:28
    비밀댓글입니다

기발하고 어려운 구글의 면접시험 문제들

by Blogger 하얀쿠아
2017. 5. 10. 01:02 NULL ptr/ NULL ptr

기발하고 어려운 구글의 면접시험 문제들





미국의 비즈니스 잡지 중 하나인 ‘비즈니스 인사이더(Business Insider)’는 구글의 면접 질문 중 답이 있는 질문들에 대해 모범답안을 제시했다. 

다음은 그 중 일부이다. 
질문의 의도가 무엇이고 면접자의 어떤 능력을 보려고 한 것인지에 대한 설명(☆)과 함께 모범답안(→)을 예시했다.



Q: A나라 사람들은 모두 아들을 극단적으로 선호해서 아들을 가질 때까지 계속해서 아이를 낳습니다. 아들을 가지면 아이 낳기를 중단하고, 딸을 낳으면 아들을 가질 때까지 계속 아이를 낳습니다. 이 나라에서 아들과 딸의 비율은 어떻게 될까요?

☆상당한 논란을 낳을 수 있는 질문입니다. 그러나 논리적 절차에 따라 비율을 계산하면 의외로 간단합니다.

→답은 50대 50으로 같습니다. 가령 이 나라에 1000쌍의 부부가 있고 각각 1명씩 1000명의 아이(아들 500명, 딸 500명)를 낳았다고 합시다. 아들을 가진 부부는 자녀 갖기를 중단할 것이고, 딸 가진 부부는 또 아이를 낳을 겁니다. 자연적 확률에 따라 아들 250명, 딸 250명이 됩니다. 이때 아들의 총수는 750명이고, 딸도 750명입니다. 딸 가진 부부(250쌍)는 또 아이를 가지는데, 아들 125명, 딸 125명을 낳습니다. 이때 아들은 총 875명, 딸도 875명입니다. 이렇게 해서 딸 가진 부부가 계속 아이를 가져도 아들·딸의 비율은 50대 50으로 변화가 없습니다.

Q: 맨홀 뚜껑은 왜 둥글까요?


☆기하학적 지식을 요구하는 문제입니다. 사각형이나 삼각형에 비해 원이 가지는 기하학적 특징이 무엇인지를 맨홀과 연결지어서 생각해야 합니다.

→둥근 맨홀 뚜껑은 절대 맨홀 안으로 떨어지지 않기 때문입니다. 좀 더 자세히 설명하겠습니다. 맨홀 뚜껑 아래에는 이를 받쳐주는 좁은 밑받침(턱)이 있습니다. 그래서 뚜껑이 사각이든 삼각이든 원형이든 평소에는 맨홀 아래로 떨어지지 않습니다. 그러나 맨홀 속으로 들어가기 위해 뚜껑을 열었을 때는? 뚜껑을 수직으로 세운 뒤 방향을 틀어보세요. 사각형이나 삼각형 뚜껑은 짧은 변이 대각선이나 긴 변보다 길이가 짧기 때문에 맨홀 아래로 떨어집니다. 그러나 원은 모든 방향으로 길이가 같기 때문에 어떤 경우에도 아래로 떨어지지 않습니다.
한 가지 이유가 더 있습니다. 원은 평면에 비해 압력에 견디는 힘이 강합니다. 맨홀이 둥근 모양인 것은 양옆에서 가해지는 압박에 잘 견디기 때문입니다. 그래서 맨홀 뚜껑도 원형으로 설계돼 있습니다.


Q: 시계의 시침과 분침은 하루에 몇 번이나 만날까요?


☆차분하게 논리적으로 생각하는 능력을 파악하려는 것입니다. 덜렁대면 착각할 수 있습니다.

→일단 자정에 한번 만납니다. 그리고 오전 1시5분, 2시11분, 3시16분, 4시22분, 5시27분, 6시33분, 7시38분, 8시44분, 9시49분, 10시55분 무렵에 만납니다. 오전 11시 대에는 분침과 시침이 안 만납니다. 오전에 총 11번. 오후에도 동일합니다. 그래서 총 22번 만납니다.

Q: 당신은 해적선 선장입니다. 황금을 어떻게 배분할지에 대한 당신의 안을 놓고 100명의 선원이 투표를 합니다. 과반의 지지를 못 얻으면 당신은 죽어요. 죽지 않으면서 최대한 많은 황금을 차지할 수 있는 안은 무엇인가요?


☆순발력과 함께 투표 행위의 본질적 요소가 무엇인지에 대한 이해가 요구됩니다.

→선원 51명과 황금을 똑같이 나눠 가지는 겁니다. 왜? 과반의 지지를 얻으려면 선원 51%를 내 편으로 만들어야 합니다. 그러려면 황금을 줘야 합니다. 그러나 분배 과정에서 불만이 있으면 안 되죠. 1표가 똑같은 가치인 만큼 황금도 똑같이 나눠야 합니다. 51명 초과의 지지는 배분 몫만 줄이므로 불필요합니다.


Q: 같은 크기의 공이 8개 있는데, 그 중 7개는 무게가 같고 한 개는 더 무거워요. 저울을 두 번만 사용해서 무거운 공을 찾아내세요.


☆논리적인 문제 해결 능력을 측정하는 문제입니다.

→8개의 공 중에서 6개를 임의로 고른 뒤 저울 양쪽에 3개씩 올려놓습니다. 저울이 균형을 이루면 6개의 공은 모두 무게가 같은 겁니다. 남은 2개의 공을 저울로 재서 무거운 공을 찾아내면 됩니다. 반대로 저울이 한쪽으로 기울면, 무거운 쪽 공 3개 중에서 2개를 임의로 골라 저울에 다시 잽니다. 한쪽이 무거우면 그 공이 답이고요, 저울이 균형을 이루면 남은 1개의 공이 무거운 공입니다.

Q: 샌프란시스코 시민들을 한꺼번에 대피시킬 계획을 말해보세요.


☆면접자가 문제에 어떻게 대처하는지 그 태도를 보려는 질문입니다. 대답하려고 끙끙거리기보다는 질문자에게 거꾸로 질문 공세를 펴보세요.

→대피 계획을 세우라고 하셨는데, 도대체 어떤 종류의 재앙에 대한 대피계획을 세워야 하는지 말씀해 주십시오.


Q: 특수 제조한 계란이 2개 있는데, 100층 높이 빌딩의 몇 층에서 떨어뜨려야 깨지는지 알아내려 합니다. 단 2개의 계란만 사용해서 몇 층에서 깨지는지 확실하게 알아내려면 계란을 최소 몇 번 떨어뜨려 봐야 할까요?


☆논리적 계산력과 함께 직관적 해결능력이 필요한, 상당히 난해한 문제입니다. 최소 비용(계란)과 시간(횟수)으로 실험을 하라는 겁니다.

→답은 14번입니다. 1층부터 차례로 계란을 떨어뜨려 보면 몇 층에서 깨지는지 확실히 알 수 있지만, 100층까지 최대 100번을 던져봐야 합니다. 50층에서 실험한 뒤 깨지면 1층부터, 안 깨지면 51층부터 실험하면 실험 횟수를 절반으로 줄일 수 있죠. 같은 식으로 최초에 시작하는 층을 계산해 보면 14층이 가장 효율적입니다. 14층에서 깨지면 1층부터 실험합니다(최대 14회 실험). 안 깨지면 13층 위인 27층에서 다시 실험합니다. 깨지면 15층부터 26층까지 던져보고(이 경우도 최대 14회 실험), 안 깨지면 12층 위인 39층에서 실험을 반복합니다. 계속 같은 실험을 50·60·69·77·80·86·91· 95·98층에서 차례로 실시합니다. 98층에서 안 깨지면 99·100층에서 최종 투척 실험을 합니다. 이 모든 경우 최대 실험 횟수는 14번입니다. 이것이 계란이 몇 층에서 깨지는지를 아는 가장 효율적인 방법입니다.



Q: 8세짜리 조카에게 데이터베이스(database)가 무엇인지 3문장 이내로 설명해 보세요.

☆복잡한 개념을 쉬운 말로 설명하면서, 누구와도 소통할 수 있는 능력을 알아보려는 것입니다.


→데이터베이스는 여러 가지 사물에 대한 많은 정보를 기억할 수 있는 기계란다. 사람들은 이 기계에 많은 정보를 저장한 뒤 필요할 때 꺼내 쓰지. 자, 이제 알았으니 나가서 뛰어놀렴.



이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)

by Blogger 하얀쿠아
2017. 5. 7. 12:36 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서. BOOTP 패킷 형식(BOOTP Packet Format)


위의 BOOTP 특성에서 알아봤듯이, BOOTP에서 정보를 교환한다는 것은 클라이언트가 보낸 요청과 서버가 보내는 답장 쌍을 이루는 것이다.

BOOTP도 일반적인 다른 '요청 / 응답 프로토콜'들과 마찬가지로 요청 및 응답에 사용되는 공통된 메시지 형식을 정의해서 사용하고 있다.


구현하기 나름이겠지만, 일반적으로 클라이언트는 요청메시지의 크기만큼의 메모리 공간을 모두 0으로 초기화 하는 것 부터 시작한다.

그런 다음 이전 항목에서 보았던 것처럼 각각의 메시지 필드를 채운 다음 요청을 서버로 보낸다.


사실 역시 구현하기 나름이겠지만, 일반적으로 서버측은 메세지를 처음부터 다시 작성하지 않고, 클라이언트로 부터 받은 요청을 메모리에 복사하고 특정 필드를 변경하여 응답을 작성한다.

BOOTP 메시지는 상당한 수의 필드를 포함하므로 메시지 형식이 상당히 크다.


UDP 데이터그램 내부의 BOOTP 메세지를 간단히 살펴보자.






IP패킷에 의해 캡슐화 된 UDP데이터그램이 있고,

UDP 데이터그램에 의해 캡슐화 된 BOOTP Message가 있다.



300 바이트, BOOTP Message의 전체 형식은 천천히 살펴보자.

아래 그림과 같다.





Field Name

Size(bytes)

Description

Op

1

Operation Code: 메시지의 타입을 지정함. 1은 요청, 2는 응답

HType

1

Hardware Type: 로컬 네트워크에서 사용하는 하드웨어 유형을 지정한다. ARP 메시지의 HRD필드와 동등한 방식으로 사용된다. 몇가지 공통된 값은 아래와 같다.

1 : Ethernet(10MB)

6 : IEEE 802 Networks

7 : ARCNET

15 : Frame Relay

16 : Asynchronous Transfer Mode(ATM)

17 : HDLC

18 : Fibre Channel

19 : Asynchronous Transfer Mode(ATM)

20 : Serial Line

HLen

1

Hardware Address Length: 이 메시지 내에서 하드웨어 주소의 길이를 지정함. 이더넷 혹은, IEEE 802 MAC 주소를 사용하는 다른 네트워크에서, 이 값은 6임.

이것은 ARP 필드 형식에서 비슷한 이름 (HLN)을 가진 필드와 동일함.

Hops

1

요청을 전달하기 전에 클라이언트에 의해 0으로 설정되고, BOOTP relay agent가 BOOTP 메시지를 포워딩 제어하는데 사용함

XID

4

Transaction Identifier: 클라이언트가 생성한 32비트  식별 값. BOOTP서버에서 받은 응답과 요청을 매칭시키기 위해 사용함.

Secs

2

Seconds: RFC 951에 의하면, 클라이언트는 이 필드에 “클라이언트가 부트를 시도한 시점부터 경과된 초단위 시간 값"을 넣는다. 이것은 BOOTP 서버에 정보를 제공함으로써, 어느것부터 응답해야 할지를 결정하는데 도움을 준다.

불행히도 이 정의는 다소 모호했기에, 전원이 켜진 직후부터의 시간값의 양인지 혹은 첫번째 BOOTREQUEST 메시지가 보내진 이후부터를 의미하는지 명확하지 않았다. 게다가 몇몇 장치는 이 필드를 잘못 구현하기까지 했다. 결론적으로 이 필드는 항상 사용되는 것이 아니다.

Flags

2

Flags: 원래 BOOTP 표준(RFC 951)에서는, 이 필드는 2바이트의 공백이었다.

RFC1542에서는 하나의 flag를 포함하는 ‘flags’ 필드로 변경되었다.

CIAddr

4

Client IP Address: 클라이언트가 계속 사용하려는 현재 IP 주소를 가지고 있으면, 이 필드에 그 원하는 IP 주소를 넣는다. 이 필드를 채우면 클라이언트는이 주소로 전송 된 유니 캐스트 IP 데이터 그램에 응답하기 위해 커밋합니다. 그렇지 않으면 이 필드를 모두 0으로 설정하여 서버에 주소 할당을 원한다는 것을 알려준다.

YIAddr

4

“Your” IP Address: 서버가 클라이언트에 지정하는 IP 주소. 이는 클라이언트가 현재 사용하는 IP 주소와 다를 수 있다.

SIAddr

4

Server IP Address: BOOTREPLY 메시지를 보내는 BOOTP 서버의 IP주소

GIAddr

4

Gateway IP Address: 이 필드는 BOOTP 릴레이 에이전트가 BOOTP 요청의 통신을 용이하게 하고 다른 서브넷이나 네트워크에있는 클라이언트와 서버간에 회신 할 때 BOOTP 메시지를 라우팅하는 데 사용된다. 이름을 이해하려면 "router"에 대한 이전 TCP / IP 용어는 "gateway"입니다. BOOTP 릴레이 에이전트는 일반적으로 라우터이다.

이 필드는 클라이언트가 0으로 설정하고 BOOTREPLY를 처리 할 때 클라이언트가 무시해야 한다. 이것은 특히 일반적인 IP 라우팅 용도로 사용될 기본 라우터 주소의 주소를 클라이언트에 제공하는 서버를 나타내지는 않는다.

CHAddr

16

Client Hardware Address: BOOTREPLY를 보내는 클라이언트의 L2 계층 하드웨어 주소. 장치의 할당 된 IP 주소를 검색하고 응답 메시지를 전달하는 데 사용된다.

SName

64

Server Name: BOOTREPLY를 보내는 서버는 이 필드에 서버이름을 지정하거나 지정하지 않을 수 있다. 이것은 간단한 텍스트로 "nickname"와 같은 게 될 수도 있고, 아니면 완전한 DNS 도메인 이름 (예 : "myserver.organization.org") 이 될 수도 있다.

클라이언트는 요청을 만들때, 이 필드값을 지정할 수 있다. 만약 지정한다면, 그것은 이 이름을 가진 BOOTP서버로부터만 응답을 원한다는 의미이다. 이것은 클라이언트가 한 서버에만 저장된 특정 부트 파일에 액세스 할 수 있도록하기 위해 수행 될 수 있다.

File

128

Boot Filename: 부트스트랩 과정을 완료하기 위해 클라이언트가 다운로드 받을 수 있는 부트 파일의 전체 디렉토리 경로와 파일이름을 포함하는 필드. 클라이언트는 여기에 텍스트로 설명을 입력하여 특정 유형의 파일을 요청할 수 있다. 혹은 이 필드를 공백으로 남겨두고, 서버가 기본 파일의 이름을 제공하게 할 수 있다.

Vend

64

Vendor-Specific Area: 원래는 제조사(공급업체)로 하여금 BOOTP를 다른 유형의 하드웨어 요구에 맞게 수정할 수 있도록 허용하는 필드다. 이 필드는 지금은 제조사 독립적인 설정 정보를 보관하는데에도 사용한다.



앞서 언급했지만, BOOTP 서버/클라이언트의 양측의 요청 및 응답 메세지는 UDP 메시지로 캡슐화되어 전송된다.

BOOTP 표준(rfc951)에서는 UDP checksum 사용을 'optional'로 정의하고 있다.

UDP checksum을 사용하면 데이터 무결성 오류를 방지 할 수 있으므로 권장된다.

그러나 이 기능은 종종 아주간단히 구현된 클라이언트 측에서는 받아 들일 수없는 처리 요구를 유발할 수도 있기때문에, checksum을 합법적으로 생략할 수도 있다.


참고로, 간결함을 위해, BOOTP는 메세지 패킷이 분할(fragmented) 되지 않는다고 가정한다.

이를통해 BOOTP 클라이언트는 분할된 메세지를 모으고, 시퀀스 넘버순서대로 다시 합치는 복잡한 과정을 피할수 있다.

패킷의 분할을 지원하지 않으면, 각 레이어 별로 길이가 초과되는 경우에 어떻게 처리되어야 하는가 고민이 생길수도 있다. 

하지만, BOOTP메세지는 모든 TCP/IP연결에서 요구되는 최소 MTU보다도 작은, 겨우 300바이트 길이이기 때문에, 일반적으로 이는 문제가 되지 않는다.




이 댓글을 비밀 댓글로

[네트워크/프로토콜] BOOTP 에 대해서. BOOTP 클라이언트/서버의 메세지전송과 주소설정 방법

by Blogger 하얀쿠아
2017. 5. 7. 11:57 소프트웨어 Note/Embedded Linux

BOOTP 에 대해서: BOOTP 클라이언트/서버의 메세지전송과 주소설정

BOOTP는 다양한 장치에 사용할 수 있지만, 최초 개발의 주된 동기 중 하나는 저장 장치가 없는 "멍청한"장치를 자동으로 구성하는 방법을 제공하는 것이었다.

대부분 이러한 멍청한 장치들은, 비교적 제한된 기능만을 가지고 있기때문에, 근사한 부팅 프로토콜을 지원하도록 요구하는 것은 사실 말이 되지않았다.

따라서 BOOTP는 복잡한 개념이나 근사한 개념 혹은 근사한 구현 요구사항 없이, 호스트 구성을 수행하는 복잡하지 않은 프로토콜이다.



BOOTP 클라이언트 및 서버

다른 많은 TCP / IP 프로토콜과 마찬가지로 BOOTP는 실제로 클라이언트 / 서버이다.
프로토콜의 작동은 BOOTP 클라이언트와 BOOTP 서버 간의 단일 메시지 교환으로 구성된다.

BOOTP 클라이언트는 구성해야하는 모든 유형의 장치가 될 수 있다.
BOOTP 서버는 BOOTP 클라이언트 요청에 응답하도록 특별히 설정된 네트워크 장치이며, 주소 지정 및 필요한 경우 클라이언트에 제공 할 수 있는 기타 정보로 프로그램이 구현된다.

BOOTP 서버는 서비스를 제공하는 클라이언트에 대한 특별한 정보 집합을 유지 관리한다.
여기에서 하나의 핵심 부분은 테이블이다.
이 테이블은 각 클라이언트의 하드웨어 (Layer 2, 데이터 링크 계층) 주소, 즉 MAC주소를 해당 장치에 할당 하고자 하는 IP 주소로 매핑하는 테이블이다.

클라이언트는 요청에서 하드웨어 주소를 지정하고, 서버는 이 주소를 사용하여 클라이언트의 IP 주소를 찾아서 클라이언트로 응답한다.
물론, 구현하기에 따라 다르고, 다른 기술도 사용할 수도 있겠지만, 매핑 테이블이 가장 일반적인 구현방법이다.


메시지 및 전송

그런데, BOOTP 메시징은 몇 가지 이유로인해, 계층 4 전송 프로토콜로 TCP가 아닌 UDP (User Datagram Protocol)를 사용한다. 

첫째, UDP는 다른 레이어 4 전송 프로토콜인 TCP보다 훨씬 덜 복잡하며, BOOTP와 같은 간단한 "요청 / 응답"프로토콜에 이상적이다.

둘째, 클라이언트가 분명히 BOOTP 서버의 주소를 알지 못하기 때문에 요청은 로컬 네트워크에서 브로드 캐스팅되야 한다.
UDP는 브로드 캐스트를 지원하지만 TCP는 브로드 캐스트를 지원하지 않는다.
BOOTP를 공부하는 정도라면 여러분들은 이미 알고 있을 것이다.

UDP는 BOOTP 서버에 대해 잘 알려진 (예약 된) 포트 번호 인 UDP 포트 67을 사용한다.
BOOTP 서버는 클라이언트가 보낸 이러한 브로드 캐스트 BOOTP 요청에 대해 포트 67에서 "수신 대기"한다.
요청을 처리 한 후 서버는 클라이언트에게 응답을 보낸다.
이 처리 방법은 클라이언트가 자체 주소를 알고 있는지 여부에 따라 다르다.


◎ 클라이언트가 주소를 알고 있는 경우
BOOTP 클라이언트가 이미 자신의 주소를 알고있는 경우가 있다. 이 경우는, BOOTP 서버가 이 주소를 직접 응답을 다시 보낼 때 사용할 수 있다.


◎ 클라이언트는 자신의 주소를 모르는 경우
물론 BOOTP는 주소를 모르는 클라이언트에게 IP 주소를 제공하기 위해 흔히 사용 된다. 
이것은 종종 "닭고기와 계란"문제라고 불리는데, 그 이유는 "닭고기와 계란"이라는 오래된 수수께끼와 같은 종류의 "고리"를 나타내기 때문이다.
이 딜레마를 해결하기 위해 BOOTP 서버에는 두 가지 선택지가 있다.
운영체제가 이를 지원하면 서버는 클라이언트의 하드웨어 주소를 사용하여 장치에 대한 ARP 항목을 만든 다음 레이어 2 유니 캐스트를 사용하여 응답을 전달할 수 있다.
그렇지 않으면 회신을 로컬 네트워크에서 브로드 캐스트로 전송해야한다.



브로드 캐스트 및 포트 사용

BOOTP 서버가 클라이언트로 다시 브로드캐스트 해야한다는 사실은 대부분의 TCP/IP 프로토콜이 클라이언트 포트를 사용하는 방식에서 약간의 변화가 필요하다.
일반적으로 클라이언트/서버 트랜잭션에 UDP 또는 TCP를 사용하는 클라이언트는 임시 또는 잠시사용하기 위한 포트 번호를 생성하여 요청메세지의 소스포트로 사용한다.

서버는 그 임시 포트 번호를 사용하여 클라이언트의 IP 주소로 응답을 보낸다.
임시 포트 번호는 특정 IP 주소에 대해 고유해야하지만, 네트워크의 모든 장치에서 고유하지는 않는다.

이해하기 쉽게 한가지 예를 들어 보면, 이런것이다.
하나의 네트워크상에 두 장치 A, B가 있다.
장치 A는 웹 서버에 대한 HTTP 요청에 임시 포트 번호 1248을 사용하고, 장치 B는 TCP/IP 스택에서 포트 번호 1248을 사용하여 DNS 요청을 보낼 수 있다.
서로다른 장치가, 동일한 네트워크상에 있다 하더라도, 동일한 포트 1248을 사용할 수 있다는 것이다.

BOOTP의 서버가 브로드캐스트이기 때문에 유니캐스트 전송을 사용하는 특정 장치를 대상으로하지 않는다.
즉, 일시적인 포트 번호로 안전하게 보낼 수 없다는 것을 의미한다.

네트워크상의 다른 장치는 다른 트랜잭션에 대해 동일한 임시 포트 번호를 선택했을 수 있으며 BOOTP 서버의 응답을 실수로 자기에게 보낸것으로 오인 할 수 있다.
이 문제를 피하기 위해 잘 알려진 다른 포트 번호가 BOOTP 클라이언트에만 사용된다.
UDP 포트 68 이 바로 그것이다.

클라이언트는 브로드캐스트 또는 유니캐스트 전송을 위해서 이 포트에서 수신 대기하지만, BOOTP 요청을 보낸적이 없는 클라이언트는 무시할 것이다. 
이 "이중 브로드 캐스트"BOOTP 통신 프로세스는 아래 그림에 나와 있으니 참고하자.

General Operation Of the Boot Protocol

이 그림을 간단히 설명하겠다.

장치 A는 IP 주소 및 기타 매개 변수를 확인하려고 시도하고 있다.

UDP 포트 67을 사용하여 로컬 네트워크에서 BOOTP 요청을 브로드캐스트 한 다음 포트 68에서 응답을 수신한다.

장치 D는 BOOTP 서버로 구성되어있고, 67 포트에서 수신 대기한다.

요청을 받으면 포트 68에서 A에게 IP 주소가 무엇인지 알려주는 브로드캐스트를 보낸다.

BOOTP는 브로드 캐스트를 사용하여 할당 된 IP 주소가없는 장치와의 통신을 허용하는 비교적 간단한 클라이언트/서버 프로토콜임을 생각하면 매우 간단한 과정이다.



세줄 요약 주요 개념

  1. BOOTP 클라이언트는 브로드 캐스트를 사용하여 청취 BOOTP 서버에 요청을 보낸다.
  2. 대부분의 경우 BOOTP 클라이언트 장치는 프로토콜을 사용할 때 자체 IP 주소를 알지 못한다. 
  3. 이런 이유 때문에 BOOTP 서버는 일반적으로 응답을 전송할 때 브로드 캐스트를 사용하여 클라이언트에 도달하는지 확인한다.

손실 된 메시지의 재전송

BOOTP 메시지 전송을 단순하게 하기위해 UDP를 사용할때의 단점은 전송 품질을 보장할 수 없다는 것이다.

UDP특성을 이미 알고 있겠지만, UDP는 신뢰할 수 없다.

즉, BOOTP 클라이언트로부터 전송된 요청메세지가 서버에 도착하기 전에 손실될수도 있고, 운좋게 서버에 도착했더라도, 클라이언트 방향으로 전송된 서버의 응답 메세지가  도착하지 않을 수 있다. 



이쯤 읽으면 '응? 장난하냐??' 하는 생각이 들겠지만, 진정하고 계속 읽어보자.

BOOTP는 이에대한 대비책을 가지고 있다.



UDP를 사용하는 다른 프로토콜과 마찬가지로 BOOTP 클라이언트도 재전송 타이머를 사용하여이 문제를 처리한다.

클라이언트가 일정 기간 후에 응답을받지 못하면 클라이언트는 요청을 다시 보낸다.


그러나 BOOTP 클라이언트는 재전송 전략을 구현하는 방법에 주의를 기울여야 한다.

한가지 문제시나리오를 가정해보자.
200대의 BOOTP 클라이언트가 있는 네트워크에서, 200대의 모든 클라이언트 전원이 꺼진다고 가정하겠다.
이 기계들은 거의 모두 비슷하게(심지어 동일하게) BOOTP가 구현되었을 것이기 때문에 전원이 다시 켜지면, 모두 재시작되며 거의 동시에 BOOTP 요청을 보내려고 할것이다.
왜? 구현이 동일하니깐.

대부분 이러한 문제로 인해 문제가 발생할 수 있다.
BOOTP 요청 메세지 일부가 손실되기도 할것이고, 심지어 서버가 과부하로 인해 일부 메세지를 drop해야 할 수도 있다. 
서버의 패킷큐 overflow 등의 이유가 예상된다.

그런데 모든 클라이언트는 전송을 실패했으므로 재전송을 하려 할 것이다.
이때, 각각의 클라이언트가 재전송을 위해 동일한 시간을 기다렸다가 재전송을 하게된다면?
그 시간이 지나면 모든 기계가 요청을 다시 보낼것이므로, 동일한 문제를 반복하게 될것이다. ...야 이 멍청이들아!!??

이와 같은 상황을 회피하기 위해 BOOTP 표준에서는 재전송주기 시간 값을 4 초부터 시작해서, 연속 시도를 위해 이 값을 지수적인 증가, 즉 두 배로 증가, 시키는 백 오프(Back-off) 방식을 사용할 것을 권장한다.
재전송을 위해서 말이다.
또한, 여러대의 BOOTP 클라이언트가 동시에 재전송을 하는 중첩 상황을 피할 수 있게 임의성 요소가 추가된다.
이 아이디어는 이더넷(ethernet)에서 사용되는 백 오프 방법과 매우 유사하다. 실제로 BOOTP 표준은 이더넷의 사양서(Specification)를 참조한다.

예를 들어, 첫 번째 재전송은 0에서 4 초 사이의 임의의 시간 간격 후에 발생시킨다. (임의의 양을 더하거나 뺀 값). 
필요한 경우 두 번째 재전송에서는, 0과 8 초 사이의 임의의 시간 간격에서 플러스 또는 마이너스 하는 등...
이렇게하면 재전송이 손실되는 가능성을 줄이는 데 도움이 되며, BOOTP의 과도한 트래픽으로 인해 네트워크가 중단되지 않도록 할 수 있다.




이 댓글을 비밀 댓글로

[칼럼] 삼성전자 홍준성 상무는 왜 구글로 갔을까?

by Blogger 하얀쿠아
2017. 4. 30. 02:26 NULL ptr/ NULL ptr

2009년 12월 16일.

삼성전자에서는 임원 승진발표가 있었다. 총 승진한 삼성전자 임원은 177명이었다. 그중엔 만 40세의 나이로 최연소 상무로 발탁된 사람이 있었다. 
바로, 당시 수석연구원(부장 급)이었던 '홍준성'님이다.
홍준성 상무는 당시 1969년생. 승진 임원 대상 177명 중 가장 나이가 어렸다.
그는 무엇을 했길래 삼성전자라는 거대 기업안에서 수많은 어르신들을 제치고 최연소 임원이 될수 있었을까?



그는 무선사업부 - 모바일솔루션센터(이하 MSC)에서 Realtime Kernel기반의 모바일 운영체제 ‘바다(Bada)’를 개발한 주역이었다. 
홍준성 상무는 '바다(Bada)'를 개발한 공로를 인정받아 2009년 자랑스런 삼성인상(기술상)을 받았다. 실제로 '바다(Bada)'를 운영체제로 사용하는 스마트폰, '웨이브' 시리즈를 출시도 했으며, 당시 전세계 스마트폰 운영체제의 약 2%정도의 점유율을 가지고 있었다.


삼성전자에서 바다 플랫폼을 기반으로 출시했던 스마트폰, 삼성 웨이브 3삼성전자에서 바다 플랫폼을 기반으로 출시했던 스마트폰, 삼성 웨이브 3





이처럼 삼성전자내에서 S급 인재로 통했던 그는 2015년 10월, 돌연 구글코리아로 이직한다.
구글코리아 엔지니어링 총괄사장이라는 직책을 받고.
구글은 그의 영입을 비밀리에 추진했으며 영입 후에도 공식 발표조차 제대로 하지 않았었다.


하지만 알만한 사람은 다 알고 있었다.
삼성전자의 내부개발자들 사이에선 구글측이 삼성측의 손꼽히는 핵심 개발자를 구글의 한국법인 수장으로써 데려갔다는 이야기가 돌았다.




삼성전자는 구글도 탐내는 소프트웨어 개발자(홍준성)를 보유하고 있었지만, 끝까지 끌어안고 가지도 못했고, 지켜내지도 못했다. 

촉망받는 소프트웨어 개발자이자 삼성전자 임원이었던 그는 왜 구글코리아로 간 것일까?

이를 알고자 한다면, 우린 삼성전자가 소프트웨어 인력을 얼마나 지켜주려 했고, 그들에게 어떤 대우했는지를 이해할 필요가있다. 


대체 뭐가 문제였을까?

2008년 삼성전자가 무선사업부의 '소프트웨어 역량 강화'를 표방하며설립한 MSC라는 조직의 탄생 ~ 소멸과정을 살펴보면 된다.


당시, 무선사업부 내에서 MSC의 의사결정은 하드웨어 부문의 의사결정에 번번이 밀렸다고 한다.

예를들어 하나의 신규 스마트폰 모델을 만든다고 가정해보자. 해당 스마트폰의 부품 재고 및 수급에 따라 하드웨어  스펙이 수시로 바뀌는 상황이 발생할 수 있다. 


그래, 충분히 그럴수 있다. 
그런데, 이 하드웨어가 바뀌면 그 안에서 동작하는 소프트웨어도 필연적으로 어떤 변경이 발생해야 할 때가 있다. 

이런 경우다. 당초 계획했던 스마트폰 디스플레이 크기가, 사정에 의해(경쟁모델 따라잡기를위한)증대하거나, (단가 낮추기를 위한)축소가 필요 하면, 앱의 소프트웨어 코드도 그에 맞춰 다시 수정해야 한다. 

좀더 자세히 예를 또 들어보자. GPS, Wi-Fi, Bluetooth와 같은 radio chip의 제조사가 달라지거나, 제조사는 다행이 동일하더라도 단가문제로 모델이 달라지면, 그에따라 driver도 달라지게 될 것이다.

driver가 달라진다는 것은 무슨의미인가 ? 

Platform layer에서 제공하는 API 및 framework부터 궁합이 잘 맞는지(기대한 대록, 혹은 의도한대로 동작이 잘 되는지)를 검증하는 과정을 거쳐야 한다.

 이 검증과정에서 문제가 발생하면 원인을 규명해야 하고(driver가 문제인지, chip의 firmware가 문제인지, 혹은 Platform의 API로직 이나 Framework로직이 문제인지 찾는 과정이 필요하다), 규명이 끝나면 수정이 가능한지 검토한 후 수정패치를 만들어 적용 해야 한다.


자, 이렇게 뭔가 Hardware가 변경되려면 Software도 시간이 필요하다. 이건 상식이다. 뭔가 달라졌으니, 그에 맞춰 함께 달라지려면, 달라진 점을 파악하고 어떻게 맞춰서 수정이 가해져야 하는지 파악해야 하니깐. 당연히 시간이 필요하지.


그렇지만 삼성전자의 높으신 분들은 소프트웨어는 알아서 맞추라는 지시를 내린다.. 추가적인 일정을 주지 않고, 기존일정대로 진행하라신다.

이게 소프트웨어 푸대접이 아니면 뭐란 말인가.

오늘날 소프트웨어는 서비스 형태로 출시하고, 사용자와 소통하며 보완 및 발전시켜야 하는데, 삼성전자의 경영진은 Hardware처럼 완제품같은 Software를 뚝딱 만들어주길 바란 것 같다.


또, 이건 삼성Android Flagship 스마트폰에 대한 얘기이지만...

거대 사업자가 되버린 구글의 압력(참고로 유럽연합에서는 구글에 대한 조사를 마쳤고 독점 행위로 결론냈다고 전해진다)으로인해 개발단계에서 스마트폰 갤럭시에 탑재도 해보지 못한채 중도하차된 삼성의 앱이 많다고 한다. 삼성전자는 구글의 압력이 들어올 때마다 대체제가 없어(삼성만의 모바일 운영체제가 없이 Android를 사용하는 상황) 구글의 압력에 굴복할수 밖에 없었던 것 같다.


앞서 언급한 홍준성 前 삼성전자 상무의 사례가 대표적이다.

그가 총괄했던 ‘바다 OS’ 개발 프로젝트는 한창 진행중이었지만, 삼성전자의 높으신 분들의 의사결정에 의해 강제 종료됐고, 심지어 2014년에는 그가 속했던 무선사업부의 'MSC'라는 조직 자체는 공중 분해됐다. 

이런 상황에서 그가 방황하고 고민했던 건 어쩌면 당연한 일인지 모른다. 

한 뉴스기사. 삼성전자, 10개 해외조직 대폭 개편 모바일솔루션센터 분산·재배치 글로벌 B2B사업조직 확대 조정


그를 잘 아는 한 관계자는 “구글은 삼성전자와 평소 모바일 부문에서 협력을 많이 해왔기 때문에 그를 가까이서 보아왔고, 그의 실력 역시도 잘 파악하고 있었다”고 말했다고 한다.

MSC는 ‘삼성도 OS를 만들어보자’ ‘플랫폼을 만들어보자’라는 비전을 꿈꿨던 조직이다.

삼성전자는 불과 설립 5년 남짓만에 실현 가능성 없다며 MSC를 정리했고, 그 여파로 지금도 삼성전자의 고급 소프트웨어 엔지니어들의 이탈은 계속 되고 있다고 한다.

MSC의 수뇌부였던 한 관계자는 “삼성이 좋은 비전을 내세워 좋은 인재들을 MSC에 끌어왔는데 한번에 조직을 해체했다”면서 “삼성이 10년 아니 100년 내에 소프트웨어 인재를 다시 뽑을 수 있을 지 모르겠다. 잃어버린 믿음을 다시 세우는 데 얼마나 오랜 세월이 걸릴 것인가”라며 한탄했다고.


미래의 먹거리산업인 자동차, 가전, 모든 전자기기가 소프트웨어 기반이 될 것이라는 사실은 자명한 일이다. 


이상 삼성전자의 MSC 운영과 해체 과정을 통해 '삼성전자는 왜 소프트웨어 부문의 경쟁력이 구글에 비해 떨어지는가'에 대한 수많은 힌트를 엿볼 수 있었다.






이 댓글을 비밀 댓글로

[C#] C#.net에서의 시리얼통신 기초

by Blogger 하얀쿠아
2017. 4. 18. 23:15 소프트웨어 Note/C#

C#.net에서의 시리얼통신 기초


C#은 시리얼 통신에 대한 모든것을 개발자가 구현할 필요 없이 매우 쉽고 간단하게 사용할 수 있는 객체를 지원한다. 
그것은 System.IO.Port namespace에 포함되어있는 System.IO.Ports.SerialPort 인데, Visual Basic 6.0 에서 지원하던 Comm 컨트롤과 매우 유사해 사용은 간단했다.

참고로 이 글은 .net framework 3.5 기준으로 작성됐다.






객체 생성

SerialPort 객체를 Form에 끌어넣어주면 된다.
SerialPort 객체는 Device Components 에 있다. 
아래 그림을 참고하자.


또한, 아래와 같이 namespace 추가가 되었는지 코드를 확인해보고, 안되어있다면 추가하도록 한다.

using System.IO.Ports;


초기화

사용하고자 하는 포트의 번호와, BaudRate(나는 보통 '보 레이트' 라고 읽는다)를 설정하는 것이 Serial통신의 시작이다.

SerialPort.PortName 속성은 COM1, COM2 등 몇번 COM port를 사용할지 설정하면 된다.
SerialPort.BaudRate 속성은 통신 속도를 설정한다.
일반적인 경우 이 두가지만 설정하면 된다.

아래 코드를 참고하자.

SerialPort SP = new SerialPort();

SP.PortName = "COM1";
SP.BaudRate = (int)38400;
SP.DataBits = (int)8;
SP.Parity = Parity.None;
SP.StopBits = StopBits.One;
SP.ReadTimeout = (int)500;
SP.WriteTimeout = (int)500;

Baud rate, Stop bits, Data bits등 시리얼 통신을 위한 여러 설정들은 위와 같은 방법으로 정의할 수 있다.
위 예에서 적용된 설정들은 이 설정들을 적용하지 않았을 경우 default값으로 적용되는 값들이다.

한가지 팁을 드리자면, 실제 사용 가능한 시리얼 포트가 몇번인지 확인하는 방법은 아래와 같다.
SerialPort.GetPortNames() 라는 method가 있는데, 이를 사용하면 사용가능한 모든 port의 이름목록을 얻어 올 수 있다.
이후 foreach문을 사용하면 모든 사용 가능한(물리적으로) 시리얼 포트를 찾을 수 있다.

foreach (string comport in SerialPort.GetPortNames())
{
    //각각의 'comport'는 사용가능한 포트이름이다.
    //이것을 리스트뷰나 콤보박스에 추가해서 디스플레이 해주는 등의 처리 코드를 넣는다.
}

Parity로 사용할 수 있는 값
  • EVEN
  • MARK
  • NONE
  • ODD
  • SPACE

Stop Bits로 사용할 수 있는 값
  • None
  • One
  • OnePointFive
  • Two
 

Port 열고 닫기


여기까지 설정이 끝났다면 단순히 Open() 메소드를 사용하여 적용된 설정과 함께 포트를 열 수 있다.
2개의 method만 기억하면 된다. Open( )과 Close( )가 그것이다.
SerialPort.Open(), SerialPort.Close() method를 이용해 포트를 열고 닫아주면 된다.
또한 필요한 Exception에 대한 핸들링도 주로 이곳에서 하게 된다.

코드를 작성하다 보면 종종 Open( )이 잘 됐는지, 혹은 아직 Open안된 상태인지 확인을 해야 할 때가 있다.
이를 판단하기위한 속성값이 있는데, SerialPort.IsOpen 이다.
이 IsOpen 속성을 이용하여 포트가 정상적으로 열렸는지 확인 할 수 있다.

SP.Open();

if (SP.IsOpen)
{   
   // 포트 오픈 성공
}
else
{
   // 포트 오픈 실패.
}


데이터 전송 및 수신

데이터 전송은 간단하다. 
'txtSend' 라는 텍스트 박스가 있다고 가정하자.
이 txtSend 에 입력되어있는 값을 전송하려면 다음과 같은 코드 한줄이면 된다.

SP.Write(txtSend.Text);

혹은 아래와 같이 Line단위로 처리하는 method도 사용가능하다.

SP.WriteLine("It’s a test.");
SP.ReadLine();

Read작업의 경우 ReadByte, ReadChar, ReadExisting, ReadLine 중 필요한 메소드를 골라서 사용하면 된다.
Win32에서 Read작업의 경우 쓰레드를 만들고 이벤트를 감시하여 해당 이벤트(시리얼로 데이터가 들어오는)가 발생하면 특정 루틴으로 넘겨주는 방법을 사용했는데, 닷넷에서도 마찬가지의 방법을 사용한다.
SerialPort가 데이터를 받으면 다음과 같은 event handler 가 호출된다.

private void SP_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)

하지만 SerialPort로 받아온 데이터를 읽어올 때 주의사항이 있다.
DataReceived 이벤트 핸들러에서 main thread의 resource에 곧바로 접근했다가는 thread exception을 접하게 된다.
이것을 해결하는 방법을 간단히 다루는것이 이 C#을 이용한 시리얼 통신에 대한 글의 목표이다.


그리고 SerialPort.ReadExisting() 를 호출하면 SerialPort 객체의 버퍼에 남아있는 데이터들을 모두 읽어오게 된다.
하지만 이 데이터들을 main form 의 ListBox 에 넣으려고 하는 순간 exception이 발생했다.
MSDN 을 검색해 보면 다음과 같은 설명이 나와있다.
굵은 부분이 핵심이다.

The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. 
Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. 
If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.


요약하면 SerialPort객체를 통해 호출되는 DataReceived 이벤트 핸들러는 secondary thread이고, main form 은 main thread이다. 
즉, 서로 다른 thread 이다. 
그런데 Serial Port 의 thread 에서 main form 의 thread 의 객체를 modify 하려고 하기 때문에 발생하는 문제이다.

이 문제를 해결하기 위해서 secondary thread인 SerialPort_DataReceived() event는 main thread의 event handler를 invoke 하도록 했다.
main thread에서 invoke되는 event handler에서는 SerialPort 를 통해 받은 데이터를 이용해 main form을 수정한다.

private void SP_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
    this.Invoke(new EventHandler(SerialReceived));
}


즉, SerialPort 가 데이터를 받아올 때마다 main form 에서 SerialReceived() event handler가 호출되며, 이 event handler에서 main form 의 객체를 조작하게 된다.
이로써 thread exception 이 일어나는 문제가 해결된다.

private void SerialReceived(object s, EventArgs e)
{
    String strReceive = SP.ReadExisting();
    listReceive.Items.Add(strReceive);
}


데이터 패킷화


public static void SetPacket(uint uCommand, uint uData , ref byte[] btBuf, ref uint uLen)
{
BitConverter.GetBytes(STARTCODE).CopyTo(btBuf, uLen);
uLen += sizeof(uint);

BitConverter.GetBytes(SESSIONNO_UNKNOWN).CopyTo(btBuf, uLen);
uLen += sizeof(uint);

const uint DATALENGTH = sizeof(uint) + sizeof(uint);     //CMD + DATA length
//btBuf.SetValue(DATALENGTH, sizeof(uint) + uLen);
BitConverter.GetBytes(DATALENGTH).CopyTo(btBuf, uLen);
uLen += sizeof(uint);

BitConverter.GetBytes(uCommand).CopyTo(btBuf, uLen);
uLen += sizeof(uint);

BitConverter.GetBytes(uData).CopyTo(btBuf, uLen);
uLen += sizeof(uint);

BitConverter.GetBytes(ENDCODE).CopyTo(btBuf, uLen);
uLen += sizeof(uint);
}


부록

아래 그림은 시리얼통신용으로 사용하는 D-SUB 커넥터를 캐드로 그린것이다.
자주 사용하는 TXD, RXD, GND 를 표시해놓은 그림이다. 
종종 시리얼통신을 사용할 때마다 핀 배열이 헷갈릴 때가 있는데, 그때마다 찾아보는 그림이다.






이 댓글을 비밀 댓글로
    • 2017.02.15 17:09
    비밀댓글입니다

[GPS 이야기] TTFF와 Almanac, Ephemeris 그리고, GPS의 start 방식, Cold start/Hot start/Warm Start ?

by Blogger 하얀쿠아
2017. 4. 13. 22:45 하드웨어 Note/GPS 이야기



여기서는 GPS에 대해 이야기를 해볼까 합니다.

GPS는 Global Positioning System의 약자인 것은 널리 알려진 내용인데요.


오늘은 GPS의 이야기를 시작하기에 앞서, 몇가지 용어를 알아볼까 해요.



TTFF

TTFF(Time To First Fix)란 GPS 수신기의 전원을 켰을 때 GPS 수신기가 현재 위치를 파악하는 데까지 소요되는 시간을 뜻하며, 상황에 따라 Factory Start, Cold Start, Warm Start, Hot Start로 구분됩니다.

TTFF를 이해하기 위해서는 먼저 Almanac 데이터와 Ephemeris 데이터에 대하여 이해할 필요가 있습니다.

지상의 여러 부 관제국에서 GPS 위성신호를 항시 관측하여 그 데이터를 주 관제국으로 보내고, 주 관제국에서는 그 데이터를 토대로 Almanac 데이터와 Ephemeris 데이터를 작성하여 일정주기로 각 GPS 위성으로 보내며, 이는 다시 GPS 위성신호 중 항법 메시지에 포함되어 지상의 각 GPS 수신기로 송신됩니다.

 

Almanac 데이터

Almanac 데이터는 GPS 위성배치의 개략적인 궤도 파리미터 정보이며, 몇달에 한번씩 갱신됩니다.

GPS 수신기는 Almanac 데이터를 통해 특정 시각의 특정 지점에서 어떤 위성들의 신호를 수신할 수 있는지 미리 파악할 수 있기 때문에 보다 신속하게 자기 위치를 계산할 수 있습니다.

각 위성별로 모든 위성의 Almanac 데이터를 2분 30초 동안에 전송완료 하며, 지속적으로 이를 재전송합니다.

GPS 수신기가 Almanac 데이터를 가지고 있지 않으면 데이터 전체를 수신하며, Almanac 데이터를 가지고 있되 일부가 최신 데이터가 아니면 해당 부분만 수신합니다.

 

Ephemeris 데이터

Ephemeris 데이터는 GPS 위성의 아주 정교한 궤도 및 시각보정 정보이며, 매 5시간마다 새로이 갱신됩니다.

GPS 수신기는 Ephemeris 데이터를 통해 정밀하게 자기 위치를 파악할 수 있습니다.

각 위성별로 해당 위성의 Ephemeris 데이터를 30초 동안에 전송완료 하며, 지속적으로 이를 재전송합니다.

GPS 수신기가 특정 위성의 가장 최신의 Ephemeris 데이터를 가지고 있지 않으면 해당 위성의 가장 최신의 데이터 전체를 수신하는데, GPS 수신기의 전원을 켰을 때 Ephemeris 데이터의 중간부터 수신하기 시작하였다면 다음번 전송 주기에 처음부터 끝까지 전체를 수신하며, 수신과정에서 일시적으로 수신이 끊어진 경우에도 다음번 전송 주기에 다시 전체를 수신합니다.

 

 

GPS 수신기는 최신의 Almanac 데이터를 통해 어떤 위성들의 신호를 수신할 수 있는지 미리 파악하고, 최신의 Ephemeris 데이터를 수신한 위성들 중 한 위성으로부터 신호를 받아 위성들과의 시각동기를 이루고, 다른 2개 이상의 위성들로부터 신호를 받아 각 위성들까지의 거리를 측정하여 자기 위치를 파악하는 것입니다. 이 때, 2개 위성에 대하여 거리를 측정하면 지구타원체(WGS84)상의 경위도 좌표값만 구할 수 있고, 3개 이상의 위성에 대하여 거리를 측정하면 지구타원체(WGS84)상의 경위도 좌표값 및 타원체고를 구할 수 있으며, 이 타원체고는 표준 지오이드 모델을 바탕으로 해발고로 환산되어 표현됩니다.

TTFF는 Almanac 데이터와 Ephemeris 데이터의 수신 여부에 따라 Factory Start, Cold Start, Warm Start, Hot Start로 구분할 수 있습니다.


 

Factory Start

Factory Start는 전원을 켠 후, 위성신호로부터 Almanac 데이터 전체와 신호가 수신되는 위성 중 최소 3개 이상의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 15분 정도입니다.

GPS 수신기가 공장에서 출고될 때에는 특정 시점의 Almanac 데이터 전체와 각 위성의 Ephemeris 데이터 전체가 입력되어 있습니다.

GPS 수신기를 그 시점보다 수개월이 지난 시점에 처음 사용하거나 사용했던 GPS 수신기를 끈 후, 수개월간 사용하지 않다가 다시 사용하는 경우가 이에 해당됩니다.


 

Cold Start

Cold Start는 전원을 켠 후, 위성신호로부터 Almanac 데이터 일부와 신호가 수신되는 위성 중 최소 3개 이상의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 30초에서 1분 30초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수십일 동안 사용하지 않다가 다시 사용하는 경우가 이에 해당됩니다.


 

Warm Start

Warm Start는 전원을 켠 후, 신호가 수신되는 위성 중 1~2개의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 10초에서 40초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수시간 이내 다시 사용하는 경우가 이에 해당됩니다.

* 참고 : Cold Start는 신호가 수신되는 위성들 중 대다수가 Ephemeris 데이터의 갱신이 있었던 경우이고, Warm Start는 신호가 수신되는 위성들 중 일부만 Ephemeris 데이터의 갱신이 있었던 경우입니다.



Hot Start

Hot Start는 새로운 데이터의 수신없이 위치를 파악하는 데 소요되는 시간으로 대략 3초에서 20초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수분 이내 다시 사용하는 경우와 GPS 수신기 사용 중 장애물(건물, 터널 등)에 의해 일시적으로 위성신호를 수신하지 못하여 위치파악을 하지 못하다가 다시 위성신호를 수신하게 된 경우가 이에 해당됩니다.

 

 


GPS 단말기의 위성화면에는 대부분 2개의 동심원이 그려져 있는데 이 중 바깥쪽 원은 현위치 기준의 평면(수평선)을 표시하는 것이고, 안쪽 원은 현위치 기준의 고도각 45도 영역을 표시하는 것입니다.

GPS 수신기는 Almanac 데이터를 바탕으로 위성화면 동심원에 각 위성들의 위치를 표시합니다.

그리고 위성화면 하단에서 막대 그래프의 길이는 각 위성들의 신호강도를 표시하는 것이고, 막대 그래프의 색깔은 Ephemeris 데이터의 활용가능여부를 나타냅니다.

현재 저장되어 있는 특정 위성의 Ephemeris 데이터가 최신 것으로 확인되면 막대 그래프의 색이 채워지고, 그렇지 않은 경우에는 막대 그래프의 테두리 선만 표현되지만 새로운 Ephemeris 데이터의 수신이 완료되면 색이 채워지게 됩니다.

 

 


내용정리

그런데, TTFF는 위에서 설명한 Almanac 데이터와 Ephemeris 데이터의 수신 여부만으로 결정되는 것은 아닙니다.

GPS 수신기의 전원을 끈 채로 1,000km 이상 떨어진 곳으로 이동하여 다시 GPS 수신기의 전원을 켜면 TTFF가 굉장히 길어지는 것을 경험하신 분도 계실 것입니다.

이는 GPS 수신기가 위성들의 원자시계와 정확한 시각동기를 이루기 위한 과정이 길어지기 때문에 발생하는 문제입니다.


GPS 수신기는 각 GPS 위성들로부터 전파(PRN 코드)를 수신하여 전파가 도달한 시간을 측정하고, 이를 통해 해당 위성까지의 거리를 측정합니다.

그런데 문제는 GPS 위성에서 GPS 수신기까지 전파가 도달하는 시간을 측정하려면 GPS 위성과 GPS 수신기의 시각이 아주 정밀하게 일치해야 된다는 것입니다.


실제로 GPS 위성은 원자시계를 탑재하고 있지요.

그런데 GPS 수신기에도 원자시계를 탑재할 경우... GPS 수신기의 무게와 부피는 아주 커지게 되고요, 그 가격 또한 수천만원을 넘게 될 것입니다.

실효성이 떨어지겠지요.

그렇기때문에 실제로 일반적인 제품에서 사용하는 방법은, GPS 신호를 통해 GPS 수신기의 시각동기를 이루는 것입니다.


그런데 여기서 또 문제가 발생합니다.

GPS 위성에서 현재의 정확한 시각정보를 전파에 실어 GPS 수신기로 보내면,

그 신호가 수신기에 도달할 때에는 이미 그 시각이 아니라는 것입니다.


그래서 다시 이 문제를 해결하기 위해 예상소요시간의 개념이 도입는데 이는 GPS 위성과 GPS 수신기의 거리를 고려하여 전파가 도달하는 예상소요시간을 산출하는 것입니다.

즉, GPS의 시각정보가 GPS 위성으로부터 GPS 수신기까지 도달하는 예상소요시간을 고려하여 GPS 수신기의 시각을 동기화 시키는 것입니다.


특정 시각의 GPS 위성 위치는 Ephemeris 데이터를 통해 산출할 수 있지만 문제는 GPS 수신기의 위치는 파악할 수 없다는 것입니다.

그래서 GPS 수신기의 위치는 최후로 위치파악이 되었던 곳을 기준으로 하여 예상소요시간을 산출하고, 시각을 보정하고, 이를 바탕으로 본격적으로 GPS 수신기의 위치파악에 들어갑니다.


만약 최후로 위치파악이 되었던 곳이 아닌 다른 곳에서 다시 GPS 수신기를 사용한다면 당연히 예상소요시간도 틀린 값이며, 시각도 정확하게 동기화 되지 않은 것이며, 좌표값도 산출도 불가능할 것입니다.

이 때, GPS 수신기의 프로세서는 예상소요시간을 가감하며 다시 위치계산을 되풀이 하게 되는데 산출된 결과를 살펴서 보다 신뢰할 수 있는 결과가 나올 수 있도록 예상소요시간을 변경해 갑니다.


여기서 산출된 결과를 살핀다는 것은 글로 설명하기 정말 어려운 부분인데,

예를들어 3개 위성과의 거리(의사거리 : Pseudorange)로 산출한 위치에 4번째 위성과의 거리값을 적용하여도 그 위치가 나오는지 확인하는 것으로,

4번째 위성과의 거리값이 더 길어야 되는지 혹은 더 짧아야 되는지 확인하여 예상소요시간의 가감을 결정하는 것입니다.

예상소요시간의 가감하여 3개 위성을 통해 산출한 위치에 4번째 위성과의 거리값을 적용하여도 정확히 일치하는 결과가 나왔다면 그 좌표값은 신뢰할 수 있는 좌표값이며,

그 때의 예상소요시간은 정확한 소요시간이 되기 때문에 GPS 수신기는 정확한 시각동기를 이룬 것입니다.


다시 본론으로 돌아가 GPS 수신기의 전원을 끈 채로 1,000km 이상 떨어진 곳으로 이동하여 다시 GPS 수신기의 전원을 켜는 경우를 생각해보죠.

GPS 수신기는 1,000km 떨어진 이전의 위치를 기준으로 예상소요시간을 부여하고 위치계산에 들어가게 되는데,

이 예상소요시간은 실제 소요시간과 큰 차이를 보이기 때문에 당연히 정확한 소요시간을 찾아내는 데 많은 시간이 필요하게 됩니다.


이 때, 사용자가 직접 수동으로 GPS 단말기에 자신의 개략적인 위치와 고도 및 시각을 입력해 준다면 GPS 수신기는 Almanac 데이터를 통해 해당 시각과 지점에서 위성위치를 파악할 수 있고,

그 위치를 기준으로 예상소요시간을 부여하기 때문에 좀 더 빨리 정확한 소요시간을 찾아내게 되어 시각동기를 이루게 될 것이고, 곧 위치파악을 할 수 있게 됩니다.

이러한 기능을 초기화(Initialize) 또는 재시작(Restart GPS)이라 합니다.

이 댓글을 비밀 댓글로
    • 2019.11.30 11:12
    비밀댓글입니다

[안드로이드] SDK manager 통한 업데이트후 ADT 실행 시 오류

by Blogger 하얀쿠아
2017. 3. 15. 23:02 소프트웨어 Note/Android

지금은 많은 안드로이드 어플리케이션 개발자들이 Eclipse + ADT 조합에서 Android Studio로 넘어갔을 것이라 예상한다.

하지만, 나는 아직도 Eclipse + ADT 조합을 이용한다.


그런데 어느순간, SDK manager를 통해 SDK를 업데이트 하고 나서부터 아래와 같이 ADT를 상위버전으로 업데이트 하라는 에러가 발생한다.



그냥 무시하고 써도 되겠거니.. 하고 Close하고 살펴봤는데, 이게 웬걸.

아무것도 할수가 없었다.

관련  패키지 로딩이 제대로 되지 않는 것으로 판단된다.


그래서 지시한 대로 [Help > Check for Updates]를 클릭하면 업데이트할 항목이 없다거나, 엉뚱한 것들만 표시된다. 

SubVersion 혹은 SVN 같은 것들.



한참 헤매다 보니, 아래와 같은 방법으로 ADT 업데이트가 가능했다.


[Help > Install New Software] 선택 후, Work with: 부분에 URL을 아래와 같이 google의 android eclipse 로 맞춰준다.


https://dl-ssl.google.com/android/eclipse/




[ADD] 버튼을 눌러주면 위와 같이 Android 관련 설치 가능한(업데이트 가능한) 패키지 목록이 보여진다.

모두 체크하고 [NEXT] 항목을 눌러 설치해주면 된다.

이제 ADT가 정상적으로 업데이트 되었고, 패키지 로딩에도 문제가 발생하지 않는것을 볼 수 있을 것이다.

이 댓글을 비밀 댓글로

Notepad++ Plugin : NPP Export Plugin

by Blogger 하얀쿠아
2017. 2. 15. 01:00 소프트웨어 Note

Notepad++ Plugin : NPP Export Plugin

notepad++의 plug-in중, code의 syntax highlight를 보이는 그대로 html형식으로 클립보드에 복사해주는 플러그인이 있다.

관련 글은 아래 URL에서 볼 수 있다.

관련 질문 : http://stackoverflow.com/questions/3475790/copy-notepad-text-with-formatting


이 플러그인의 코드는 git hub에 공개되어 있다.

Github URL : https://github.com/chcg/NPP_ExportPlugin


그리고 dll로 빌드해서 다운로드 받을 수 있는 경로가 제공된다.

https://ci.appveyor.com/project/chcg/npp-exportplugin/build/job/l1eku4c71gtrwvh5/artifacts


편의를 위해 윈도우 64bit용으로 빌드한 dll을 첨부한다.

NppExport.dll



Settings->Import->Import plugin 메뉴를 통해 플러그인 설치가 가능하므로 참고하기 바란다.

이 댓글을 비밀 댓글로

무선 LAN, Wi-Fi 이야기

by Blogger 하얀쿠아
2017. 2. 8. 01:47 소프트웨어 Note/Network Technology



무선 랜 관련 용어 설명


우선 알아두어야 할 몇가지 용어들에 대해 간략히 설명하겠다.


AP(Access Point)

보통 "에이피-"라고 발음한다. AP(Access Point)는 그 자체로는 무선 중계 기지국의 의미를 가지고 있다.

즉 안테나와 무선 신호처리, 관리 기능, 유선 네트워크와 무선 네트워크를 연동하는 기능을 가지고 있다.

쉽게 생각을 하자면 유선 랜의 허브에 해당하며, AP를 통하여 기존 유선 랜과 연동이 가능하다. 

최근에는 AP에 인터넷공유기능을 내장한 유무선 인터넷 공유기 혹은 무선 인터넷 공유기 등이 더욱 일반화 되어 가고 있다.



Infrastructure(Access Point Network) 모드 / Ad-Hoc모드 (Peer-to-Peer Network)

모든 무선 랜 카드는 AP가 있는 경우와 없는 경우 두 가지로 동작모드(Operation Mode)를 설정 가능하다.



AP가 없는 경우 : Ad-Hoc


"에드혹"이라고 발음한다. 이 모드로 설정하면 작은 무선 네트워크 그룹을 간단하고 빠르게 설치가 가능하다. 모든 데스크탑 PC나 컴퓨터들이 무선 랜 카드를 가지고 있는 경우이며 파일과 프린터 공유가 가능하다. 유선랜과 비교하자면 허브없이 1:1 크로스 케이블로 연결 하는 것과 유사하다고 볼 수 있겠다. AP를 사용하는 것 보다는 신뢰성이나 보안성이 떨어진다.





AP가 있는 경우 : Infrastructure 모드


"인프라스트럭쳐"라고 발음한요. 이 모드로 설정하면 기존 유선 네트워크에 손쉽게 연동이 가능하다.
즉 무선 랜 카드를 장착한 PC나 컴퓨터들이 Access Point를 통하여 손쉽게 기존 유선 네트워크와 연동되어 파일 공유 및 프린터 공유 그리고 인터넷 사용 등이 가능하다. 참고로 Access Point는 두 가지 종류가 있다. 단순히 무선과 유선을 연동하는 기능만을 제공하는 기본적 Access Point와 무선 공유기(Access point+인터넷 공유기)가 있다. 아래 그림은 무선 공유기의 예이다. 유선 랜과 비교하자면 AP는 허브에 해당한다. Ad-Hoc모드 보다는 신뢰성 및 보안성이 더 좋다.







SSID (Service Set IDentifier)

유선 랜은 네트워크를 연결할 때 물리적으로 전기신호가 통할 수 있는 케이블들이 연결되기 때문에 같은 허브에만 연결하면 되었지만 무선 랜은 빈공간을 매체로 통신을 하기 때문에 같은 공간에 다른 무선네트워크가 존재하는 경우 혼신이 불가피 해진다. 이런 문제를 해결하기 위해 같이 통신을 할 모든 무선 장비들은 동일한 ID(식별부호)를 사용하여 통신을 하게되며, 모든 신호마다 그 ID를 포함시켜 혼신을 회피하게 된다. 이러한 ID를 SSID라고 부른다. 좁은 공간 안에 두개이상의 무선 네트워크가 존재가능하며, 이때 각 AP마다 서로다른 SSID를 부여하면 사용자는 무선랜카드를 통해 스캐닝을 하여 이들을 구분할 수 있고, AP를 골라서 연결 한 후 통신에 사용할 수 있다.



채널(Channel)

우리나라에서 802.11b표준을 사용하는 무선 랜에서 채널은 1번부터 13번까지 가능하다. 주파수 대역은 2.4Ghz 이며, 범위는 2412~2472Mhz, 한 채널 당 5Mhz씩 증가한다.

채널은 TV의 채널을 생각하면 된다. 예를들어 특정 방송국의 방송을 보려면 해당 채널을 맞추어야 하는 것처럼, 무선랜을 통해 특정 AP 혹은 무선장비와 통신을 하려면 같은 채널을 사용하도록 설정해야 한다.

단, 무선네트워크를 구성할 때 같은 공간에 2개 이상의 네트워크가 존재한다면 같은 채널을 사용할 수 없는데, 이때는 각 AP간에는 4채널의 간격을 두어야 간섭을 최소화 할 수 있다. 즉 첫번째 AP가 1번 채널을 쓰고 있다면 4채널의 간격을 두어서(2,3,4,5채널), 두 번째 AP는 6번 채널을 사용하도록 해야 한다는 말이고, 만약 세 번째 AP가 존재한다면, 그 세번째는 11번 채널을 사용하도록 설정해야 한다. 결과적으로 채널 역시 무선 랜 카드나 AP등에 해당 채널 값이 입력이 되어야 한다.

 


안테나의 특성


무선은 특성상 여러 가지 변수와 요인들에 의해 신호품질이 개선 될 수도, 악화될 수도 있다.

그러한 여러 요인 중 상당히 중요한 것은 안테나이다. 안테나의 특성을 파악하는 것만으로도 무선신호의 품질을 어느정도 개선 할 수 있다. 

이 경우에도 빛의 성질을 적용하면 이해하기 쉬울 것 같다.

 

 즉, 형광등이나 벽 등에 부착된 간접조명은 빛이 방 전체에 골고루 퍼지지만 멀리까지는 빛이 나가지 않는다. 일반적인 30~40평대의 아파트를 상상해 보길바란다. 거실의 형광등을 켜면 거실정도는 밝게 되지만, 저멀리 주방이나 발코니 등은 약간만 밝아질 뿐, 여전히 어둡다.

그러나 스포트라이트나 서치라이트와 같은 조명기구에서 나오는 빛은 좁은 부분만을 비추지만 강한 빛이 멀리까지 나간다.

이렇듯이 안테나도 무지향성(형광등/간접조명과 유사)과 지향성(스포트라이트나 서치라이트와 유사) 등의 서로다른 안테나가 존재하며, 어떤 안테나를 사용하느냐에 따라 무선 랜의 신호가 전달되는 범위의 길이와 형태가 달라진다. 그래서 대부분의 안테나가 어떤 특정 방향으로 놓아졌을 때, 이와는 다른 방향으로 놓아지는 여러가지 경우들보다 송수신되는 신호의 품질/세기가 가장 좋다. 


 이러한 것을 안테나패턴(Antenna Pattern)이라고 한다. 즉 지향성(Uni-directional)이나 무(無) 지향성(Omni-directional)이냐가 안테나패턴 종류이다. 지향성의 경우 안테나가 신호를 보내는 방향과 신호를 송수신할 상대 무선장비가 마주 보고 있지 않다면 무선신호는 도달되기 어렵다.

 

또 다른 하나의 특성은 안테나극성(Antenna Polarization)이다. 즉 전자기장의 방위성인데 무선 랜의 전파가 공간을 통과하는 특성 이다. 물론 일반사용자는 정확한 극성에 대해서 알 필요는 없다. 그러나 최소한 현재 극성이 수직적인지(Vertical) 수평적(horizontal)인지는 알아야만 한다. 이 특성에 따라 만약 송신용 안테나와 수신용 안테나의 극성이 불일치하게 된다면, 신호세기는 90%이상의 격감될 수 있기 때문이다. 즉 막대기처럼 생긴 안테나의 경우 상대방 무선 장비가 안테나를 수직으로 세워 놓았다면 자신의 무선 장비 안테나 역시 막대기 처럼 생긴 경우는 동일하게 수직으로 세워야 한다.

 

모든 안테나는, 그것이 비록 스마트폰 처럼 내장된 형태라도, '패턴'과 '극성'의 특성을 가지고 있다. 

이런 특성때문에 안테나를 이동시키거나 AP를 재구성함으로써 무선 환경을 개선 시키거나 사용 가능한 범위를 확장하거나 변경 할 수 있다. 즉 노트북을 약간 옆으로 돌리는 것만으로도 안테나 패턴에 의해 신호품질을 개선 할 수 도 있게 되는 것이다.

만약 AP(무선인터넷공유기)를 선택 시 내장안테나를 가진 제품이나 안테나 1개짜리 제품보다는 토끼 귀 처럼 2개의 작은 안테나를 가진 AP를 선택하는 것이 좋은 극성을 가지게 할 것이다.

 

그 외에 안테나에서 발생하거나 받는 신호의 세기를 나타내는 이득(gain)과 손실(loss)은 데시벨(dB)이라는 단위로 표시되는데 이것은 안테나가 가질 수 있는 신호의 세기를 말한다. 이것은 안테나의 입력된 전력과 출력되는 전력의 비례관계를 의미한다.(자세한 식은 사실 나도 잘 모르겠으므로 생략한다). 


다만 데시벨이 높을수록 출력되는 신호의 세기가 강해지지만 반드시 입출력 전력비에 비례적으로 강해지는 것은 아님을 유의해야 한다.

즉, 전력비가 2:1일 때 데시벨은 3dB이지만, 100:1일때는 20dB 이라는 것 이다.


또한 안테나는 신호를 증폭하기 보단 알맞은 형태의 무선파형으로 변환해 준다고 생각해야 한다. 

즉, 아래 표에서 여러가지 안테나중 dipole안테나의 이득은 6dB이고 parabolic안테나의 이득은 최고 25dB이어서 parabolic안테나가 신호는 훨씬 멀리 나가지만, parabolic의 경우 방향이 안 맞으면 dipole보다 연결신호가 오히려 약하게 된다. 전파의 파형을 변형해서 이득이 좋아지는 것이지 신호자체가 강력해지는 것은 아니며, 신호자체를 강하게 하려면 별도의 증폭장치를 이용해야 한다. 이러한 장비는 매우 고가이고 관련기관으로부터 허가를 받아야 사용 가능한 경우도 많으므로 일반적인 소호(SOHO) 사용자나 가정용으로 쓸 수 있는 것은 아니다.


종류 

설치/적용 

패턴 

극성 (Polarization) 

이득 (Gain dB) 

형태 

Quarte Wave (회초리형) 

이동용 

무지향성 

수직적 

 

stacked dipole 

데스크탑 벽면 독립설치 

무지향성 

수직적 

 

Panel 

벽면 

지향성 (150도 fan형) 

수직적 

10 

Yagi/Uda 

독립설치 

지향성 (15도 beam형) 

수직/수평적 

12~15 

 

Parabolic 

독립설치 

지향성 (5도 beam형) 

수직/수평적 

18~25 




무선랜 최적환경 만들기

무선랜 환경을 구성할 때, 몇가지 지켜야 하는 사항들이 있다. 이 내용을 준수한다면 무선랜을 통해 최적의 송수신율을 끌어 낼 수 있다.

장애물과 간섭 및 잡음으로 인한 신호세기 격감 최소화 하기.

일반적으로 전파는 주파수, 전송전력의 출력 값, 안테나의 형태와 지향점등에 영향을 받는다.

이중에 주파수, 전송전력의 출력 값 등은 관련법규에서 제한하는 최대치까지 사용이 가능하도록 되어있기 때문에 사용자로썬 그다지 바꿀 수 있는 부분이 없다. 또 안테나의 형태나 지향점 역시 어느 정도는 개선을 시킬 수 있겠지만 SOHO환경과 일반가정에서 쓸 수 있는 안테나 역시 매우 제한적이므로 사용자에게 선택의 폭이 넓은 것은 아니다. 결국 사용자는 주어진 장비를 최대의 효과를 내기위해서 전파의 성질에 대한 기초지식을 이용하는 것이 무선 랜 환경의 효율성을 높이는데 가장 중요한 관건이라 할 수 있겠다.

 

장애물 : 빈공간이 최상의 조건.

 유선 랜에서 케이블의 설치 상태에 따라 네트워크 품질이 영향을 받듯이, 빈 공간을 매체로 신호를 주고 받는 무선 네트워크은 전파가 통과하는 공간에 어떤 물체로 채워져 있는가에 따라 영향을 받는다.

 통신을 하려는 무선 장비간 사이에 장애물이 전혀 없는 빈공간이 최상의 조건이고, 만약 장애물이 존재한다면 그 물체의 성격에 따라 신호격감이 강해지기도 하고 약해지기도 하는 것 이다. 즉 무선 랜 장비사이가 장비를 기준 시점으로 서로 눈으로 보이고 가까운 거리에 놓는다면 최상인 것이다.(이론적으로 300m까지 무선랜 신호가 도달이 가능 하지만 이는 매우 이상적인 환경에서 테스트 했을 때 이다. 실내에서는 장애물이 없고 AP가 육안으로 확인이 가능한 범위에서 30~50m까지 일반적으로 사용이 가능하고 가정에서는 벽이 많이 있기 때문에 이보다 더 줄어든다. 단 옥외에서 특별한 안테나와 장비를 채용하면 최고 3Km까지도 가능하다.)


 다음이 장애물에 성격에 따른 설명이다. 전파는 눈에 보이는 것이 아니기 때문에 빛과 유사한 성격을 많이 가지고 있는데, 무선 랜의 전파를 빛으로 가정해서 조건을 검사해 보면 유사한 추측이 가능하다.(전등을 천장에 달면 장애물 간섭 없이 실내공간에 골고루 빛이 가는 원리와 같이 AP도 천정이나 벽면의 높은 위치에 많이 설치하는 것은 빛과 무선 랜의 전파 성질이 유사하기 때문이다.)

 

장애물의 밀도가 높을수록 신호가 약해짐(Fading)

 벽돌이나 돌 같은 밀도가 높은 장애물이 비교적 밀도가 낮은 석고보드나 목재벽보다 신호를 더 약하게 만든다.

 

전도체는 거의 완벽하게 신호를 차단하고 일부를 반사 시킴

 금속으로 만들어진 문 혹은 환기용 금속재덕트나 금속으로 만들어진 가구등 모든 전도체로 만들어진 물체는 거의 완벽하게 무선 신호를 차단한다. 예를 들어 무선 랜카드와 AP사이에 거울을 둔다면 반사를 위해 거울안쪽에 발라진 금속이 신호를 차단 시킬 수 있다. 이렇게 차단되는 경우는 소멸되는 것이 아니고 반사된다고 보아도 된다. 마치 거울에 빛이 거의 완벽히 차단되지만 반사가 되는 것과 같이 전도체는 무선 랜의 전파를 차단/반사 시킨다. 즉 빛의 반사체가 거울이라면 무선 랜 전파의 반사체는 전도체입니다. 빛이 거울이나 꼭 거울이 아니더라도 벽이나 가구에 의해 반사되어 간접조명이 이루어지듯 무선 랜의 전파는 완전한 전도체가 아니라도 전도정도에 따라 전파는 반사 될 수 있으며 이는 무선 랜 통신에 영향을 미칠 수 있다.





무선 지역네트워크 (Wireless LAN)

보통 무선랜이라고 하며, 무선 네트워크를 하이파이 오디오처럼 편리하게 쓰게 한다는 뜻에서 와이파이(Wi-fi)라는 별칭으로도 불린다. 무선접속장치(AP)가 설치된 곳을 중심으로 일정 거리 이내에서 PDA나 노트북 컴퓨터를 통해 초고속 인터넷을 이용할 수 있다. 무선주파수를 이용하므로 전화선이나 전용선이 필요없으나 PDA나 노트북 컴퓨터에는 무선랜카드가 장착되어 있어야 한다.

1980년대 말 미국의 프록심(Proxim)사와 심볼(Symbol)사 등의 무선기기 회사에서 처음으로 사업화하였으나 다양한 방식이 난립하여 일반화되지는 못했다. 1999년 9월 미국 무선랜협회인 WECA(Wireless Ethernet Capability Alliance; 2002년 WiFi로 변경)가 표준으로 정한 IEEE802.11b와 호환되는 제품에 와이파이 인증을 부여한 뒤 급속하게 성장하기 시작하였고, 우리나라에는 2000년에 도입되어 대학과 기업을 중심으로 활성화되고 있다.


초기에는 전파 도달거리가 10m에 불과했으나 2000년대에 들어와서는 50~200m 정도까지 대폭 늘어났다. 전송속도가 4∼11Mbps로 대용량의 멀티미디어 정보도 주고받을 수 있으며, 장시간 사용해도 사용료가 저렴하고, 이동성과 보안성까지 갖추고 있다. 유선 연결이 복잡한 백화점이나 병원·박물관 등과 전시회·세미나·건설현장 등 일시적으로 네트워크를 설치하는 데에 매우 유용하다. 2002년 12월 현재 보안과 주파수 간섭·전력소모·로밍서비스 등 해결해야 할 문제들이 많긴 하나 4세대이동통신 시장을 이끌어갈 것으로 전망된다. 



320Mbps에 도전하는 차세대 무선랜 규격 802.11N

무선랜의 속도가 100Mbps를 넘어 320Mbps에 도달한다면 어떤 변화가 생길까? 굳이 속도 때문에 불편한 유선 환경을 고집해야할 이유가 사라질 것이다. 지금 IEEE에서는 새로운 무선기술의 연구가 한창이다. 비공식적이긴 하지만, 이 새로운 표준(802.11n)은 802.11a와 802.11g의 두배인 108Mbps에서 최대 320Mbps의 대역폭을 지원한다. 더욱 놀라운 것은 이론상 속도가 아닌 실제 속도라는 것이다.


현재 802.11n 표준을 개발중인 High Throughput Task 그룹은 MAC계층과 물리(PHY)계층의 변형을 통해 데이터가 각 계층 사이의 접속점 (SAP : Service Access Point)을 통과할때 발생하는 대역폭 손실의 최소화를 위해 연구중이다. 이것은 802.11의 데이터 전송속도의 증가를 의미하며, 결과적으로 사용자들이 체감할 수 있는 성능의


증대를 가져오게 된다. 802.11g의 경우 54Mbps를 지원하지만 데이터 전송과정(암호화와 복호화, 에러 정정, 트래픽 관리 등)과 데이터 오버헤드로 인해 실제 사용자가 느낄 수 있는 속도는 절반에 불과한 20Mbps인 것을 생각하면 쉽게 이해가 될 것이다. 무선으로 320Mbps의 대역폭을 만끽하기 위해선 좀더 기다려야 한다. IEEE 802.11 워킹그룹의 회장인 스튜어트 케리는 이 기술의 적용이 2005년 이후에나 이뤄질 것으로 예상한다. 하지만 802.11g 표준이 IEEE로부터 공식인증 되기도 전에 802.11g제품을 출시한 제조사들의 발빠른 행보 역시 802.11n에도 적용될 것으로 예상된다. 

'소프트웨어 Note > Network Technology' 카테고리의 다른 글

TCP Flags: PSH 그리고 URG  (1) 2017.09.29
무선 LAN, Wi-Fi 이야기  (0) 2017.02.08
이 댓글을 비밀 댓글로