S/W 개발자들이 사는 이야기 - 식스맨++

윈도우를 투명하게 하는 함수를 쓰면 느려지는 현상으로 고생한 이야기...

myidojh — Sun, 31 May 2009 23:34:06 +0900

새로운 프로젝트를 하게되면, 아래와 같은 프로세스를 거친다.
1. SRS작성
2. SRS에서 요구하는 기능 구현
3. SDS작성
4. 개발
5. QA
6. 릴리즈
당연히 2번을 하다가 1번을 고치기도 하고, 3번을 하다가 1번을 고치기도 하고,4번을 하다가 1번을 고치기도 한다.

5번을 하다가 고치기도 할까?

당연히 SRS를 작성할 때나, SDS를 작성할 때나, 개발을 할때 안나오던 버그가 발견되어서 SRS에 이런 경우에는 non bug로 처리한다고 SRS를 반영한다.

이번 프로젝트도 역시나 QA하는 동안 버그를 발견했다. 발견된 시기는 QA를 시작하는 시점이었고, 관련 이슈를 검토한 시점은 베타 기간이었다. 큰 프로젝트가 아니라 짧은 베타기간중 3일이라는 긴 시간을 잡아 먹었다.
QA에서 제품의 기능을 검증하는 PC에서 특정 UI를 실행하면, "아주 느리게 나오는 버그"였다. QA 알파에 느려지는 이슈가 올라왔을 때는, 당장 "아 내가 실수했구나'하는 버그들이 많아서 그 이슈를 처리한다고 관심을 가질 여유가 없었다.
"아 내가 실수했구나"라는 버그는이 내 pc에서도 같은 재현 스텝을 하면 그대로 발생하는 이슈들이다. "아주 느리게 나오는 버그" 내가 가지고 있는 어떤 머신을 이용해도 발생하지 않아서 특정 pc에서만 발생하는 이슈겠지 하고 미루어 놓았다.
베타가 시작되고, 본격적으로 관련 이슈를 검토해 보기 위해서, QA용 pc를 공수했다. pc 구하기가 어려워서.. 라는 말로 시작을 했는데,.. QA pc 대부분에서 느려지는 현상이 발생한다고 하면서 여러 pc 중에 한대를 빌려주었다.
글로만 보던 버그를 눈 앞에서 재현을 해보니, 어처구니가 없었다. 이런 현상이 QA를 하는 모든 pc에서 발생한다고 하니. 마음이 조급해졌다. 우선 어떤 기능 때문에 느려지는 현상이 발생하는지 체크하기로 했다. 아래와 같은 순서로 체크해 보았다.
1. 특정 UI만 따로 분리해서 프로그램을 만들어서 실행해본다.
2. 특정 UI와 동시에 실행되는 기능들을 모두 off 해본다.
3. 특정 UI와 동시에 실행되는 기능들을 하나씩 키면서 실행 해본다.
역시, 첫번째, 두번째에서는 이상없이 실행이 되었다.
그런데 세번째에 기능을 하나씩 키면서 실행을 해보는데, 특정 UI가 발생할때
알파 값을 먹인 윈도우를 배경으로 까는 기능이 있는데 그 기능을 키니깐 늦어 졌다.
어떤 기능 때문에 늦어 졌는지를 파악했으니깐 실제 어떤 함수에서 이런 현상을 발생시키는 지 확인하면 되기 때문에 그 기능 내부에 함수를 하나씩 제거 해보면서 체크해 보았다.
조금만 더하면 된다는 생각에 퇴근 시간이 되었지만, 끝까지 찾아보았다. 그런데.. 왠걸 모든 함수를 다 빼 보았지만, 여전히 느려지는 현상이 발생하는 것이다.
결국 포기하고 다음날 아침에 와서 다시 확인해 본다는 생각으로 어제 찾은 기능을 on하는 것은 제일 마지막으로 미루고, 처음부터 다시 해보았다.역시나 알파값을 가진 배경을 그리는 윈도우 때문이었다.
혹시나 하는 마음에 내가 만든 함수가 아닌 윈도우에서 제공해주는 함수인 "setlayerattribute"를 제거해 보았다. 그런데 UI가 정상적인 속도로 동작을 했다. 찾기는 찾았는데 해결책을 제시할 수 없는 상황이 발생한 것이다.
이 함수를 선택한 이유가 가장 쉬우면서 GDI, GDI++ 비해서 훨씬 속도가 빠르다고 해서 사용한 함수인데. 너무 어처구니가 없었다. 내가 만든 함수가 아니기 때문에 어쩔 수 없다라고 하면, 그러면 다른 프로그램들은 어떻게 유사한 기능들을 사용하고 있냐는 질문에 답을 할 수 없기 때문에 더 파보기로 했다.
1. 디버그를 이용해서 윈도우 내부 함수를 하나씩 off 해본다.
2. 그래픽 연산 문제이기 때문에 그래픽 드라이버를 업그레이드 해본다.
위와 같은 2가지 방법이 있는데 1번을 하기에는 시간적으로 촉박하여 2번을 해보기로 했다. 업그레이드를 해보았지만, 관련 현상을 여전히 발생하였다. 그래서 같은 회사의 같은 계열 그래픽 가드중 상위 그래픽 카드를 구해서 실행해 보았다. 여전히 마찬가지로 느렸다. 혹시나 하는 마음에 다시 최신 드라이버로 업그레이드를 해보았다.
그런데, 업그레이드를 한 이후에는 UI 느려지는 현상이 발생하지 않았다. 드라이버 버젼을 확인하는 2009년 2월이었다. 다시 원래 그래픽 장치를 꼽고 드라이버 버젼을 보니 2006년 버젼이 최신이었다.
흠 여기서, 그냥 그래픽 드라이버 문제라고 결론 지을 수 있지만, 우리 제품 쓰는 사람이 똑같은 현상이 발생했을때 '그래픽 장치를 바꾸세요.' 라고 할수 없기 때문에 해결책을 제시해주기로 마음 먹었다.
그런데 릴리즈 날자는 다가오고 다른 버그들도 있는데.. 걱정이다.

