견우의 블로그 http://cjhnim.egloos.com ...다시 시작해봅니다.... ko Sat, 18 Oct 2008 09:43:11 GMT Egloos 견우의 블로그 http://pds7.egloos.com/logo/200806/04/67/b0001167.jpg http://cjhnim.egloos.com 80 107 ...다시 시작해봅니다.... <![CDATA[ 무당벌레 ]]> http://cjhnim.egloos.com/3946811 http://cjhnim.egloos.com/3946811 이제 저도 앞으로 1년후엔 저자리에서 발표를 해야하는데
지금까지 준비하나도 한 것이 없음을 절로 느끼는 자리였지요.!!!
....
한번 할꺼면 좀 멋지게 논문을 쓰고 싶은데 방법은 없을까요?....
....

아래사진은 오늘 자전거 타다가
우연히 찍은 무당벌레입니다. 햇살이 따뜻해서
밖에서 운동하기 참좋네요...
기분도 절로 좋아지고요...
]]> PHOTO http://cjhnim.egloos.com/3946811#comments Sat, 18 Oct 2008 09:43:11 GMT 견우 <![CDATA[ 불꽃축제 ]]> http://cjhnim.egloos.com/3938176 http://cjhnim.egloos.com/3938176 크롭하니까... 나름 괜찮네요~

내 인생도 펑펑 불꽃처럼 살면 좋겠습니다.!
]]> PHOTO http://cjhnim.egloos.com/3938176#comments Sat, 11 Oct 2008 14:33:15 GMT 견우 <![CDATA[ 제주도 러브랜드... ]]> http://cjhnim.egloos.com/3938108 http://cjhnim.egloos.com/3938108 여행마지막날이 되서야 겨울 맑은 하늘을 볼 수 있었지...

]]> PHOTO http://cjhnim.egloos.com/3938108#comments Sat, 11 Oct 2008 13:54:17 GMT 견우 <![CDATA[ 제부도... ]]> http://cjhnim.egloos.com/3938050 http://cjhnim.egloos.com/3938050 사람은 사라지고...
흙만 남았구나....
]]> PHOTO http://cjhnim.egloos.com/3938050#comments Sat, 11 Oct 2008 13:21:23 GMT 견우 <![CDATA[ 가을하이킹.... ]]> http://cjhnim.egloos.com/3938029 http://cjhnim.egloos.com/3938029 진하게 물든 가을길
.............
의외로 우리가 사는 곳은 아름답다....
다만 이를 느끼지 못하는 차가운 가슴만 존재할뿐.
]]> PHOTO http://cjhnim.egloos.com/3938029#comments Sat, 11 Oct 2008 13:10:35 GMT 견우 <![CDATA[ 중랑천 가을길 ]]> http://cjhnim.egloos.com/3938014 http://cjhnim.egloos.com/3938014

가을이다.... ]]> PHOTO http://cjhnim.egloos.com/3938014#comments Sat, 11 Oct 2008 13:02:23 GMT 견우 <![CDATA[ Nagle's Algorithm vs Delayed ACK ]]> http://cjhnim.egloos.com/3934879 http://cjhnim.egloos.com/3934879 Nagle's Algorithm

TCP를 통해서 패킷을 전송할 때,
전송한 패킷에 대한 ACK가 올 때까지
기다린 후 그다음 패킷을 전송하는 매커니즘을 뜻합니다.
이런 방법을 사용함으로써
ACK가 수신하기 전까지 버퍼에 쌓인 패킷들을 한번에
보냄으로써 전체적인 패킷 개수를 줄여 traffic을 감소시키는 목적이라고 합니다.

하지만, ACK가 올 때까지 다음 패킷 전송이 대기하기 때문에
응답성이 떨어지는 단점을 초래합니다. 어플리케이션에 따라서 오히려
이 알고리즘을 적용하지 않는 것이 도움이 되기도 합니다. 그래서
소켓 API를 이용해서 이를 사용하지않도록 설정 가능합니다.

BOOL option = TRUE ;
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, &option, sizeof option) ;

TDI단에서도 마찬가지로 설정가능합니다. 간단히
Flag를  TDI_SEND_NO_RESPONSE_EXPECTED로 설정하면됩니다.

