대회 종료 10일 10시 ~ 11일 20시

[최종 결과]

대회 종료 직후 최종 결과 집계!

대회 전 예상했던 인물들도 몇몇 보이고, 예상치 못했던 인물들도 몇몇 보였다.

빼빼로 데이라서 그런지 여자친구랑 놀러가서 제대로 참가를 못한 학생들도 다수였다. 그래서 그런지 참가율이 매우 저조하여 트래픽이 과부하 되는 일은 발생하지 않았다.

슬프다.

[대회 규칙]

대회 룰 중에 가장 이슈가 되었던건 보너스 문제의 경우 브레이크 쓰루(처음으로 문제를 푼 사람)에게 먹을 거리를 준다는 것!!

기획상으론 원래 피자나 치킨같은거 미리 기프티콘으로 사놨다가 애들 폰으로 바로 전송해주려 했는데, 기획 기간 내내 뭐사지 뭐사지 하다가 못하고 말았다 -_-;;ㅋㅋㅋㅋㅋㅋㅋ

그래서 뒤늦게나마 그냥 3만원 이내로 먹고싶은거 아무거나 말하면 기프티콘으로 보내준다고 했다! 굿ㅋ

사실 기획상으론 이벤트는 보너스 문제 뿐만 아니라 IRC에서도 자잘한 이벤트 해서 줄려고 했는데 예산 때문에 무산되고 말았다 ㅜㅜ 빼빼로 줄려 했는뎅..

[공지]

다소 부산스러워 보이지만.. 거의 모든 이벤트를 기록해 놓은 Notice 메뉴

형식도 따로 정해져 있지 않고 그냥 중요하다 생각되는 내용을 마구잡이로 집어넣어서 그렇게 보이는 듯 싶다.

내년엔 좀 더 깔끔하게 만들 방법을 생각해봐야겠다!

[EndTime]

대회는 11월 10일 10시부터 11월 11일 20시까지 진행되었다.

진행 상황은 위 EndTime에서 퍼센트로 표시해주었고, 마지막 1%는 일명 '/발광' 이라는 네이트온 이모티콘을 사용하여 긴박함을 나타내었다 (참고로 움직인다!).

나름 괜찮긴 했는데 퍼센트가 아니라 초단위의 시간으로 표시를 했으면 좀 더 확실했을 거란 생각이 뒤늦게 든다.

[Challenge Map]

가장 문제가 많았던 챌린지 맵 ㅠㅠ

사실 기획할 때 도트 맵 말고 다른걸 해보려 했는데 여러 문제로 인해 실패하였고..(가장 큰 문제는 챌린지 메뉴 만들때가 대회 하루 전이였음)

결국 그나마 깔끔해 보였던 이것을 선택한 것..

대회 시작 전부터 이게 사용자 입장에서 불편할 것이란 생각을 했지만 아무래도 시간이 없어서 그저 서둘렀던 것 같다.

이 점에 대해서는 참가자들에게 상당히 죄송스런 마음 밖에 들지 않는다.. 그저 시간 맞춰서 반드시 대회를 열어야겠다는 생각 밖에 ㅜㅜ

또 나중에 가니 IRC에서 푼 문제는 초록색 점으로 만들어 달라고 하길래 오래걸려서 만들긴 했는데 막상 테스트 페이지에 실험해보니 제대로 동작하지도 않고..

그냥 겁나 멘붕이였습니다 ㅜㅜ;; 죄송합니다..

결국 /prob/로 대체..ㅠㅠ

8월부터 기획해온 대회가 이틀만에 끝이라니..!!!!!!!!!!

이런 기분은 수능 이후로 처음인 것 같다 ㅋ..

첫 대회 치고는 가장 걱정했던 트래픽 과부하 문제가 발생하지 않아서 좋았지만..

그 보다 큰 문제가 자잘하게 발생했던 것 같다..

처음 시작부터 데이터베이스 밀림 현상이 발생하는가 하면.. 수시로 키 값이 매치되지 않는 사태가 발생하고, 문제 세팅도 잘못되는 일이 허다하게 발생..

지금와서 생각해보면 너무 설렁설렁 기획을 한게 아닌가 싶고.. 그저 내년엔 절대 이런 일이 발생하지 않도록 공부를 더 열심히해야겠다는 생각밖에 들지 않는다.

확실히 대회를 직접 운영해보니 이런 느낌이 더 절실히 와닿는 것 같다 ㅋ..

혹시나 그밖에 대회에 궁금한 사항이 있으신 분께선 

http://facebook.com/extr00 으로 연락주세요~

sadsadsad

javascript.zip

윈도우 메모리

파일로서의 메모리

파일로서의 메모리는 동적으로 존재하는 메모리와는 달리, 그 내용이 변하지 않으며 메모리 관련 API가 아닌 파일 시스템 API를 통해 접근을 할 수 있다.

시스템 메모리

시스템 메모리는 보통 물리적 메모리를 의미한다. 1차 저장장치인 RAM과 여기에 추가적으로 하드 드라이브가 보조 장치로써 2차 저장장치가 될 수 있다.