WinDBG로 Deadlock 알아내기

erratum — Sun, 31 May 2009 21:22:16 +0900

대학에서 운영체제 시간에 Deadlock에 대해서 배울 때, 많이 거론되는 것이 Dijkstra의 '식사하는 철학자' 일 것이다.
멀티 쓰레딩 프로그래밍을 하다 보면 아주 많은 주의를 기울여야 할 Deadlock 문제.
다양한 deadlock 문제 중에 윈도우 프로그래밍의 critical section에서 야기될 수 있는 deadlock을 WinDBG를 사용해서 발견하는 방법을 설명하려고 한다.
멀티쓰레딩 프로그램에서 hang이 발생하면 우선 deadlock을 의심해볼 수 있다.
처음으로 할 일은 hang dump를 수집하는 것이다.
windbg의 attach process 기능을 사용하던지, ADPlus나 UserDump 프로그램을 사용해서 응답하지 않는 프로그램의 hang dump를 수집한다.
hang dump는 약간의 시차(한 10초 정도)를 두고 3번 정도 반복해서 만드는 것이 좋다.
dump가 생성되면 windbg를 사용해서 디버깅을 시작한다.
dump 파일을 open 하고 난 뒤, command line에 '!locks'라고 친다.
user mode 디버깅에서는 locks는 ntsdexts.locks와 동일한 명령이다.
이 명령은 ntdll.dll에 있는 RtlInitializeCriticalSection에 의해서 초기화된 critical section 객체의 정보를 쭉 보여준다.

=====================================================

0:000> !locks

CritSec w3svc!g_pWamDictator+a0 at 68C2C298
LockCount          0
RecursionCount     1
OwningThread       d1
EntryCount         1
ContentionCount    0
*** Locked

CritSec SMTPSVC+66a30 at 67906A30
LockCount          0
RecursionCount     1
OwningThread       d0
EntryCount         1
ContentionCount    0
*** Locked

=====================================================

여 기에 아무런 옵션이 없으면 현재 프로세스에 속한 critical section 객체만을 보여주고, 옵션으로 -v를 붙이면 프로세스 밖에 있는 critical section 객체도 보여준다. '-o' 옵션은 Windows XP와 그 이후의 운영체제만 지원하는 것으로 orphaned information(유효하지 않은 critical section을 가르키고 있는 포인터)만을 보여준다.
locks 명령 말고도 비슷한 모양으로 정보를 보여주는 명령어는 !critecs, !cs 등이 있다.

이 위의 출력물에 대한 의미는 다음과 같다.

Windows XP와 그 이전 것들

LockCount 필드는 이 critical section으로 진입하기 위한 EnterCriticalSection()을 호출한 thread의 수에서 하나를 뺀 것과 같다. 왜 하나를 빼야 하냐면, 이 필드는 -1을 unlock 상태로 표시하고 EnterCriticalSection()이 호출될 때마다, 하나씩 증가하기 때문이다. 나중에 LeaveCriticalSection()이 호출되면 하나씩 감소시킨다. 예를 들어, 만약 이 값이 3이라면 하나의 thread는 이 critical section에 진입한 상태이고, 3개의 다른 thread들이 이 곳에 진입하기 위해서 기회를 노리고 있다는 의미이다.
RecursionCount 필드는 critical section에 진입한 thread가 다시 EnterCriticalSection()을 몇 번 더 호출하고 있는지를 나타낸다.
EntryCount 필드는 critical section에 진입하지 못한 thread가 몇 번이나 EnterCriticalSection()을 호출하고 있는지를 나타낸다.
CritSec w3svc!g_pWamDictator+a0 at 68C2C298에서 at 다음에 있는 숫자는 critical section의 핸들이다.
Owning thread는 말 그대로 이 critical section 객체를 현재 가지고 있는 thread이다.

