NeverStop

NeverStop http://dstein.egloos.com 늘 하던 일만 한다면, 늘 얻는것 외에는 아무것도 얻을 수 없다. ko Fri, 20 Nov 2009 01:37:17 GMT Egloos NeverStop http://pds8.egloos.com/logo/200805/02/25/d0036725.jpg http://dstein.egloos.com 80 77 늘 하던 일만 한다면, 늘 얻는것 외에는 아무것도 얻을 수 없다. <![CDATA[ 나는 훌륭한 프로그래머는 아니다,... ]]> http://dstein.egloos.com/2474702 http://dstein.egloos.com/2474702

Kent Beck이 자기 자신에 대해 이렇게 표현했다.

"나는 훌륭한 프로그래머는 아니다, 그냥 훌륭한 습관을 가지고 있는 좋은 프로그래머이다."

Kent Beck의 이말로 다시한번 생각하게 된다.

훌륭하거나 뛰어난 사람들은 그들이 그렇게 될수 밖에 없는 습관을 가지고 있다는것을....

]]> 어떤생각 http://dstein.egloos.com/2474702#comments Tue, 17 Nov 2009 07:29:19 GMT stein <![CDATA[ MFC Class Header, Source File ]]> http://dstein.egloos.com/2468674 http://dstein.egloos.com/2468674

이럴때 MFC Class 소스를 보려고 하면 클래스명과 헤더/소스 파일명이 전혀 상관없이 작성되어 있어 파일 찾는데 상당한 시간이 소비된다.

이런 시간낭비를 줄이기 위해 내가 필요해서 본 Class들에 대한 헤더/소스 파일을 정리하였다.

MFC Class/Struct Name	Header File	Source File
CCreateContext	afxext.h, afxext.inl
CDocument	afxwin.h	doccore.cpp
CDynLinkLibrary	afxdll_.h	dllinit.cpp
CFile	afx.h	filecore.cpp
CFileFind	afx.h	filefind.cpp
CFrameWnd	afxwin.h	winfrm.cpp
CMemFile	afx.h	filemem.cpp
COleDateTime	ATLComTime.h, ATLComTime.inl
CRuntimeClass	afx.h	arccore.cpp, objcore.cpp
CStdioFile	afx.h	filetxt.cpp
CView	afxwin.h	viewcore.cpp
CWinApp	afxwin.h, afxwin2.inl	appcore.cpp, appinit.cpp
CWinAppEx	afxwinappex.h	afxwinappex.cpp
CWnd	afxwin.h, afxwin2.inl	wincore.cpp
......

]]> C++(VC++) http://dstein.egloos.com/2468674#comments Mon, 09 Nov 2009 06:09:33 GMT stein <![CDATA[ MFC DLL의 resource 찾는 순서 ]]> http://dstein.egloos.com/2459698 http://dstein.egloos.com/2459698 http://support.microsoft.com/kb/600771/ko

요약

MFC extension DLL에서 resource를 가져오기 위해 CString::LoadString 혹은 CBitmap::LoadBitmap를 사용할 때, EXE file과 DLL file의 중복된 ID가 있는 경우에는 EXE file의 resource를 가져오게 된다. 이것은 MFC에서 resource를 찾는 순서가 Extension DLL 인 경우 EXE file의 resource를 가장 먼저 살펴 보고 여기에서 발견이 안된 경우에 Extension DLL resouce를 그리고 마지막 으로 MFC DLL resource를 찾게되기 때문이다.

그러나 MFC Regular DLL인 경우에는 DLL 의 함수가 resource를 load할 때 DLL의 resource만을 살펴보기 때문에 이러한 문제가 없다.

추가 정보

MFC Extension DLL에서 올바른 자신의 resource를 가져오기 위해서는 AfxSetResourceHandle()를 이용하여 DLL의 instance를 application의 default resource 위치로 잠시 setting해 주어야 한다.

예를 들면 다음과 같이 coding할수 있다.

HINSTANCE hInstResourceClient = AfxGetResourceHandle();

AfxSetResourceHandle(g_hInstance); // uses DLL's instance handle