그런데 이러한 물리 메모리가 아닌 가상 메모리라는 것도 존재다. 가상 메모리란 멀티태스킹 능력을 확장시키기 위해 페이징 기법을 사용하는 기술로써, 루트 폴더의 PageFile.sys 파일에 기록한다.

또한 여기서 간단히 짚고 넘어가야 할 문제가 있다. 물리적 메모리의 정의가 철저해져야 할 필요가 있다는 것이다.

물리 메모리(시스템 메모리)는 RAM만을 뜻하는 것이 아닌 RAM과 Page File 두 가지를 의미하는 것이다. 

하지만, 그렇다고 해서 메모리 덤프 시에 RAM과 Page File 두 가지가 모두 덤핑이 되는 것은 아니다. 이 경우, RAM만이 덤프가 된다.

또한, 프로세스 덤프를 하게 되면 가상 메모리에 대한 덤프가 되기 때문에 RAM과 Page File 모두 사용하는 가상 메모리로썬 모두 덤프할 수 밖에 없다.

가상 메모리

일반적인 물리 형태의 메모리가 아닌 논리 형태의 메모리이다.

가상 메모리의 데이터 저장 형태는 RAM이나 Page File 같은 물리적 메모리 또는 하드 드라이브에 저장되며, 할당되는 주소도 물리 메모리와는 달리 VAS(Virtual Adress Space)라는 주소 공간을 따로 할당 받게 된다.

또한 32비트 기준으로, 윈도우의 모든 프로세스는 개별적으로 4GB의 가상 메모리를 할당받는다. 

어디까지나 ‘가상’ 메모리라서 가능한 점이다. 또한, 가상 메모리는 물리 메모리 뿐만 아니라 하드 드라이브(Page File)도 주소 공간으로 사용한다.

가상 메모리의 특징을 몇 가지 간추려 보자면 다음 표와 같다.

가상 메모리의 구조

32비트 기준으로 가상 메모리의 구조는 위의 그림과 같다. 

실제 하나의 사용자 프로세스가 사용할 수 있는 영역은 사용자 영역 2GB로 제한되어 있으며, 이는 사용자 모드로 동작하기 때문에 커널 영역에 진입할 수 없다. 

커널 영역은 오직 커널 모드로 동작하는 프로세스만 진입 가능하다.

또한 사용자 영역은 boot.ini에서 ‘/3GB’ 옵션을 붙여 재부팅하게 되면 사용자 영역을 3GB로 증설하고, 커널 영역을 1GB로 축소 시킬 수 있는데, 이러한 경우 한 번에 실행할 수 있는 프로세스의 개수가 줄어들게 된다.

그리고 커널 영역은 모든 프로세스에게 공통적인 영역이라서 다른 프로세스의 다른 커널영역이라도 두 커널 내의 오브젝트가 가지고 있는 Virtual Address는 동일하다.

커널 영역은 시스템 운영에 사용되기 때문에 Page File보다는 RAM에 저장되며, 가상 주소에 매핑된다.

사용자 영역은 당장 필요 없다고 판단되는 데이터는 Page File로 이동 시키고, 프로세스가 요청할 경우 RAM으로 올린다.

그렇기 때문에 온전한 사용자 데이터를 얻기 위해서는 RAM+Page File을 추출해야만 얻을 수 있다.

가상 메모리 주소와 물리 메모리 주소 간의 주소 변환

모든 프로세스의 가상 메모리는 가상 주소와 실제 주소가 다르기 때문에 매핑을 시켜주어야 한다. 이는 MMU(Memory Management Unit)에 의해 이루어지며, 반드시 필요한 작업이다.

가령 위와 같이 서로 다른 프로세스가 같은 가상 주소에 다른 데이터를 저장하였더라도, 매핑되어있는 물리 주소가 다르기 때문에 실제론 다른 공간에 저장된다.

그렇다면 어떻게 매핑 정보를 알 수 있는 것일까?

가상 메모리의 주소는 32비트 시스템에서는 32비트의 길이를 갖는다.

이 가상 메모리의 주소가 물리 메모리의 주소로 변환될 땐 Page Directory라는 테이블과 Page Table이라는 테이블, 그리고 하나의

가상 주소를 이용한 물리 주소 찾기

- 메모리는 페이지(Page)라는 단위로 불리는 일정 크기의 물리적 단위를 사용하여 물리 메모리를 관리하는데 가상 주소와 물리 주소의 매핑 또한 이 페이지를 기준으로 이루어진다.

각각의 페이지는 첫 번째 페이지부터 0번 순서가 매겨지며, 이 번호를 페이지 프레임 넘버(Page Frame Number)라고 한다. 가상 주소의 구조는 다음과 같다.

위와 같은 정보를 이용하여 가상 주소를 토대로 물리 주소를 찾을 수 있다.

방법은 다음과 같다.

 위의 순서를 그림대로 표현하자면 다음과 같다.