그 이후 것들(Windows Server 2003 SP1과 그 이후것들)은 'Debugging Tools for Windows'의 Help에 Display a Critical Section 편을 보면 자세히 나와 있다.

Deadlock에 빠진 것이라면, !locks 명령어를 실행했을 때, LockCount가 1 이상인 것들이 하나 이상 존재해야 한다.
만약 그렇다면 이 thread들의 call stack을 훑어 봐야 한다.
call stack을 보면 top 언저리에 ntdll!RtlpWaitForCriticalSection+0x132와 비슷하게 보이는 frame이 존재하는데 이 함수의 첫번째 인자가 그 thread가 지금 기다리고 있는 critical section의 핸들이다. 이 핸들을 !locks으로 출력됐던 결과에서 봤을 때, critical section을 가지고 있는 두 놈이 서로의 것을 기다리고 있다면, 100%입니다.

RSA 알고리즘 - 공개키 암호 방식

꾸벅히로 — Sun, 31 May 2009 17:09:07 +0900

비밀키 암호기법에 있어서 가장 큰 문제점은 바로 메세지의 전달자와 수신자가 똑같은 비밀키를 다른 사람들이 모르게 공유해야 한다는 점이다.

특히 메세지의 전달자와 수신자가 물리적으로 서로 떨어져 있다면 그 두사람은 매우 안전한 통신 수단을 이용하여 비밀키를 전달하여야 할 것이다. 만약 공격자가 이 두사람간의 통신경로상에서 비밀키를 얻어낸다면 그 후로부터 메세지의 송신자와 수신자가 그 비밀키를 사용하여 메세지를 암호화한다 하여도 그 공격자는 자신이 훔친 비밀키를 이용하여 모든 메세지를 복호화하여 그 내용을 알 수가 있게 될 것이다. 또한 비밀키 암호기법에 있어서 모든 키들은 그것을 사용하는 두 사람이외에는 아무도 알 수 없도록 비밀리에 보관되어야 하므로 만약 수많은 사람들이 동시에 상호 메세지를 주고 받고자 하는 경우에는 이러한 비밀키의 관리가 매우 어려워진다. 이와 같이 암호화를 위한 키의 생성과 전달 그리고 보관하는 문제 즉, 키의 관리 문제는 암호를 이용한 정보보안에 있어서 중요한 이슈가 되는 문제이다.

비밀키 암호기법이 갖는 위와 같은 키관리의 문제를 해결하기 위해서 제안된 것이 바로 공개키 암호 기법이다. 이것은 1976년 Whitfield Diffie와 Martin Hellman에 의해 제안되었다. 비밀키는 메세지의 송/수신에 참여하는 모든 사람들이 개인적으로 비밀리에 보관하고 있어야 하고 공개키는 공개키 디렉토리에 보관되어 모든 사람들이 자신이 원하는 공개키를 얻을 수 있어야 한다. 그리하여 송신자가 메세지를 보내기 위해 먼저 공개키 디렉토리에서 메세지 수신자의 공개키를 획득한다(실제로는 공개키를 획득하는 과정에서도 암호기법을 이용한 인증절차가 필요하며 공개키를 보관하는 디렉토리의 안전한 관리를 위해 여러가지 방법이 필요하다). 그리고 송신하려는 메세지를 수신자의 공개키를 이용하여 암호화한 후 발송한다. 암호화된 메세지를 받은 수신자는 자신만이 갖고 있는 비밀키를 이용하여 그 메세지를 복호화하여 메세지를 얻는다. 여기에서 반드시 주목해야 할 사실은 바로 비밀키와 공개키는 키의 길이만 동일하고 서로 다른 값을 갖는 키라는 것이다.

공개키 알고리즘 중 RSA 기법은 Rivest, Shamir, Adleman에 의해 개발된 방식으로 지수 승을 가진 수식을 사용하도록 만들어졌다. 평문은 블록으로 암호화된다. 각 블록은 어떤 수 n보다 작은 이진 값을 가진다. 암호와 복호는 평문 블록 M과 암호문 블록 C에 대하여 다음의 형태를 따른다.

C = M^e mod n

M = C^dmod n = (M^e)^d mod n

여기서 n=pq, p와 q는 솟수, d는 정수(단 d는 Φ(n)에 서로소인 정수), 그리고 e= d-1 mod Φ(n) 이다.