// set in DllMain

CString strRes;

strRes.LoadString(IDS_MYSTRING);

AfxSetResoourceHandle(hInstResourceClient);

위의 code에서 g_hInstance는 DllMain에서 grobal 변수에 미리 저장하여 사용할수 있으며, Extension DLL를 AppWizard를 이용해 만들었다면 wizard가 만들어 놓은 AFX_EXTENSION_MODULE type 변수의 hResource 값을 이용해도 좋다. 그러나 AfxGetInstanceHandle은 이용할수 없다. Extenstion DLL에서 이 함수는 DLL의 instance가 아닌 EXE 의 instance를 return하기 때문이다.

참고로 Regular DLL에서 EXE 의 resource를 가져오기 위해서는 위의 code와 는 역으로 EXE file의 resource instance 값을 가지고 default resource 위치를 다시 setting해주어야 한다.

예를 들어 다음과 같이 coding할수 있다.

HINSTANCE hInstResourceDll = AfxGetResourceHandle();

HINSTANCE hInstResourceClient = (HINSTANCE) ::GetModuleHandle(NULL);

// use EXE's instance handle

AfxSetResourceHandle(hInstResourceClient);

CString strRes;

strRes.LoadString(IDS_MYSTRING);

AfxSetResoourceHandle(hInstResourceDll);

위의 code에서 GetModuleHandle 대신 AfxGetInstanceHandle를 사용해서는 안된다. Regular DLL에서 AfxGetInstanceHandle 함수는 DLL 의 instance를 return하기 때문이다.

[주의] AfxGetInstanceHandle 함수는 Extension DLL과 Regular DLL에서 서로 정반대의 instance를 return한다.

]]> C++(VC++) http://dstein.egloos.com/2459698#comments Wed, 28 Oct 2009 04:44:03 GMT stein <![CDATA[ access token ]]> http://dstein.egloos.com/2419815 http://dstein.egloos.com/2419815

● access token

- 로그온 사용자에 대한 정보를 포함한다.

- access token은 사용자 인증이 성공하여 로그온이 될때 생성된다.

- 프로세스가 보안 객체에 접근하거나, 특권을 요구하는 시스템 관리 기능을 수행할려 할때 access token을 사용하여 보안 검증을 수행한다.

- access token은 프로세스나 스레드의 보안 컨텍스트를 기술하는 오브젝트이다.

- access token은 프로세스나 스레드와 연관된 사용자 계정의 identity와 privileges 정보를 포함한다.

- 사용자가 로그온하는 과정 동안에 Winlogon은 로그온을 하고 있는 사용자를 표시하는 첫 번째 토큰을 만들고 이 토큰을 최초의 프로세스(기본적으로 Userinit.exe)에 붙인다.

- 기본적으로 자식 프로세스는 부모 프로세스의 토큰을 복사하여 사용한다.

- 토큰은 각각의 사용자 계정이 각각 다른 권한과 그룹을 갖기 때문에 크기가 일정하지 않다.

- 모든 프로세스는 access token이라는 보안 컨텍스트(security context)를 가지며, 프로세스 액세스 토큰은 보안 증명과 프로세스에 대한 자격증명을 포함한다.

- 기본적으로 스레드는 자신의 액세스 토큰은 가지고 있지 않지만, 하나를 얻어서 각 스레드들이 프로세스에서 다른 스레드들에 영향을 끼치지 않고 다른 프로세스의 보안 컨텍스트로 가장하는것을 허용한다.(Impersonation)

- Impersonation이라는 기능을 사용하여 스레드는 부모 프로세스와는 다른 보안 컨텍스트를 가질 수 있다.

- 일반적인 경우는 프로세스의 보안 컨텍스를 사용하여 보안 검증을 하고, Impersonation된 스레드의 경우는 프로세스의 것이 아닌 Impersonation된 스레드의 보안 컨텍스트를 사용하여 보안 검증을 수행한다.

・ primary token

프로세스의 보안 컨텍스트를 대표하는 토큰.

일반적으로 windows kernel에 의해서만 생성되고 프로세스의 기본 보안정보를 나타내기위해 프로세스에 할당될수도 있다.

