insert at end/push_back test on C++ Standard Library containers and ncl::Array

gcc(+stlport) 환경에서 C++ Standard Library container들과 ncl::Array에 대한 성능 측정을 해보았습니다. 다만, int형에 대한 insert at end/push_back operation에 대해서만 측정을 해보았습니다. 참고로, ncl::Array는 C Standard Library의 realloc을 활용하여 copy를 줄이는 container입니다. 즉, C++ Standard Library의 container들과는 semantic이 좀 다른 셈이지요.

1. insert at end

첫번째는 (Sheet 1) container.insert(container.end(), obj) operation을 사용한 테스트입니다. stlport가 들어가있는 결과물은 gcc의 기본 library 구현 대신 stlport를 사용한 결과이고, reserve란 단어가 들어가 있는 결과물은 vector::reserve나 Array::Array(int size)를 사용한 구현의 결과입니다. (deque, list는 reserve를 위한 mechanism이 없습니다.)

결과를 요약해보면, vector (reserving) < vector < deque(stlport) =~ deque < list < list (stlport) 입니다. code는 다음과 유사합니다.

#include 
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
std::vector v;
#ifdef VECTOR_RESERVE
v.reserve(size);
#endif
for (int j = 0; j != size; ++j)
v.insert(v.end(), j);
}
}

2. push_back test

두번째는 (Sheet 2) container.push_back(obj) operation을 사용한 테스트입니다. vector의 경우에 위의 insert(container.end(), …)와 성능 차이가 2배정도 나는 것이 신기하군요.

결과를 요약해보면, Array (reserving) < vector (reserving) < deque < Array =~ vector << list 입니다. container들에 대한 코드는 다음과 유사합니다.

#include 
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
#ifndef VECTOR_RESERVE
std::vector v;
#else
std::vector v;
v.reserve(size);
#endif
for (int j = 0; j != size; ++j)
v.push_back(j);
}
}

ARRAY의 테스트 코드는 다음과 같습니다.

#include 
#include "ncl/array.h"
int main(int argc, char * argv[])
{
if (argc != 3)
{
printf("usage: %s count sizen", argv[0]);
return 0;
}
int count = atoi(argv[1]);
int size = atoi(argv[2]);
for (int i = 0; i != count; ++i)
{
#ifndef ARRAY_RESERVE
ncl::Array v;
for (int j = 0; j != size; ++j)
//v.insert(v.size(), j);
v.add(j);
#else
ncl::Array v(size);
for (int j = 0; j != size; ++j)
v.item(j) = j;
#endif
}
}

3. Conclusion

신기하게도, insert at end의 경우에는 vector가 제일 빠르고, deque, list의 순입니다. push_back의 경우에는 deque, vector, list의 순이었습니다.

두 경우 모두 list는 매우 느렸습니다. link를 위한 pointer의 overhead와 entry 별 allocation이 큰 것 같습니다. (아마도 allocator 수준에서 pooling을 하게 되면 개선할 수 있을까요?)

reserve를 하지 않는 경우 vector와 Array는 거의 유사한 performance를 보여줍니다. 10만건이 되면 좀 차이가 납니다. item 수가 적은 경우 (10000건 이하인 경우) vector의 alloc/copy와 Array의 realloc이 별로 차이나지 않는 것을 알 수 있습니다. (copy cost외에도 pre-allocation의 전략이 다르기 때문일 수도 있을 것 같습니다.) int형이 아니라 좀 더 큰 size의 (따라서 copy cost가 더 큰) object를 사용할 경우에는, vector와 Array의 차이가 더 커질 수도 있을 것 같습니다. (테스트가 필요합니다)

그리고 deque가 vector와 Array보다 더 빠른 것을 알 수 있습니다. gcc의 구현을 조금 보니, deque는 memory chunk 단위로 alloc하고 이에 대한 index(map)를 유지하는 data structure더군요. push_back의 경우에 추가적인 메모리만 할당하고, index의 size만 조절해주면 되기 때문에 당연히 더 좋을 수 밖에 없는 것 같습니다.

또한, reserve하는 것이 단연 reserve 하지 않는 경우보다 빠른 것을 알 수 있습니다. reserve할 경우에는 ncl::Array가 std::vector보다 훨씬 빠릅니다. Array의 경우에는 생성자를 통하지만, vector의 경우에는 reserve() op를 통하기 때문일까요?