송신자 A와 수신자 B는 n의 값을 알아야 한다. 예를 들어 수신자 B의 공개키 KU는 {e,n}으로 구성되고 수신자 B의 KR은 {d,n}으로 구성되어 있을 때 송신자 A는 수신자 B가 공개한 e의 값을 알고 있으며, 수신자 B만이 d의 값을 알고 있다.

만일 사용자 A가 메시지 M을 사용자 B에게 전송하고자 한다면 A는 C =( M^e mod n )을 계산하여 얻은 C를 전송하고 B는 M = C^d mod n을 계산하여 M을 얻게 된다. 즉 e와 d가 mod n의 곱셈에 대한 역원 관계에 있으므로 공개키로 암호화 한 메시지는 개인키로 복호화되며 개인키로 암호화한 메시지는 공개키로 복호화되게 된다. 공개키는 다른 사람들에게 공개하고 개인키는 자신만이 알고 있다는 점을 생각해보면 상대방의 공개키로 암호화한 내용은 상대방만이 복호화할 수 있으며 나의 개인키로 암호화한 메시지는 모든 사람에 의해서 복호화될 수 있다. 결과적으로 상대방의 공개키를 이용한 암호화는 특정 상대방만이 알아볼 수 있게 하기 위한 방안으로 이해될 수 있으며 자신의 개인키를 이용한 암호화는 자신임을 입증하는 전자서명에 효과적으로 이용될 수 있다.

참고적으로 관용 암호방식과 공개키 암호방식의 알고리즘 상의 구성에 있어서의 차이점을 살펴보면 관용 암호방식의 경우는 평문에 대한 연산의 조합이나 재배치를 기반으로 하는 반면에 공개키 암호방식은 지수승이나 mod 연산 등의 수학적 수식을 기반으로 한다는 차이점을 들 수 있다.

요즘 정신이 산만하네요. 산만한 만큼 생각도 많고 매일 고민에 빠져 살고 있습니다.

마지막으로 노무현 전 대통령님 삼가 명복을 빕니다. 꼭 좋은 곳에서 행복하세요.

김제동 어록...

kingstone — Fri, 29 May 2009 23:21:52 +0900

고 노무현 전 대통령님의 유서에 대한 김제동씨의 글입니다.

"나로 말미암아 여러 사람이 받은 고통이 너무 크다 하셨지만 그 분에게 받은 사랑이 크다"

"여생도 남에게 짐이 될 일밖에 없다 하셨지만 우리가 기꺼이 나눠드려야겠다"
"너무 슬퍼하지 말라고 하셨는데 오늘은 좀 슬퍼해야겠다"

"삶과 죽음은 하나라고 하셨는데 우리 가슴 속에 심장이 뛸 때마다 잊지 않겠다"
"미안해하지 말랐는데 좀 미안해하겠다. 지켜드리지 못했다"

"누구도 원망하지 말랬는데 스스로를 원망하겠다"
"운명이라 하셨는데 이 운명만큼은 받아들이지 못하겠다.

"작은 비석만 남기라 하셨는데 우리 가슴 속에 잊혀지지 않는 큰 비석 잊지 않고 세우겠다"
"마음의 뜨거운 열정으로 그 분을, 우리 가슴 속에 한 줌의 재가 아니라 영원토록 살아있는 열정으로 대하겠다"

지지난 대선날, 소주를 마시며 결과를 기다리던때가 생각이 납니다.
"제발"과 "설마"를 연거푸 되뇌이며 소주잔을 기울였지요.
그리고, 믿어지지 않는 결과가 나온덕에 3차까지 달리며 술을 먹었던...

이제와서 무슨 이야기가 필요하겠습니까.
끝까지 투표할때의 마음과 같이 믿어주지 못했던 제가 후회 스럽고 원망스럽습니다.
최소한 저에겐 너무 과분한 대통령이 아니었나 생각합니다.

편히 쉬세요.

▶謹弔◀ 노무현 대통령님 편히 가십시오.

sanmaul — Fri, 29 May 2009 03:39:28 +0900

결국은 사람이라는 생각

희망을 가지게 해준 사람

다 노무현 때문입니다.

국민에게 사랑 받았던 대통령으로 우리들에게 영원히 기억될 것입니다.

안녕히 가십시오.

느낌이 산뜻한 웹서비스 소개

네오케이 — Fri, 22 May 2009 21:45:08 +0900

느낌이 산뜻한 웹서비스를 소개합니다.
이미 많이 알고 있는 사이트겠지만, 순위도 포함해서 정리해 봤습니다.

* 위지아 (wisia)
순위: 713위
분류: 방문자들이 뽑는 랭킹 정보
URL: http://www.wisia.com/
특이사항: NHN을 설립했던 김범수 대표가 만든 사이트