OpenProcessToken 을 호출하여 primary token을 구할수 있다.

・ impersonation token

impersonation된 스레드의 보안 컨텍스트를 나타낸다.

OpenThreadToken 을 호출하여 impersonation token을 구할수 있다.

・ Token 구조체

]]> Windows Programing http://dstein.egloos.com/2419815#comments Sun, 06 Sep 2009 23:22:04 GMT stein <![CDATA[ 공룡체험전시관 을 가다.. ]]> http://dstein.egloos.com/2380119 http://dstein.egloos.com/2380119

둘다 뻘쭘하니 웃는 저 표정ㅡㅡ;
사진 찍는 연습을 더 많이 해야겠군..

정말 큰 공룡 '티라노 사우루스'
이때부터 민아는 겁을 먹었다..

기본체험 '화석찾기'
나름 신경을 쓴 듯하다.. 이런 기회는 흔치 않으니까..
민아 어디에 신경쓰는거니...

열심히 붓질하는 호야..

이제서야 자리잡고 화석찾기 하고 있다..

다 찾은 결과 스테고 사우루스 였다...
한가지 아쉬운 점!! 많은 화석찾기가 있었으나 모두가 '스테고 사우루스'였다
신경쓰는 김에 조금만 더 신경써주시지... 2% 아쉽다..ㅡㅡ;

커다란 티라노 발 밑에서....

아빠와 함께 트리케라톱스 앞에서...
민아는 아빠한테서 떨어지려고 하질않는다..

재밌어라 하는 호야^^

흔들~흔들~ 흔들다리 건너는 민아..

민아가 좋아하는 공룡 '파키케팔로 사우루스'
그래도 만지는건 싫은가 보다....

자기는 안 앉혀줬다는 심술이 났다..
사실은 앉으면 안되는 건데.. 민아는 살짝 얹힌거였었는데.. 호야...

어두운 터널같은 곳...
민아는 또 울었다..ㅡㅡ;

보기엔 그럴듯한데.. 굉장히 가볍다는...

다른 구경거리를 발견한 호야..

작은 전시장..
축소된 공룡들이 즐비하다...
다큐멘터리 봤다고 한 녀석을 알아봤다..

공룡 표본 뜨기

종이가 움직이지 않아야 하는데... 잘안된다 신지민..

ㅋㅋ

호야도 열심히...

짜짠~~ 아빠랑 민아랑 작품..

이건 호야 작품..

표본뜨기를 마치고 해저공룡들 보러 가는 길..

바다속 공룡들....
조명이 그래서 그런가 호야는 바다속 공룡들이 더 무섭다고 했다..
혼자 화장실도 못갔다는^^;

공룡들이 싸우고 있다..
실내인데다 조명이 어두운 관계로 영 사진이 별루다...

공룡퀴즈...
이것도 재미있더라^^

자꾸만 틀린다 호야..

그래도 기분좋은 호야^^

공룡 색칠하기..땀 뻘뻘 흘리며 색칠하고 있다..

체험전시관을 다녀간 친구들의 작품...

바로 위에 마련된 놀이방..

공룡놀이방이라 하기엔 좀...
하긴 공룡들이 구석구석에 쓰러져 있긴 하다^^;

공짜로 얻은 풍선...

역시 놀이방에서 최고의 인기는 자동차다...
익룡 또 쓰러졌다..

민아가 챙겨간 가방
저기에 뭐가 들어있더라??

맛있는 점심시간..
소풍엔 뭐니뭐니해도 김밥이 최고지^^;

민아는 또 조금만 먹었다..
좀 많이 먹으면 좋겠구만...

이제 배가 부른지 장난이 시작됐다..
민아가 보고 있다 호야..

거봐.. 금방 따라한다고 했지?
호야의 웃는 표정은 보는 엄마도 웃게 만들어^^

입구에 서 있던 둘리?
아깐 뜨거워서 못타고 지금 타고 있다..

나와서 마지막으로 기차 한번 타주시고 집으로 go~go~