insert at end/push_back test on C++ Standard Library containers and ncl::Array 더 읽기"

Visual Studio 2005 Beta 1 Refresh with the Team System

기존에 release된 Visual Studio 2005 Beta 1에 Visual Studio 2005 Team System의 Community Technology Preview (CTP)가 추가되어있다. 기회가 되면 VSTS에 대해서 글을 써보도록 하겠다.

Get the Visual Studio 2005 Beta 1 Refresh with Visual Studio 2005 Team System
http://lab.msdn.microsoft.com/vs2005/get/default.aspx

Visual C++ 2005 Express Beta
http://lab.msdn.microsoft.com/express/visualc/default.aspx

Visual C++ 2005 Tools Refresh (patch to Visual C++ 2005 Beta 1 release)
http://www.microsoft.com/downloads/details.aspx?FamilyID=afd04ff1-9d16-439a-9a5e-e13eb0341923&displaylang=en

Update :

Microsoft Set to Launch Refreshed ‘Whidbey’ Preview
http://www.eweek.com/article2/0,1759,1640080,00.asp

Visual Studio 2005 Beta 1 Refresh with the Team System 더 읽기"

Why do some structures end with an array size 1?

Win32 API나 COM의 variable-length struct를 사용해보신 분이라면, 익숙하실, size 1의 array member에 관한 설명입니다.

Why do some structures end with an array size 1?
http://blogs.msdn.com/oldnewthing/archive/2004/08/26/220873.aspx

한편, Zero-length array (정확히는 Flexible array member)의 지원은 C99부터군요. gcc에서는 3.0부터 extension으로 C/C++에서 지원해왔다고 하는군요.
http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

C++ standard 쪽에도 병합되었는지는… 모르겠습니다. C++98 까지는 분명히 지원되지 않는 것 같습니다. C++03쪽을 확인해보고 업데이트 하겠습니다.
http://david.tribble.com/text/cdiffs.htm

Why do some structures end with an array size 1? 더 읽기"

유혹의 기술

‘유혹의 기술’이란 책을 읽지도 않고 서평을 쓰는 실험.
뭔가 의도를 담아내는 재치가 부족해 보인다.
글쓴이: Cestlavie (이방인) [writers/BlueEyes]
날 짜: 2002년 11월 25일 월요일 04:21:38
제 목: 유혹의 기술
나의 삶이 얼마나 거짓된 삶인지 명확하게 보여주는 글이다.
아이 재미있어라. 낄낄. 참고로 writers/cybgira의 동제목의 글에 대한 리.
남의 보드를 어지럽히기는 미안하여 내 보드로 옮김.