* 윙버스 (WINGBUS)
순위: 966위
분류: 해외 여행 정보 사이트
URL: http://www.wingbus.com/
특이사항: NHN에 2009년 인수됨.

* 스프링노트 (springnote)
   순위: 1261위
   분류: 공유 노트
   URL: http://www.springnote.com/
   특이사항: NCSOFT의 오픈마루 스튜디오가 만든 사이트

* 티워 (TWAR)
순위: 1656위
분류: 게시판형 찬반 사이트
URL: http://www.twar.co.kr
특이사항: 소프트뱅크 투자 자문하는 리트머스에서 지원하는 사이트,
파란 포털에서도 지원하는 중임.

* 미투데이 (me2day)
   순위: 1671위
   분류: 한줄 블로그
   URL: http://me2day.net/
   특이사항: 해외의 트위터와 비슷한 서비스로 NHN에 인수됨.

* 위자드닷컴
   순위: 1819위
   분류: 개인화 웹페이지
   URL: http://wzd.com/
   특이사항: 웹위젯 시장을 선도하는 사이트.

* 온오프믹스 (ONOFFMIX)
순위: 7546위
분류: 모임 및 이벤트 관리 서비스
URL: http://www.onoffmix.com/
특이사항: 티워와 마찬가지로 리트머스에서 지원하는 사이트.

순위는 2009.5.22 랭키닷컴 기준입니다.

이렇게 몇개의 사이트를 보니, nhn과 연관된 사이트가 여럿이군요. 그리고 리트머스가 지원하는 사이트가 몇군데 됩니다.
역시, 순위를 보면 신생 웹서비스가 메이저 웹서비스까지 가는 데는 아직도 험난해 보입니다.

Windows 7에서 SCM(Service Control Manager)의 개선점

erratum — Thu, 30 Apr 2009 21:22:57 +0900

윈도우의 백그라운드 프로세스에는 두 가지 형태가 있다.
하나는 Windows Service이고, 나머지 하나는 Windows Task이다.
현재 윈도우2000 이후의 운영체제를 사용하고 있다면, 이러한 프로그램들을 이미 알게 모르게 사용하고 있을 것이다. 이러한 백그라운드 프로세스는 여러 용도로 사용된다. 유닉스 시스템에서는 데몬이라고 말하는데(죽지 않는다고 해서 붙여진 이름이란다.) 주로 어떤 주기적인 작업이나 시스템이 기동하는 순간부터 종료될 때까지 필요한 작업, 어플리케이션에게 어떤 서비스를 제공하는 기능들을 수행하는 프로그램들이 이러한 형태를 띠게 된다.
Windows Service는 SCM(Serivce Control Manager)를 통해서 제어하게 되고, Windows Task는 Windows Scheduler를 통해서 사용할 수 있다.
이 중에서 조만간 세상에 모습을 드러낼 Windows 7에서 강화된 SCM의 기능에 대해서 이야기 하고자 한다.
서비스는 윈도우가 부팅될 때 함께 시작하는 것들이 있는데, 이러한 서비스가 많아 질수록 운영체제의 부팅 속도에 영향을 주게 된다. 따라서 굳이 부팅과 함께 동작할 필요가 없는 서비스까지 자동으로 시작하게 만들지 않는 것이 효율적인 서비스 프로그램을 만드는 첫 번째 관문이다. 그래서 Windows 7에서는 서비스가 시작할 수 있는 조건을 좀 더 세밀하게 제어할 수 있는 장치가 마련 되었는데 이것을 Trigger Start라고 한다. trigger의 종류로는 첫 번째 IP 주소의 도착, 마지막 IP 주소의 출발, 도메인에 시스템이 join하거나 disjoin하는 것, 하드웨어의 연결, Group policy의 변화와 같은 것들이 포함된다. 서비스 프로그램은 이러한 trigger들을 통해서 시작/중지될 수 있다. 예를 들면 디지털 카메라가 연결되면 이미지 장치 서비스가 동작하는 것이다. 이러한 trigger들은 비교적 빈번히 일어나는 것이 아니기 때문에 부팅과 종료 속도를 개선시킬 수 있고, 서비스의 외부로부터의 공격에 대한 노출을 줄일 수 있으며, 서비스가 사용하는 리소스를 아낄 수 있는 장점이 있다. trigger에 의한 동작은 현재 서비스의 시작과 종료에만 국한되고 다른 동작들은 아직 지원하지 않는다.
Windows 7에 포함되어 있는 command-line service 제어 도구인 sc.exe도 service trigger를 지원하도록 업데이트 되었다. 다음은 sc.exe의 triggerinfo 명령어를 쳤을 때 보이는 help 정보이다.

식사하는 철학자 문제