TdiBuildSend( ... , TDI_SEND_NO_RESPONSE_EXPECTED , ...) ;

좀더 복잡한 방법으로는
IOCTL_TCP_SET_INFORMATION_EX의 IRP를 생성 시켜
TCP_REQUEST_SET_INFORMATION_EX구조체의  toi_id필드를
TCP_SOCKET_NODELAY 로 설정하는 방법으로도 가능합니다.



Delayed ACK

이것은 수신측입장에서 패킷을 받았을 때 이에 대하여 바로 ACK를 주는 것이 아니라
시간을 좀더 기다리다가 만약 패킷 전송할 게 생긴다면 이 때 ACK를 함께 실어 두는 방식입니다.
(약 200ms 정도 기다린다고합니다.) 이렇게 데이터와 함께 ACK를 실어서
마찬가지로 효율성을 증대하기 위함이지요...

 HKEY_LOCAL_MACHINE \SYSTEM \ CurrentControlSet\\Services \Tcpip \Parameters \Interfaces \{Adapter-id}\TcpAckFrequency 를 1값으로 설정하면 Delayed ACK 또한 해제할 수 있습니다만
전역적으로 설정되는 것이라서 실제 제품에 적용하기에는 무리가 있습니다.

즉 만약 위의 2가지 알고리즘이 모두 적용되어 있다면 최악의 경우에
패킷을 보내고 200ms 후에 ACK가 전송되는 경우가 생길 수 있습니다.
즉 송신측에서는 200ms 마다 데이터가 전송되는 것이지요~.....
이렇게된다면, 전체적인 성능이 확 떨어지게 될 것입니다.
따라서, 내가 만들고자하는 어플리케이션의 용도가 무엇인지 정확하게 판단하고
이를 사용할 것인지 아닌지를 결정해야 할것입니다.

]]> WORK http://cjhnim.egloos.com/3934879#comments Thu, 09 Oct 2008 01:17:15 GMT 견우 <![CDATA[ 2008.9.20 ~ 21 춘천가는 자전거 ]]> http://cjhnim.egloos.com/3913658 http://cjhnim.egloos.com/3913658

비가 내리니 운치있구나.. ]]> TRAVEL http://cjhnim.egloos.com/3913658#comments Mon, 22 Sep 2008 14:51:52 GMT 견우 <![CDATA[ 2008.9.20 ~ 21 춘천가는 자전거 ]]> http://cjhnim.egloos.com/3912050 http://cjhnim.egloos.com/3912050 1박2일간 짧다하면 짧고 길다고하면 긴~ 하이킹 여행을 다녀왔습니다.
타이어 펑크 2회, 브레이크 고장 1회 등 잦은 사고가 있었던 여행이었지만
그래도 안전하게 돌아왔습니다.^^

좋은 후배들과 즐거운 시간을 함께할 수 있어서 더욱 좋았습니다.
그리고 춘천가는 동안 눈 앞에 펼쳐진 풍경들도 너무 좋았었고요.
그리고 자전거를 타고 빗속을 뚫고 가는 경험도 새로왔지요..^^

.... 아래는 자전거 여행 동안 찍은 풍경들인데
건진 풍경이 몇가지 안되네요..^^.....

아~ 이제 어디로 가볼까나!





]]> TRAVEL http://cjhnim.egloos.com/3912050#comments Sun, 21 Sep 2008 12:26:11 GMT 견우 <![CDATA[ 덤프분석하다 IRQL이 FF인 것을 경험해보셨다면..읽어보세요~ ]]> http://cjhnim.egloos.com/3909185 http://cjhnim.egloos.com/3909185 오늘 작업을 하다가
우연히 KeGetCurrentIrql 내부를 분석해보게 되었습니다.

KeGetCurrentIrql의 ASM 코드

1: kd> u hal!kegetcurrentirql
hal!KeGetCurrentIrql:
806e6428 a18000feff      mov     eax,dword ptr ds:[FFFE0080h]
806e642d c1e804          shr     eax,4
806e6430 0fb68018126f80  movzx   eax,byte ptr hal!HalpVectorToIRQL (806f1218)[eax]
806e6437 c3              ret