이 책에서는 유혹의 ‘필요’가 근대에서 발생하기 시작했다고 했는데,
그 때부터일까 근대의 어느 시점에서부터일지, 아니면 훨씬 더 오래전부터일지,
유혹은 부정적인 개념이 아니라 오히려 미덕이 되어버리지 않았을까.
유혹의 역사는 그것이 가능한 사회에서는 우리가 아는 바와 같이 분명히 기록되어
전해져왔으며, 아마도 탄복과 외경의 의미가 아닐지. (두려움과 비난의 형태로만
나타난다 하더라도)
인간사에 흔한 유혹의 시나리오에서 유혹하는 쪽은 유혹당하는 쪽에 비해서 뭔가
뛰어난 조건-능력을 가지고 있다고 생각되고 (그 뛰어난 조건이 아무리 원천적이고
인간 본능적인 것이라고 하더라도) 그러한 뛰어난 조건이 미덕인 것으로
생각해야할 터인데, 유혹과 유혹의 기술과 그것을 위한 조건들은 모두
뭉뚱거려져서 미덕으로 생각되고 있는듯하다.
많은 사람들이 유혹당하는 쪽보다는 유혹하는 쪽을 원한다. 심지어 유혹을
경멸하면서도 말이다. 합리적이라고 일컬어지는 인간은 불합리함의 점철이자
결정판이지만, 그러한 불합리성을 어떻게든 극복해낸 사람이라면 유혹에 있어서
좀 더 능수능란할 수 있을 것이고 유혹이 성공할 가능성도 높아질 것이다.
(살인에 대해서 자기합리화를 잘할 수 있는 병사가 더욱 능력있는 병사가
될 것이다.)
하지만, 이러한 유혹에 대한 합리성의 문제는 사소한 것에 불과하고,
합리성의 문제와 유혹의 기술 자체, 그리고 그 기술을 위한 능력의 세가지
중에 유혹의 실행을 위해서 가장 중요한 것은 아마도 유혹을 위한 조건,
즉 능력의 존재여부일 것이다.
이 책은 유혹을 실행하기 위한 이러한 세가지 조건 중 가장 덜 중요하지도 가장
중요하지도 않은 유혹의 기술 즉, 방법론에 관한 책이다. 유혹의 기술에 관한한
이 책은 상당히 잘 설명하고 있다. 이 책의 최고의 매력이라고 생각되는 점은
아무래도 유혹의 기술을 몇 가지의 유형으로 분리하고 예를 들어 설명한 것이다.
설명하기 힘든 인간간의 문제에 대해서, 역사는 가장 합리적인 설득이 될 수 있는
것이다. 덤으로 독자들은 유혹의 역사에서 조명을 받는 주인공들을 통해 어느
정도의 대리만족을 느낄 수도 있다.
하지만, 책을 덮고 나서 막상 유혹의 실행에 있어서 난감해지는 것을 느낄 수
있는데, 이것은 위에서 설명한 자신의 능력의 조건에 대해서 만족스러울 만큼 잘
알고 있지조차도 못하기 때문이다. 글쎄 이 책을 읽은 독자라면 다음과 같은
제목의 책을 기다리지 않을까?
‘유혹, 세라비만큼만 하기’
‘유혹자를 위한 변명’

유혹의 기술 더 읽기"

Identity

메일을 정리하다보니 이런 글도..
내가 봐도 무슨 말인지 모르겠군.
글쓴이: Cestlavie (이방인) [writers/BlueEyes]
날 짜: 2002년 10월 31일 목요일 01:10:38
제 목: Identity
하루만에 지하철을 2시간 가량 탔더니 나타나는 증세인가보다.
오묘한 원리로 지하철역으로 모여드는 엄청난 인파들을 질리게 보다보니,
이 삭막하기 그지없는 도시에서 자신의 아이덴티티를 지켜내기란 정말로
힘든 일인 것 같다. 무언가를 창조하는 일이 지속되어야 이유는 그것이 다른
사람들을 행복하게 해주기 때문이 아니라 자신을 지켜내는 행위이기
때문이어야 한다. 사실상 ‘창조’라는 단어를 쉽게 쓸만큼 우리들은
(적어도 난) 창조적이지 않다. 많은 사람들은 그들의 진취성과 창조성을
잃어버린지 오래다. 하여, 우리는 일생동안 자신도 감당못할 ‘생산’을 한다.
그 중 2/3 정도는 쓰레기이고, 1/3 정도는 다른 사람들을 행복해주기도 한다.
몇몇 안되는 창조물을 위한 희생이다.
인간은 그 홀로 있을 때에도 창조적일 수 있다. 창조성과 아이덴티티의 도식을
가볍게 받아들인다면, 창조적인가 아닌가 하는 것은 그것이 분리된 상태에서도
창조성을 유지하는가의 여부가 하나의 척도가 될 수 있다. 우리가 추구하는
아이덴티티의 궁극은 그런 것이 아닐까 생각된다. 24년동안의 궤적이 무색할
정도로 난 창조적이지 못하고 여느 사람과 거의 다른 점이 없어서
인파속의 나를 스스로도 구분하기도 힘들다. 하지만, 유치하기 그지없는 매일의
고심과 엄청나게 적체되어 먼지에 쌓여 빛나고 있는 위대한 창조물들의 연구와
습득은 24년의 궤적을 이어가는 같은 방향의 행로에 있는 것이기도 하다.
현재의 나는 다른 사람들과의 관계속에서 존재하고 다른 사람들과의 관계속에서만
나의 걸음을 옮길 수 있다. 하지만 언젠가는 스스로 홀로 설 수 있는 사람이,
스스로의 걸음을 걸을 수 있는 사람이 될 수 있지 않을까 상상해본다.