오남공룡체험전시관..
가까이에 있어서 한번 가볼만한 곳이였던거 같다..
물론 애들도 좋아했고^^

기본체험으로 입장해서도 여러가지 즐긴거 같다..

위치... 네비게이션이 시키는 대로 해서 어찌어찌 오긴했으나 오는내내 정말 이곳이 맞나 할정도였다...
정말 산속에 숨어있었다..

호야의 작품[안킬로 사우루스]

민아의 작품 [파키케팔로 사우루스]

아빠의 작품 [스테고 사우루스]

]]> - My hoya mina http://dstein.egloos.com/2380119#comments Wed, 22 Jul 2009 08:34:04 GMT stein <![CDATA[ 한샘친구들과 함께.... ]]> http://dstein.egloos.com/2360952 http://dstein.egloos.com/2360952

늘 우리아파트 놀이터에서 놀다가 오늘은 옆 아파트로 원정가서 놀았다..
여기에 바닥분수대가 있는 관계로....
아직은 물이 나올 시간이 안되서 놀이터에서 그냥 놀고있다..
지현이, 가연이, 지민이, 서윤이, 민지, 동호, 채원이, 가현이....
현주랑 윤배랑 윤배동생 인영이만 빠졌네..

젤 왼쪽이 여기 아파트에 사는 다연이... 다연이 빽 믿고 원정왔다는..^^;
모두 5살짜리 애들이구만.... 이렇게 모이기도 힘들텐데.. 올핸 모두들 5살 뿐이네..

이젠 제법 개구장이가 다 되었다.. 호야...
예전에 수줍어 하던 호야가 아니야...

민아도 이젠 놀이터에서 놀지않으면 울고불고 난리다..
덕분에 놀이터 썬탠을 확실히 했다..

운전중인 지현이 언니와 가현이..구경만 하는 민아^^;

드디어 분수대에서 물이 나오기 시작했다..

구경만 하는 민아..
아직은 무서워서 가까이 가질 못하고 있다.. 오빠는 벌써 흠뻑 젖었는데...

호야는 물에 빠진 생쥐가 되버렸네...

겁 많은 채원이 들어가고픈 맘은 굴뚝같은데.. 차마 용기를 내지 못한다..
결국 이날 물에 젖지 않은 말짱한 모습은 채원이 뿐이였다는....

모두들 추워서 덜덜~~
그래도 먹겠다고 모두들 한 손엔 뻥튀기 들고 있다^^; ]]> - My hoya mina http://dstein.egloos.com/2360952#comments Tue, 30 Jun 2009 11:08:21 GMT stein <![CDATA[ 간식... ]]> http://dstein.egloos.com/2360940 http://dstein.egloos.com/2360940

초코맛이라 민아가 특히 좋아하는 빵이다..

민아가 들고 있는 휴대전화.. 듀얼폴더... 저 폰이 처음 나왔을때.. 그리고 내가 그 폰을 샀을 때...
이 폰보다 좋은 폰이 나오리라곤 상상도 하지 못했다.. 아니 안했다..
신제품은 계속해서 나오겠지만 이 폰이 젤 좋고 젤 이쁠지 알았다...
완전 착각이란걸 곧 알게됬지만....
지금은 민아 장난감이 되었다..

혼자서 전화놀이 잘한다..
소리만 들으면 진짜 통화하는 줄 안다..
민아~~ 아빠가 진짜루 빵 사왔으면 좋겠다.... ]]> - My hoya mina http://dstein.egloos.com/2360940#comments Tue, 30 Jun 2009 10:50:43 GMT stein <![CDATA[ 평내 물놀이장.. ]]> http://dstein.egloos.com/2355281 http://dstein.egloos.com/2355281

많이 뜨거워진 날씨 탓에 동네에 있는 물놀이장을 가봤다..
놀고자 간건 아니고 상태가 어떤가 해서 민아만 데리고 잠시 들렀다..
생각보단 깨끗했다..
관리하시는 분이 두분 계시는데 철저히 관리?를 하고 계셨다..
신발 신고 들어갔다가 야단맞았다는...ㅜㅜ