간단하게 보면 FFFE0080의 내용을 EAX에 넣고
HalpVertorToIRQL이라는 함수를 통하여 EAX에 대응하는
IRQL 값을 얻는 것이죠...

그래서 실제로 그런지 그냥 무심코 디버깅해보았습니다.

1: kd> p
hello!DriverEntry+0x13:
bafbf4c3 ff1580f5fbba    call    dword ptr [hello!_imp__KeGetCurrentIrql (bafbf580)]

==> KeGetCurrentIrql 안으로 진입합니다.
1: kd> t
806e6428 a18000feff      mov     eax,dword ptr ds:[FFFE0080h]

==> FFFE0080의 값이 FF임을 확인하고요
1: kd> dd fffe0080 l1
fffe0080  000000ff

==> 한 스텝 실행합니다.
1: kd> p
806e642d c1e804          shr     eax,4

==> EAX값을 확인하였더니.. FF가 아닌 0 이 들어있습니다..
1: kd> r eax
eax=00000000

음.. 왜그럴까요? 분명 우리가 처음 확인하였을땐 FF값이었는데
실제로 들어간 값은 0 입니다....-.-;;;
처음엔 이게 왜그런지 몰라서..한참 해맸습니다만,
결국.. FF 라는 값은 현재 디버거가 attach하였기 때문에
그에 대응하는 IRQL로 변경이 된것입니다.

그리고 디버거가 detach되면, 원래 IRQL로 원복이 되고 그때의 값이 0 이 되는 것이죠...

사실 FFFE0080 이 값은 APIC의 TPR(Task Priority Register)를 가르킨다고합니다..
APIC는 주소 FFFE0000과 매핑이되어있고 APIC중에 한 레지스터인 TPR은 FFFE0080에
매핑되어 있는 것이죠...

이 TPR은 인터럽트가 발생할때 현재 인터럽트에 대한 우선순위 값을 가지고 있는 것인데요
이 값은 운영체제가 설정을 해준다고 합니다...
즉 IRQL을 구한닫는 것은 APIC의 TPR의 값을 가지고 와서
HalpVectorToIRQL 라는 함수를 통해 IRQL을 획득하는 것이지요..

실제로 디버거가 붙어있을 때 TPR값은 !apic명령으로도 확인가능합니다.

1: kd> !apic
Apic @ fffe0000  ID:1 (50014)  LogDesc:02000000  DestFmt:ffffffff  TPR FF
TimeCnt: 09e8c610clk  SpurVec:1f  FaultVec:e3  error:0
Ipi Cmd: 000008e1  Vec:E1  FixedDel  Lg:01000000      edg  high            
Timer..: 000300fd  Vec:FD  FixedDel    Dest=Self      edg  high       masked
Linti0.: 0001001f  Vec:1F  FixedDel    Dest=Self      edg  high       masked
Linti1.: 000004ff  Vec:FF  NMI         Dest=Self      edg  high            
TMR:
IRR:
ISR:

어째든.. 이번 경우엔
디버거가 attach되어있을때는 TPR값이 바뀌기 때문에 이와 같이
메모리(FFFE0080h)에서 확인한 값과 실제 레지스터(eax)가 다른 현상이 발생한 것이었습니다.

덤프를 받아보시면, 현재 IRQL이 FF라고 나와있는 경우를 종종 경험하셨을것입니다.
이걸 보시고 IRQL이 왜이리 높아졌지?.. 이런경우도있나?.. 그래서 죽었나?
이렇게 생각하신분들 계실것입니다.

사실 이것도 bugcheck가 발생하면서 윈도우즈가 APIC의 TPR을 FF로 바꾸었기 때문에
덤프에 그런 흔적이 남아있는 것으로 생각하면됩니다.
실제 IRQL은 얼마였는지는 알수가 없죠...^^...

좀더 자세한 내용은 APIC(Advanced Programmable Controller)의 TPR레지스터를
찾아보시면, 좀더 이해가 쉬울 것이라고 생각이 되네요...^^
저는 여기까지만 확인하고 더 깊숙히 공부하는 것은..남겨두었답니다...




]]> WORK http://cjhnim.egloos.com/3909185#comments Fri, 19 Sep 2008 02:31:22 GMT 견우