Identity 더 읽기"

Inside C#, Modern C++ Design

Inside C#, 2nd Edition

C# Programming Language에 관한 책이다. 사실 .Net Framework에 대한 내용도 상당히 포함되어있기 때문에, Language를 배우기에 좋은 책은 아니다. 그럼에도 불구하고, C#의 여러 언어적인 요소와 CIL(Common Intermediate Langauge; aka MSIL)을 비교하면서 작동원리를 설명해주기 때문에 C# Programming Language의 구현 방식을 약간이나마 들여다볼 수 있는 점은 이 책의 미덕이다. 번역은 엉망인 편이다. (10점 만점에, 초반은 4점 중반은 0점, 후반은 5점 정도?) 아르바이트 생들에게 시키고 한번도 제대로 읽어보지 않은 정도의 퀄리티. 읽어보면서 내가 직접 수정하면서 읽어간 곳만도 한 스무군데 정도 되는 것 같다. 요즘에 번역서를 몇권 보면서 신뢰를 약간 얻어가는 중이었는데, 이 책을 보고 다시 실망해버렸다. 따라서 이 책을 읽고자 하는 사람은 차라리 원서를 보기를 추천한다.

참고로, C# Programming Language를 공부하고 싶다면 이 책보다는, O’Reilly사의 Programming C#, Third Edition과, C# Programming Language의 아버지인 Anders Hejlsberg가 쓴 The C# Programming Language를 추천한다.

 

Modern C++ Design