sanmaul — Thu, 30 Apr 2009 17:21:01 +0900

프로세스의 기아상태를 설명하기 위해 다익스트라(Dijkstra)에 의해 제안된 문제로 자원을 공유하는 동기화된 병행프로세서를 위한 표준 모델

"식사하는 철학자" 문제의 조건

철학자들은 원형테이블을 공유하며, 이 테이블은 5개의 의자로 둘러 싸여 있다. 테이블 중앙에는 한 접시의 음식이 있고, 테이블에는 다섯 개의 젓가락이 놓여있다.

- 철학자가 생각할 때는 다른 동료들과 상호작용하지 않는다.
- 철학자는 배가고프면 자신에 가장 가까이 있는 두개의 젓가락을 집으려고 시도한다.
- 식사 중에는 젓가락을 놓지 않고, 식사를 마치면 젓가락 두개를 모두 놓고 다시 생각을 시작한다.

"식사하는 철학자" 문제에 의한 교착 상태 설명

가. 상호배제(mutual exclusion)
- 철학자는 배가 고프면 자신에게 가까운 양쪽의 젓가락을 집어야 식사가 가능하다. 하지만 옆의 다른 철학자가 이미 젓가락을 집어서 사용하고 있으면 식사를 마치고 젓가락을 놓을 때까지 대기 하여야 한다.
- 이것은 상호배제(mutual exclusion) 조건으로 최소한 하나의 자원이 비공유 모드로 점유되어 어느 자원에 대해 한 프로세스가 이미 사용 중이면 다른 프로세스는 기다려야 하는 것을 보여준다.
나. 점유와 대기(Hold and wait)
- 배고픈 철학자는 자신의 양옆 중 놓여있는 젓가락을 사용하기 위해 하나를 집고, 다른 철학자가 쓰고 있는 다른 하나의 젓가락을 식사가 끝마쳐져서 놓여지기를 기다리는 경우가 발생
- 이것은 점유와 대기(Hold and wait) 조건으로 하나 이상의 자원을 할당받은 채로 나머지 자원을 할당 받기 위해 다른 프로세스의 자원이 해제되기를 기다리는 프로세스가 존재하는 경우이다.
다. 비선점(Nopreemption)
- 젓가락은 미리 선점할 수 없다. 즉 젓가락을 집고 있는 중 강제로 방출할 수 없으며, 식사를 마친 철학자가 젓가락을 자발적으로만 놓을 때만 사용 가능하다.
- 이것은 자원을 할당받은 프로세스로부터 자원을 강제로 빼앗지 못하는 비선점(Nopreemption) 조건이다.
라. 순환대기(circular wait)
- 철학자1은 철학자2가 가지고 있는 젓가락을 내려놓기를 기다리고 있고, 철학자2는 철학자3을, 철학자3은 철학자4를, 철학자4는 철학자5를, 철학자5는 철학자1의 젓가락을 기다리는 상황이 발생
- 이것은 자원 할당 그래프 상에서 프로세스의 환형 사슬이 존재하는 것으로 순환대기(circular wait) 조건이다.

∴ 교착상태 발생은 다익스트라(Dijkstra)가 "식사하는 철학자" 문제에서 설명했던 상호배제, 점유와 대기, 비선점, 순환대기의 4가지 원인이 동시에 성립되어야 발생한다.

regular expresion 3 대해

myidojh — Thu, 30 Apr 2009 14:21:12 +0900

고수 : 프로그래머라면 regular expression을 다양한 언어에서 능수 능란하게 사용해야 돼!
regular expresion 2에서 php와 javascript로 했으니 마지막으로 . python이나 java로 같은 문제를 풀어바.
문제 : html의 img의 src를 읽어와서 output으로 뿌려라.

나 : 옙. 그럼 python으로 풀어 볼게요.

python 프로그램 환경 설정.

▶python 필수 환경