옷을 안가져간 터라 물에 빠지지 않길 바랬는데..
역시 그건 무리였다... 벌써 바짓단이 다 젖었다.. 팬티도,,,,

이건 왜 흑백으로 찍혔는지 모르겠네...???

나름 이것저것 애들이 즐기기에 적당한걸루다 설치를 해 놨다..
근데 맨발로 다니다보니 저 초록색 바닥이 너무나 뜨거웠다ㅡㅡ;

왔다 갔다...
원에서 견학을 가는 관계로 오늘 민아는 유치원에 안가고 쉬었다..
유치원이 아직 마치지 않은 시간이여서 그런가 애들도 몇 없고 놀기에 딱 좋았다..

시간이 되면 이렇게 물도 쏟아져내려 주신다..
시간내서 호야랑 민아랑 같이 철저한 준비를 한 뒤 놀러와야겠다..
애들은 신나하겠지?
엄만 힘든데...ㅜㅜ

]]> - My hoya mina http://dstein.egloos.com/2355281#comments Wed, 24 Jun 2009 03:54:41 GMT stein <![CDATA[ WriteProcessMemory를 사용한 코드 인젝션시 주의 사항 ]]> http://dstein.egloos.com/2335201 http://dstein.egloos.com/2335201 WriteProcessMemory를 사용한 코드 인젝션시 주의 사항

VirtualAllocEx()와 WriteProcessMemory()를 사용하여 리모트 프로세스에 코드를 인젝션 시키는 방법은 이미 많은 분들이 소개해서 모두 알고 있을것으로 생각된다.

이런 설명들을 보다보면 Release모드로 컴파일한 경우에서는 정상적으로 동작하지만 Debug모드로 컴파일일한 경우에는 리모트 프로세스가 Crash된다라고 언급이 되어 있으나 구체적으로 왜 이런 현상이 발생하는지에 대한 설명이 존재하지 않아 이부분에 대해 언급하려 한다.

아래 예제 코드는 리모트 프로세스에 인젝션될 스레드 함수 코드이다.

이 코드가 Release 모드와 Debug 모드에서 어떻게 코드(기계어)화 되는지 내용을 보면 그 원인을 알 수 있다.

Release 모드로 컴파일 한 경우

Debug 모드로 컴파일 한 경우

Releas모드와 Debug모드의 차이점이 명확이 구분된다.

Debug모드일 경우에는 런타임체크 코드가 자동으로 삽입되었다. 이렇게 자동으로 생성된 런타임체크 코드가 리모트 프로세스에 주입되어 실행되면 당연히 런타임체크 코드가 호출하는 주소에 해당 런타임체크 코드가 존재하지 않으므로 Crash가 발생한다.

그럼 이렇게 자동으로 삽입되는 런타임체크 코드를 생성하지 않게하기위해서는 어떻게 해야 할까? 방법은 두가지가 있다.

첫째. Debug모드일 경우 기본으로 설정되는 컴파일 옵션을 변경하여 코드 전체에 대해 적용하는 방법

C/C++ ->Code Generation의 Basic Runtime Checks의값을 Both (/RTC1, equiv. to /RTCsu)에서 Default로 변경한다.

둘째, 컴파일 지시자를 사용하여 해당 코드에 대해서만 적용하는 방법

또 하나 주의해야 할 사항이 있다. WriteProcessMemory로 코드를 리모트 프로세스에 쓰기위해 쓸 코드의 주소를 얻어야 하는데.. Debug모드일 경우 이 코드의 주소가 실제 주소가 아닌 해당 코드 주소를 가리키는 JMP문으로 기록되어 있는 경우가 존재한다.

이는 Debug모드일 경우 Link옵션이 Incremental Linking으로 설정되어 있어서 그렇다. 모두 알고 있겠지만 Incremental Linking은 링크 시간을 단축하기 위해 링크시점에 모든 코드의 호출 주소를 변경하지 않고 변경된 코드의 주소만 JMP문으로 변경하는 기능을 수행한다. 따라서 WriteProcessMemory로 기록하는 내용이 실제 코드의 내용이 아니라 JMP문에 해당하는 다른 내용의 코드가 기록된다.