Modern C++ Design은 template의 사용에 관한한 최고의 책이라고 한다. template이 어디에 쓰는 건지 모르겠다면 Modern C++ Design은 template을 사용해서 구현할 수 있는 모든 technique을 보여줄 것이다. (from http://www.lastmind.net/tWiki/bin/view/Main/SoftwareDevelopmentBooks)

현재 읽고 있는 책이다. 현재 Chapter 6를 읽고 있는데, 이번 달 안에 끝낼 생각. 번역은 C++ In-Depth 시리즈를 통틀어서 그렇듯이, 만족스러운 편이다. Template parameter를 Strategy로 사용하는 idiom을 Chapter 1에서 소개하고, Template을 사용하는 자잘한 techniqueue을 Chapter 2에 모아두었다. 이어서 Template을 이용해서 구현하는 굵직굵직한 주제들이 나온다. Typelists, SmallObjAllocator, Generalized functor, Singleton, Smart pointer, Object Factory, Abstract Factory, Visitor, Multi Method가 그것들인데, 잘 알려진 패턴이거나 현재 Library TR에서 adopting 중인 것이기 때문에 어쩌면 이미 잘 알고 있는 사람도 있을 것 같다. (저자인 Andrei Alexandrescu가 CUJ의 고정 칼럼 필자이기 때문에, CUJ에서도 이미 다루어졌던 주제들이 많다.) 어떤 것들은 이것이 쓸모가 있는가 싶을 정도인 것도 있고, 어떤 것들은 당장 내 코드에 반영할만한 것들도 있고, 또 내가 직접 구현해보고 싶은 것들도 있다. 확실히 template을 잘 쓰고 싶은 사람이라면 한번쯤은 거쳐가야할 책인 듯 싶다.

 

(참고로 이 글은 요즈음 만들고 있는 MovableTypeWriter로 작성한 글.)

Inside C#, Modern C++ Design 더 읽기"

The New C++: Part I

Introduction

소프트웨어 개발자가 선택하는 언어는 개발 패러다임이 변화함에 따라, 어플리케이션 도메인이 변화함에 따라, 또는 외부적인 기술 변화에 따라 계속 변해왔다. 현대의 프로그래밍 언어에서는 이러한 변화가 비단 언어간의 선택에만 반영되는 것이 아니라, 이미 존재하는 언어에도 변화를 요구하는 것이 사실이다.

이 사실은 C++ Programming Language에 있어서도 예외가 아니다. 1998년에 처음으로 C++ Programming Language의 공식적인 표준 (ISO/IEC 14882:1988 International Standard. C++98)이 제정된 이후로 꾸준히 bug fix들이 – 이러한 bug fix 가운데 하나는 std::vector의 internal storage가 contiguous해야한다는 requirement가 추가되어야 한다는 것이다. 그래야만, 프로그래머는 vector 내의 한 element로의 pointer를 얻은 후 array처럼 pointer 연산을 통해 traverse할 수 있다 – 이루어져와서 작년(2003년)에 TC1을 포함한 새로운 표준 (ISO/IEC 14882:2003 International Standard. C++03)이 발표되었다.

현재 C++ Standards committee는 C++0x 표준안에 노력을 기울이고 있는데, 여기에는 기존과는 달리 C++의 언어 자체상의 변화와 표준 라이브러리 (흔히 STL이라고 불리는.. 이는 잘못된 이름이다) 상의 변화를 수반하고 있다. C++ Programming Language를 사용해서 개발하는 프로그래머라면, 이러한 변화에 대해서 미리 알고 있다면, 그동안, C++에서 부족했던 feature에 대해서 보완할 때, 미래의 C++을 미리 고려해서 결정할 수 있을 뿐만 아니라, C++이라는 언어가 현재까지 가져왔던 철학뿐만 아니라 앞으로 가질 철학에 대해서도 더욱 잘 이해할 수 있으리라고 믿는다.

이를 위해서 ISO C++ Standards committee의 의장(convener)이자 Exceptional C++/More Exceptional C++의 저자이면서 Micorosoft에서 Visual C++ architect로 일하고 있는 Herb SutterCUJ에 기고한 The New C++ 칼럼을 이해하기 쉽도록 정리해서 적어보고자 한다.

ISO C++ Standard Committee

ISO C++ Standard Committee에서 하고 있는 일들의 진행상황은 여기에서 볼 수 있다. 언어 자체상의 issue들 (The C++ Standard Core Issues List)이나 표준 라이브러리상의 issue들 (The C++ Standard Library Issues List), 또는 TR1에 들어갈 표준 라이브러리 extension의 draft 등을 해당 사이트에서 찾아볼 수 있다.

Issues List를 참고할 때, Issue들의 종류에는 크게 세가지가 있다.

  • Defect Reports: committee가 표준안 상에서 수정이 필요하다고 동의한 것들이다.
  • Active Issues: 현재 고려중인 issue들이다. 저번 meeting에서 제기된 새로운 issue들과 논의되고 있던 issue들뿐만 아니라, commit하기 전에 더 많은 작업을 필요로 하는 issue들도 필요로 한다.
  • Closed Issues: 더이상의 작업(표준상의 변화)이 필요없는 issue들이다.

The C++ Standards meeting에서 주로 작업하는 것들에는 다음과 같은 것들이 있다.

  • Defect Reports (DRs): 전체 미팅 시간의 반 정도를 현재의 표준안에 대한 질의에 대답하고 버그를 찾는데에 할당한다. TC1 (Technical Corrigendum 1) 이후의 bug fix들은 TC2 또는 C++ 표준안의 다음 revision인 C++0x에 들어가게 될 것이다.
  • Performance Technical Report (Performance TR): 하드웨어나 embedded system을 물론 C++ implementability (예를 들어 exception을 어떻게 좋은 성능으로 구현 및 사용할 것인가)에 초점을 맞추고 있다. 이 TR은 C++0x에 들어갈 예정이다.
  • Library Technical Report (Library TR): 표준 라이브러리에 새로운 기능을 추가하는 것에 대해서 다룬다. 특히, 언어 자체에 추가사항을 필요로 하지 않는 것에 대해서만 다루고 있다. 이 TR은 C++0x에 들어갈 예정이다. Library TR에서 다루는 대부분의 기능은 Boost에 구현되어있다. (그렇다고 해서 Boost의 구현이 표준이 되리라고 보장할 수는 없다는 점을 유의)
  • Evolution Working Group (Evolution WG): Library TR이 다루지 않는, 즉 언어 자체에 추가사항을 필요로 하는 것들을 다룬다.

이번에는 소개와 C++ Standards committee에 대해서 소개하는 내용밖에 없었지만 다음부터는 C++0x에 들어갈 내용 중, 프로그래머에게 가장 관심이 있을 부분인 Library TR와 Evolution WG에 approve된 내용들을 다루려고 한다. 일단 Part II에서는 현재 Libary TR과 Evolution WG에서 다루고 있는, 다음 내용들에 대한 간단한 설명부터 시작하고, 이후에 각각의 issue에 대해서 자세한 article을 써보는 것도 괜찮을 것 같다. C++에 관심있는 개발자라면, 간단히 적어놓은 아래의 리스트만 보아도 누구나 눈에 띄이는 내용들일 것이다.

  • Library TR
    • Smart pointers (shared_ptr, weak_ptr)
    • Tuple types (tuple)
    • Generalized function pointers (function)
    • Nearly complete C99 library compatibility
    • Hash-based container (unordered_set, unordered_map, unordered_multiset unordered_multimap)
    • Type traits (alignment_of, has_nothrow_copy, has_virtual_destructor, is_base_of, is_const, is_convertible, ..)
    • Regular expressions (basic_regex)
    • Random-number generation(random_device, poisson_distribution)
  • Evolution WG
    • C99 harmonization (long long, #scope/#endscope, ..)
    • Delegating constructors
    • Static (compile-time) assertions
    • Explicit conversion operators.
    • nullptr
    • Strongly typed enums

References

The New C++: Part I 더 읽기"

MSN Web Messenger Beta

p. Web 기반의 Messenger 서비스인 [“MSN Web Messenger”:http://webmessenger.msn.com/]가 beta-testing 중이다.
h2. First Impression
p. 약간 사용해 본 느낌은 메신저 창이나 대화 창이 초기화되는데 좀 오래걸리는 것 같고, 상대방의 메시지가 도착할 때, 메시지가 기록되는 창으로 focus가 가서 내 typing이 방해받는 것이 신경쓰였다. 그리고 메시지를 보내고 난 후, form이 다시 loading되는데에 걸리는 시간도 불편한 점.
p. 웹브라우저 외에 다른 소프트웨어를 설치 불가능한 곳이라든가…
MSN Messenger 서비스를 사용 불가능한 platform이라든가… (요즘엔 gaim이 파일 전송도 된다는 모양입니다만.. ㅋ) 그런 곳에서는 쓸모가 있을 수는 있겠다.
h2. Technical overview
p. 기술적으로는 이미 존재하기도 했기 때문에 그다지 신기한 것은 아니다. server-side something + HTTP (periodical refresh) + Javascript 정도인 듯. applet이나 ActiveX 기술을 사용하지 않는덕분에 많은 Javascript를 지원하는 웹브라우저에서는 대부분 사용가능하다. (Windows의 IE, Mozilla, Firefox는 물론 OS-X의 Camino나 Linux의 Firefox에서도 동작가능할 것이라고 한다. 실제로 가능한지는 not confirmed.)
다만 인상적인 것은 push에 사용하는 방법이 주기적인 HTTP refresh일 뿐이었는데도, realtime messaging이라는 서비스의 usability에는 그리 치명적이지는 않았다는 것. client-side 및 server-side의 performance가 문제가 될 수는 있겠지만, realtime requirement가 critical하게 중요하지 않은/부차적인 서비스에서는 connection-oriented 기술이 필수적이지 않다는 생각도 해볼 수 있을 것 같다. (예를 들어, 채팅 같이 messaging이 빈번하고 realtime-ness가 중요한 서비스에서는 connection-oriented 기술이 사용자의 experience를 개선하는데에 중요하겠지만, 메시지 전달이 빈번하지 않은 게임 초대 같은 서비스 등에서는 별로 중요하지 않을 수도 있다는 것이다. (물론 user exprience에서의 최선은 connection-oriented이다.)
h2. Inside the MSN Web Messenger
기본적으로 MSN Web Messenger의 UI는 HTML과 Javascript에 기초한다고 보면 된다. 다음은 MSN Web Messenger의 중심이 되는 javascript file을 indentation을 위해 약간 수정한 것이니 참조해보라. (License쪽을 뒤져봐야겠군. ;;)
[“webmessenger.js”:http://www.lastmind.net/archives/20040809/webmessenger.js]
세션의 유지는 server-side에서 이루어진다고 생각된다. client는 어떤 형태로든 session ID를 유지하리라고 추측된다. Javascript에서 connection을 해서 세션을 유지한다거나 하는 것 절대 아니다. ;;;
서버로부터 클라이언트로 push되는 정보는 위에서 언급했듯이 HTTP refresh를 통해 이루어진다. Fiddler같은 HTTP 분석 tool을 사용해보면 5-7초 간격으로 driver.ashx라는 URL을 refresh하는 것을 알 수 있다. 그리고 이 page 내에는 WebMessenger javascript 객체의 method를 통해 상대방이 보낸 메시지나, 친구들의 상태 변경 정보들을 WebMessenger object instance에 update하고 이를 통해 UI에도 반영시키게 된다.
다음은 상대방이 메시지를 보내왔을 때, 이 page의 예이다.



h2. Links
* [” What is MSN Web Messenger?”:http://www.mess.be/msnmessengerfaq/article.php?id=083&action=print]
* [“eMessenger”:http://e-messenger.net/]: MSN Web Messenger와 거의 똑같은 서비스를 하는 web application.
h2. Screenshots
!http://www.lastmind.net/archives/20040809/MSN_Web_Messenger_01.JPG!
!http://www.lastmind.net/archives/20040809/MSN_Web_Messenger_02.JPG!

MSN Web Messenger Beta 더 읽기"

Sakamoto Maya – Gravity

!http://www.nerdtopia.org:81/~jthai/gravity.gif!
p. 난, 게임과 애니메이션을 좋아하면 칸노 요코를 좋아할 수 밖에 없고, 칸노 요코를 좋아하면 사카모토 마야를 좋아할 수 밖에 없다..라는 꽤나 빠져나오기 힘든 연쇄고리에 얽혀있는 사람들 중 하나다.
p. 피곤하면 음악을 듣기 힘들어하는 스타일이다. 좋아하기는 하지만, 음악을 듣는데에는 일정 정도의 노력이 필요하다. 영화를 몇편 보면 내 정신적 capacity가 가득차는 것처럼. 즐거운 것과 이른바 ‘일’이란 것과, 힘이 드는 것이 모두 독립적인 사실인 것처럼.
p. 몇주간 음악을 제대로 들을 수가 없었는데, – 그 동안 육체적으로 힘든 일은 없었기 때문에, ‘피곤하다’는 건 아마도 정신적인 것으로 생각된다 – 그 때는 대체로 easy listening 계열이나 classic, 또는 나의 favorite 모음 등을 듣곤 한다. 요 며칠은 sakamoto maya를 mp3p에 넣어다니는 중이다. 마치 암에 걸린지 오래되어 아무런 약도 더 이상 듣지 않을 때, 마시는 커피 – 각성제 같은?


p. 퇴근하려다보니 비가 엄청 쏟아지고 있었다. ‘비가 그칠지도 몰라, 만약 그렇다면 행운이지’라는 생각을 하다, 결국은 비 속에 몸을 맡기고 말았다.
‘그렇지 않다면’의 상황을 일부러 잊어버린 것에 대한 문책을 하기도 전에, 이미 이 모퉁이를 돌아서면 불빛이 스크린’에 가득차면서 무의식에 가까워짐, 배어나오는 따뜻한 액체 등을 상상하고 있는 건, 나의 본능은 정말 대책이 없다.
앞으로 모든 내 주변의 사람들을 불행하게 만들 수 있으리라는 자신감이 든다.


p. 며칠 전에 어떤 여자애와 헤어졌지만 아무런 감흥이 없다. 나이 따위의 이유로 치부하기도 싫고, 그렇다고 내가 감정이 메마른 인간이어서도 아니다. 그건, 부인해왔지만, 보기 좋게 실패해버린 나의 희망에 관한 연작 실험에 대한 망각 본능일 뿐이다.
p. 다른 사람이나 사회에 일말의 기대도 희망도 가지고 있지 않다. 그래서 오히려 쪽지 끄트머리에 쓰여졌다가 지우개로 북북 지워진 듯한 희망의 증거를 찾아다니는 사람이다. 모든 사람들이 필요로 하는, 하지만 나에게는 버거운, 이 별의 중력을 필요로 하지 않는다. 어느 왕자가 살았음직한 조그마한 별 정도의 중력이 필요할 뿐이다.

Sakamoto Maya – Gravity 더 읽기"