썰렁한 엔지니어

소켓 프로그램에서 송수신으로 가장 많이 사용되는 것은 recv,send 와 recvfrom, sendto 일 것이다. 전자를 TCP 용 후자를 UDP 용으로 흔히 알고 사용하는데, 그 이유는 연결지향형이 아닌 경우 매 패킷마다 주소지가 다른 데이터가 올라 올 수 있기 때문에 주소를 받거나 보낼 수 있는 시스템 콜을 사용하게 된다. UDP의 경우 기대되는 데이터의 흐름은 다음과 같다. 서버 1. UDP 서버가 대기 2. 패킷 및 클라이언트 주소 수신 3. 클라이언트 주소로 응답 송신 클라이언트 1. 서버주소 및 요구사항 송신 2. 패킷 및 서버 주소 수신 여기서 주의할 점이 클라이언트가 데이터를 송신하고서 recvfrom 으로 대기하고 있다면, 서버가 아닌 다른 누군가가 패킷을 쏜다면 (이것은 네트웍 중간..

TCP/IP 서버를 만들때는 다음과 같은 방법으로 만들게 된다. 1. 소켓 생성 2. bind 3. listen 4. accept 로 클라이언트 소켓 생성 소켓 프로그램을 처음하는 사람들이 겪게 되는 의문 중의 하나는 무엇에다가 묶고(bind), 듣기전까지는 어떤 일이 일어나길래 들어야(listen)하는가인데, 여기에는 발상의 전환이 필요하다. 일반적으로 파일을 열고 파일에서 읽는 과정을 생각해보면, 이미 경로라는 구별되어 있는 개체가 존재하고 그것을 다루기 위한 기술자(descriptor)를 만들어 기술자를 모든 파일 관련 입출력 함수에 인자로 넘기게 되는데, 소켓 프로그램은 그 반대라는 것이 중요하다. 기술자(socket)를 먼저 만들고, 그 기술자를 구별될 수 있는 경로 혹은 주소에 가져다가 붙이는..

컴파일러 캐시(ccache)와 gcc 3.4 이상이나 Visual Studio가 지원하는 미리 컴파일된 헤더(Precompiled Header; pch)의 주 목적은 컴파일 속도를 높히는데 있다. 간단히 이들의 원리를 설명하자면, 컴파일러 캐시는 PATH상에서 먼저 설치 돼있는, gcc로 이름이 바뀌어 있는 ccache가 gcc를 실행시킬때 수행되어 PATH의 이하 부분에 오는 실제 gcc를 자식 프로세스로 실행하면서, gcc의 버전, gcc의 전처리 결과(gcc -E) command line 인자 등을 분석하여 동일한 실행 명령과 전처리 결과가 오면, 컴파일을 수행하지 않고 이전에 컴파일 결과로 나온 목적파일(Object file)을 현재 시각으로 복사해서 만들어주는 일을 한는 것이며, 미리 컴파일된 ..

http://bbs.kldp.org/viewtopic.php?t=768 여기에 썼던글이다. (drupal로 이관하면서 이관된 문서를 찾으려 했으나 역부족.) 본 글은 IP 주소를 얻는 방법에 대해 쓴 것이 아니라, 그 이면에 있는 드라이버와의 통신에 대해 다룬다.#include #include #include #include #include #include #include #include #include #include #if defined(sun) #include #endif #include #if defined(linux) #include #endif #define BUFFERSIZE 1024 const char * localip = "0.0.0.0"; const char * myip() { cons..

소켓프로그래밍 깊이 보기 1 : 접속이 닫힌 후 읽을 수 있는 버퍼Quiz 하나를 생각해보자.클라이언트가 서버에 접속하여 뭔가를 전송하고 있다. 클라이언트는 1000 바이트를 전송하고나서 바로 소켓을 종료하였는데, 서버는 1 byte 씩 읽으면서 행의 끝을 판단하는 구조로 되어 있다. 서버가 10 바이트를 읽었는데, 실상 접속은 종료되었다. 서버쪽 프로그램은 11 바이트를 읽을 때, 접속 종료를 바로 알 수 있을까? 싱겁지만, 답은 서버쪽에서 1001번째를 읽기 시도할 때 비로소 안다는 것이다. 그 이유는 TCP는 데이터의 정확한(?) 전송을 보장하도록 되어 있기 때문인데, 끊어진 클라이언트에게 일단 1000 바이트에 대해 받았다는 신호를 보냈기 때문에, 서버 프로그램에 안정적으로 데이터를 올려 보낸후 ..

어떤 메시지를 암호화하여 전송할 때, 과연 그 메시지가 정상적으로 전달되었는가를 테스트하는 방법에 관한 생각이다. A. 1. 평문을 암호화한다. 암호문의 해시값을 구하여 암호문과 해시값을 전달한다. 2. 받은 쪽에서는 암호문을 풀기전에 암호문의 해시값을 구하여 전달받은 해시값과 같은지 비교한다. 3. 같을 경우 암호문을 푼다. 위 방법과 B. 1. 암호문만을 전달한다. 암호문을 풀어 보면, 평문과 그 해시값이 복원된다. 2. 받은 쪽에서 평문에 대한 해시값을 다시 계산해서 복원하여 얻은 해시값과 같은지 비교한다. 3. 같을 경우만 평문을 인정한다. 이 방법 중 어떤 것이 좋을까? 아니면 둘을 합한, C. 1. 평문을 암호화한다. 암호문의 해시값을 구하여 암호문과 해시값을 전달한다. 2. 받은 쪽에서는 암..

심재희라는 작가의 스포츠 서울 칼럼에 재밌는 글이 있어서 인용해 본다. 호나우디뉴의 외계인 카리스마 "천재는 노력한 자를 이길 수 없고, 노력한 자도 즐기는 자를 이길 수는 없다". 보통 카리스마 있는 선수들을 떠올리면 매우 험악한 인상을 머리에 그리기 일쑤다. 거칠고 투박하지만 팀에 든든한 버팀목이 되어주는 그런 선수들이 '카리스마맨'으로 통해왔다. 하지만 호나우디뉴는 그와는 또 다른 카리스마를 가지고 있다. '미소 속의 비치는 카리스마'라고 할까. 항상 즐겁게 웃으면서 경기를 펼치지만 그의 몸짓 하나하나는 보통 선수들과 차원이 다르다. 또한 상대방도 미워할 수 없게 만드는 좋은 매너를 갖추고 있고, 승부를 결정짓는 해결사 능력까지 보유하고 있다. 한마디로 실력과 인품, 그리고 축구에 대한 끝없는 열정..

0.96 에서 1.0 Classic 으로 바꾼다음 1.04 로 전환. 1.04로 전환은 언젠가는 이루어졌겠지만, 가장 큰 이유는 permalink가 맘에 들어서다. 내 글에 대한 URL에 "?"가 들어가지않고 표현되는 방식인데, 이는 로봇이 판단해야할 기준을 주기 때문이랄까?비누넷에서 등록 사용자에게 mysql.byus.net 이라는 UTF-8 지원 mysql 서버를 지원해주므로 이참에 content를 모두 utf-8으로 바꾼것도 한 몫한 것이지.간단히 migration에 대한 소개를 하자면, 태터툴즈쪽에서는 0.96과 1.x 클래식 사용자에게 1.02 이상 으로 이관할 방법을 제공하는데, 이렇게 하면 된다.1. 0.96, 1.x 클래식이 /tt 에 설치되어 있다면, 잠시 /tt 를 /tt1 로 이름을 ..

vim 뒤에 파일명이 압축 확장자(.gz, .Z, .bz2)로 되어 있다면, $ vim maillog.1.gz 바로 읽을 수 있다. /usr/local/share/vim/vim60/plugin/gzip.vim 이라는 플러그인이 확장자를 알아서 인식하여 전처리를 해주기 때문이다. 물론, 저장할 때 후처리로 다시 압축하여 저장하는 센스도 발휘 해준다. 로그가 압축되어 있을 때, 그 얼마나 편리한 기능인가!

다음과 같은 시나리오를 살펴 보자. "소스 디렉토리 A 의 a.c의 내용을 복사하여 소스 디렉토리 B의 b.c 로 사용해야할 일이 생겼다. 제품이 늘어 나고 있거든!" (물론 코드는 되도록 복사해서 사용해서는 안되지만 우리는 그런 완벽한 세상에서 살지 않으므로...) 이 경우. $ pwd /work/project_x/src/agent $ cp a.c ../log $ cd ../log $ svn add a.c $ svn commit $ svn log a.c위와 같이 하면, 중대한 것을 잃게 된다. a.c 의 지금까지의 변경기록이다. 다음과 같이 해야 정석이다. $ pwd /work/project_x/src/agent $ svn cp a.c ../log $ cd ../log $ svn commit $ svn..