1. 최신 버젼 설치(http://www.python.org/download/)

2009년 4월 30일 현재 : 2.6.2

2. python용 debug 설치

2-1. CPython 설치(http://www.python.org/download/)

2-1. python 버젼에 맞는 wxPython 설치(http://www.wxpython.org/)

python용 GUI toolkit

2-2. python dbg(winpdg) 설치(http://winpdb.org/)

2009년 4월 30일 현재 : 1.4.6

3. python 예제 flle url: http://docs.python.org/tutorial/

4. python help file 기본 url: http://docs.python.org/reference/index.html

5. python help file 모듈 url: http://docs.python.org/library/index.html

▶python Shell 사용법

1. py파일에서 Edit with IDLE 실행.

▶python debug 사용법

1. py파일에 윈도우 마우스 오른쪽 키 연결.

C:\Python24\Scripts\winpdb_start.bat 를 아래의 코드로 만든다.

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

@echo off

start "" "C:\Python24\Scripts\winpdb_.pyw" %1

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

아래와 같이 입력

[HKEY_CLASSES_ROOT\Python.File\shell\Run with Winpdbg]

[HKEY_CLASSES_ROOT\Python.File\shell\Run with Winpdbg\command]
@="\"C:\\Python24\\Scripts\\winpdb_start.bat\" \"%1\""

2. 기본 명령어 확인 방법

cmd 창에서 help를 치면 확인 가능

launch를 실행하면 debug를 실행시킨 폴더에 있는 파일을 debugging 할 수 있다.

python에서 regular expression을 사용하는 방법.

python에서는 Re라는 객체를 제공해준다.
(http://docs.python.org/library/re.html)

re.complie(pattern,flag)
생성 시에 두번째 파라미터의 의미
re.I:대소문자 구분하지 않음
re.M: multiline 지원

compile.match()

사용법
import re
pattern = re.compile("pattern",옵션)
data = patern.match("원문")

제공하는 함수
library 참고.

검색결과의 부분 이용하기(Backreference)
data.group();
data.groups();

python으로 푼 내용.

import re

def displaymatch(match):
    if match is None:
        return None
    return '%s' % match.groups(0)

htmlfile = open('test.html','r')
lines = htmlfile.readlines()

imgsrc = re.compile("\<img src=[\\\"\\\']?([^\>^\\\"^\\\']+)[^\>]*/?\>",re.I)
for value in lines :
result = displaymatch(imgsrc.match(value))
if ( result != None ) : print result

htmlfile.close()

보안트랜드의 변화

kingstone — Wed, 29 Apr 2009 22:00:27 +0900

기존의 보안 파라다임은 외부에 있는 공격자로부터 내부의 리소스를 보호하는데에 주력하였었다. 하지만, 요 몇년사이에 그 패러다임이 변화하고 있다.
물론 외부에 대한 공격자에 대한 중요성이 감소한 것은 아니고, 그러한 보안은 이젠 당연시 되고 있다. 고전적인 보안 파라다임은 네트웍을 untrusted network과 trusted network으로 구분하고, untrusted에서의 네트웍에 대한 보안이나, untrusted 구간에서 공격해 들어오는 공격자로부터 trusted network의 리소스를 보호하는 것이었다.

그러나, 요즘 진화하며 중요성이 부각되고 있는 부분은 내부 사용자에 의한 공격 및 자료 유출등과 같은 부분에 대한 보안성이다.
즉, 신뢰받고, 인증 받은 사용자만이 내부 리소스를 사용할 수 있고, 내부 리소스를 외부로 무단 유출하는 것을 방지하는 보안에 대한 중요성이 부각되고 있다.

대표적인 솔루션들이 NAC(Network Access Control), DLP(Data Loss Prevention), DRM 등이다. 특히, NAC과 DLP는 관심을 많이 받고 있는 솔루션이다.

아래는 DLP에 대한 기사내용이다.

이제 막 시장을 형성하기 시작한 데이터유출방지(DLP: Data Loss Prevention) 솔루션이 올해 내부정보유출방지 시장의 핵심 솔루션으로 급부상할 전망이다.

이 가운데 기밀 자료 유출 문제가 심각한 제조사나 공공기관은 물론, 원천 기술을 보유한 중소업체, 재무데이터가 유출되면 안 되는 작은 규모의 외국계 업체나 회계법인 등에 이르기까지 최근 데이터유출방지 솔루션 도입에 대한 요구가 높아지고 있어 해당업체들은 올해 DLP 시장만 50억원 이상 규모를 형성할 것으로 보고 있다.

DLP솔루션은 고의 혹은 실수로 인한 기밀 정보 유출을 원천적으로 방지하는 솔루션으로, 네트워크 상에 저장되어 있는 정보와 네트워크에 연결되지 않은 엔드포인트의 정보를 보호함은 물론, 어떠한 네트워크 게이트웨이, 엔드포인트로도 정보가 빠져나가지 못하도록 할 수 있다는 게 해당업체들의 설명이다.

메일보안, DRM 등의 전문솔루션들도 DLP기능을 표방하고 있으나, DLP 솔루션 업체들은 컨텐트 모니터링, 필터링 및 데이터 손실 방지를 목표로 네트워크, 엔드포인트 모두를 포괄해 일관성 있는 정책 적용, 높은 가치를 지닌 이벤트 분석 능력과 정책 위반 사항에 대한 경고 및 수정 프로세스를 구현할 수 있는 중앙 집중적인 관리 콘솔을 갖추고 있다는 점에서 차별화 된다고 주장하고 있다.

◆DRM에서 DLP로 방향 선회···'일부 DRM 시장 수요 대체'= 맥아피와 시만텍은 각각 데이터 유출방지 전문 업체인 본투(Vontu)사와 세이프부트(SafeBoot)사를 인수하며 2007년 하반기 부터 DLP사업을 강화하고 있으며, 국내 업체인 소만사와 컴트루테크놀로지도 각각 내부정보유출방지, 매체제어, 유해사이트 차단 기능 등을 지원하는 '메일아이(Mail-i)와 웹키퍼', '넷센터'를 내세워 DLP사업을 펼치고 있다.

뿐만 아니라 시스코는 안티스팸 및 안티스파이웨어 사업본부인 아이언포트 시스템즈(www.ironport.com)에서 전 제품 라인에 데이터유출방지 및 이메일 암호화 기능을 보강했으며, 트렌드마이크로도 데이터유출방지 전문업체인 프로빌라(Provilla)사 인수 이후 시장 진입을 지속 검토 중이다.

최근들어 한국맥아피는 굵직한 DLP 레퍼런스로 3-4곳 정도를 확보했고 국내 총 20여곳에 DLP솔루션을 공급했다. 시만텍코리아 역시 최근 국내 제조사 한 곳과 계약을 체결하고, 추가 2-3곳과도 DLP 솔루션 공급을 위한 계약 체결을 앞두고 있다고 밝혔다.

해당 업계는 "DRM 도입 예산을 책정한 기업이나 DRM 예산 확보를 기획하고 있던 기업들을 중심으로 최근 DLP 수요가 이어지고 있다. 이는 DRM 솔루션 이용 시 협업 및 데이터 공유에 번거로움을 우려하고 있기 때문"이라며 "앞으로 DLP 시장이 일부 DRM 시장을 대체해 나갈 것으로 예상된다"고 말했다.

특히, DRM 솔루션을 도입하지 않은 기업들의 경우, 기밀정보유출방지 솔루션 도입 시 'DRM이냐 DLP냐'를 놓고 고민을 하고 있기 때문에 DLP 솔루션을 공급하는 업체들은 DRM과 DLP의 차이점을 알리는 데 주력하고 있다. 맥아피와 시만텍은 "DRM 솔루션이 데이터 이용 권한을 부여해 해커나 외부자로 부터 정보 접근을 막는 액세스 컨트롤에 목적을 두고 있는 반면, DLP 솔루션은 데이터 이용 권한을 지닌 내부자들에 대한 통제까지도 가능하다"고 강조했다.

◆DLP솔루션 봇물…'기능 차별화로 승부'= 소만사와 컴트루테크놀로지 등 국산 DLP솔루션 업체들은 보안USB, 백신 탑재, 통합PC보안 제품과의 연동, 매체제어 기능 등을 추가, 내부정보유출방지 기능을 강화하여 공공, 금융 시장을 집중 공략하고 있다.

소만사는 98년 출시한 자사의 주력 제품인 메일아이를 국내 다수 대기업과 500개이상 기업들이 도입한 데이터 유출방지 솔루션이라고 소개하고 있다. 소만사는 "다양한 종류의 이메일, 웹메일, 메신저 등을 통한 정보유출을 방지할 수 있는 제품으로, 네이트온 등 국내 복잡하고 특수한 환경에 맞는 운영 지원, 상세한 프로토콜 지원 등 커버리지 면에서 여타 경쟁 솔루션들에 비해 앞서 있다"고 전했다.

컴트루테크놀로지는 최근에 관세청(망분리 사업)을 비롯해서 농촌진흥청, 성남문화재단에 자사의 내부정보유출방지 솔루션 '넷센터'를 공급했으며 2006년 출시 이후 국내 20여곳의 레퍼런스 사이트를 확보하고 있다고 말했다.

컴트루테크놀로지는 "넷센터는 상용메일 차단과 같은 접속 차단뿐만 아니라 키워드 등으로 차단할 수 있는 컨텐츠필터, IP 차단, 첨부파일 전송차단 등 다양한 내부정보유출 방지 기능을 제공한다. 기업들이 정보유출사고 발생 시 신속히 데이터를 불러와 해결할 수 있도록 아카이빙시스템과 연동하는 방향으로 제품을 발전시킬 계획"이라고 밝혔다.

한편, 외산 DLP솔루션은 ▲쉬고 있는 데이터 보호(스토리지) ▲움직이는 데이터 보호(카피, 메일) ▲사용 중인 데이터 보호(보고 있는 문서의 프린트 스크린, 중요 부분 복사 등을 통한 데이터 유출 방지)를 핵심 기능으로 지원한다. 노트북 분실이나 하드디스크 도난 시에도 데이터가 유출되지 않도록 하며, 데이터검색 기능과 화면 캡쳐, 프린트 방지 기능 등을 점차 강화해 가고 있다.