단 해당함수가 static으로 구현되어 있을경우 Incremental Linking으로 설정되어 있더라도 실제 함수의 주소가 코드에 설정된다.

(위의 샘플소스를 보면 static으로 선언되어 있음.)

이설정은 Project의 Linker->General의 Enable Incremental Linking을 NO로 설정하여 해결 할 수 있다.

]]> Windows Programing http://dstein.egloos.com/2335201#comments Tue, 02 Jun 2009 07:39:05 GMT stein <![CDATA[ IPv6 어플리케이션은 IPv4와 IPv6 주소 중에서 어느 것으로 접속을 하나요? ]]> http://dstein.egloos.com/2324104 http://dstein.egloos.com/2324104 http://www.ngix.ne.kr/other/faq/IPv6DNS/IPv6_application.htm

도메인네임이 IPv4 주소(A RR)와 IPv6 주소(AAAA RR)를 모두 갖고 있는 경우

IPv4 인터넷에서는 도메인 네임이 갖는 IP 주소는 IPv4 주소 한 종류 뿐이었습니다.

그러나 이제 IPv6 인터넷이 도입되면서, 하나의 도메인네임이 IPv4 주소와 IPv6 주소 모두를 갖는 경우가 발생하게 됩니다.

예를 들어 아래와 같은 경우,

"examp.co.kr" 도메인 설정 내용
ftp.examp.co.kr. 1800 IN A 192.0.2.200
ftp.examp.co.kr. 1800 IN AAAA 2001:dc5:f::200

단말 호스트의 IPv6 어플리케이션은 getaddrinfo() 함수 호출의 결과로 ftp.examp.co.kr. 도메인네임에 대해 "192.0.2.200" IPv4 주소와 "2001:dc5:f::200"의 2개 주소를 얻게 됩니다.

이 경우, 어플리케이션은 "이 2개의 주소 중 어느 주소를 선택하여 접속을 시도해야 하는가?" 하는 문제가 발생하게 됩니다.

물론 이것은 원칙적으로 어플리케이션을 작성하는 개발자의 선택에 따라 결정될 것입니다.

어플리케이션이 getaddrinfo() 함수로부터 얻은 IP 주소 중 하나를 다시 Socket API에 인자로 전달함으로써 통신이 개시될 수 있기 때문입니다.

이 동작은 프로그래머가 정하여 프로그램 코드를 작성할 수 있습니다.

디폴트 IP 주소 선택 알고리듬 (Default Address Selection)

IETF RFC3484 문서는 이 문제를 다루고 있습니다.

Ref Docs : RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"

일반적으로 어플리케이션은 도메인네임의 IP 주소 변환 함수 gethostbyname() 이나 getaddrinfo()가 리턴하는 IP 주소 목록에서 첫 번째 IP 주소를 선택하여 이 IP 주소로 Socket을 열고 통신을 개시합니다.

이러한 일반 사항을 기반으로 RFC3484는 getaddrinfo() 함수가 도메인네임의 IPv4 주소와 IPv6 주소를 함께 파악한 경우, 일정한 디폴트 알고리듬을 적용하여 어플리케이션으로 리턴하는 IP 주소 목록을 정렬(sort)하여 반환하는 동작을 정의합니다.

getaddrinfo() 함수는 일정한 규칙으로 IP 주소 목록을 반환하여 어플리케이션이 접속 시도하는 IP 주소를 일정하게 제어하는 역할을 하게 됩니다.

접속대상 주소 선택 알고리듬에 사용되는 디폴트 정책 테이블(default poliy table)은 아래와 같습니다.

Prefix Precedence Label 비고

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

::1/128 50 0 IPv6 LoopBack 주소

::/0 40 1 이외의 모든 IPv6 주소

2002::/16 30 2 6to4 IPv6 주소

::/96 20 3 IPv4-compatible IPv6 주소

::ffff:0:0/96 10 4 IPv4-mapped IPv6 주소, IPv4 주소를 의미

Source : RFC3484 "Default Address Selection for Internet Protocol version 6 (IPv6)"

2.1. Policy Table

이 주소 선택 알고리듬의 개략적인 내용은 아래와 같이 정리할 수 있습니다.

1. IPv4 주소와 IPv6 주소가 함께 리스트에 있는 경우, IPv6 주소가 디폴트로 리스트 중 첫 번째 IP 주소로 리턴됩니다.

IPv4 주소(::ffff:0:0/96) 보다 IPv6 주소(::1/128, ::/0, 2002::/16, ::/96)들이 Precedence에서 모두 우선순위가 높습니다.

이에 따라 IPv6 어플리케이션이 getaddrinfo() 함수로부터 반환받는 IP 주소 리스트에 IPv4와 IPv6가 혼재하는 경우, 디폴트 동작으로 그 첫 번째 IP 주소는 IPv6 주소가 됩니다.

결과적으로 IPv6 어플리케이션은 IPv4와 IPv6 주소 모두 가진 도메인네임에 대해서는 IPv6를 먼저 접속 시도 주소로 선택하는 동작을 하게 됩니다.

2. IPv6 주소가 다수 존재하는 경우, IPv6 루프백(loopback) 주소, 일반적인 IPv6 주소, 6to4 IPv6 주소, IPv4-compatible IPv6 주소의 순으로 정렬(sort)하여 리턴합니다.

IPv6 주소 "2001:dc5:f::200"와 IPv6 주소 "2002:c000:02c8::c000:02c8"가 도메인네임에 함께 지정되어 있는 경우, APNIC을 통해 할당된 native IPv6 주소 "2001:dc5:f::200"가 6to4 tunnelling 방식의 자동생성된 6to4 IPv6 주소 "2002:c000:02c8::c000:02c8"보다 우선하게 됩니다.

곧 어플리케이션은 native IPv6 주소와 6to4 IPv6 주소가 있는 경우, native IPv6 주소로 먼저 접속시도하게 됩니다.

NOTE!: DNS의 IPv6 주소 설정오류가 야기하는 어플리케이션의 접속 시간 지연 문제

일반적으로 어플리케이션은 getaddrinfo() 등의 함수로부터 리턴받은 IP 주소 목록 중 첫 번째 IP 주소로 접속을 시도한 후 접속에 실패하면 다음의 IP 주소를 사용하여 접속을 시도합니다.

따라서 IPv4와 IPv6 주소가 하나씩 있는 경우, IPv6 주소로 먼저 접속을 시도하고, 이에 실패하게 되면, IPv4 주소로 접속을 시도합니다.

만일 DNS의 특정 도메인네임에 존재하지 않는 IPv6 주소가 설정되어 있는 경우, 어플리케이션에서는 접속시도와 그 timeout에 따르는 시간지연이 발생한 후 IPv4 주소로 접속이 성공함으로써, 사용자는 접속이 느린 현상을 경험하게 됩니다.

위에서 정리된 디폴트 주소 선택 알고리듬 내용은 개략적인 것으로 이외에 시스템 환경조건에 의한 주소 선택 및 정렬 알고리듬을 RFC3484 문서에서 정의하고 있습니다.

주의할 점은 RFC3484에서 정의한 주소선택 알고리듬은 디폴트 알고리듬일 뿐이며 어플리케이션에서 별도의 선택 알고리듬을 사용하여 특정한 주소 선택을 하거나, 디폴트 주소 선택 정책 테이블의 내용을 변경하는 경우, 선택 방식이 변경될 수 있다는

사실입니다.

Windows 2003 서버의 경우, 아래와 같이 default policy table 내용을 볼 수 있으며, 이 테이블에서 각 필드 값을 변경하여 getaddrinfo() 함수의 정렬 순서를 변경할 수 있습니다.

C:>netsh interface ipv6 show prefixpolicy
Querying active state...

Precedence Label Prefix
---------------- --------- --------------------------------
   10 4 ::ffff:0:0/96
   20 3 ::/96
   30 2 2002::/16
   40 1 ::/0
   50 0 ::1/128

]]> Network http://dstein.egloos.com/2324104#comments Thu, 21 May 2009 08:35:42 GMT stein