Server programming in use...FiaDot

안녕하세요 ^^;
제가 설명드리려고 하는 것은 CDynamicParameterAccessor를 이용한 방법입니다.
아래의 코드를 보시면 쉽게 이해가 가실겁니다.

// 이 부분은 접속하는 부분입니다. 어느 엑세서를 사용하시던지 공통입니다.
CDataSource    m_Connection;
CSession    m_Session;
HRESULT        hRet = E_FAIL;

USES_CONVERSION;
// pInitString에 들어가야 할 건 잘 아시리라 생각하구여 ^^
hRet = m_Connection.OpenFromInitializationString(T2COLE(pInitString));
if(FAILED(hRet))
{
     return FALSE;
}

hRet = m_Session.Open(m_Connection);
if(hRet != S_OK)
{
     return FALSE;
}

스토어프로시져의 구조에 따라 약 3가지 정도로 구분된다고 할 수 있습니다.
1. 반환값이 없고 출력 파라미터가 있는 경우.
    CREATE PROCEDURE sp_MyTest1
    @ret int OUTPUT
    AS
       set @ret = 1
   GO

2. 반환값이 없고 입력 출력 파라미터가 있는 경우.
    CREATE PROCEDURE sp_MyTest2
    @index int,
    @ret int OUTPUT
    AS
       set @ret = 1
   GO


3. 반환값이 있고 입력 출력 파라미터가 있는 경우.
    CREATE PROCEDURE sp_MyTest3
    @index int,
    @ret int OUTPUT
    AS
       -- 입력값은 받았지만 사용안하는걸로 이해해 주시길 ^^
       declare @aaa int
       set @aaa = 99
       select @aaa AS RESULT

       set @ret = 1
   GO


이 이외의 경우는 CDynamincAccessor를 사용하셔야 하겠죠 ^^

// 길게 쓰는게 귀찬으니깐 짧게 줄입니다. ^^
typedef CCommand<CDynamicParameterAccessor, CRowset, CMultipleResults>    CxParamCmd;

CxParamCmd   m_Cmd;

void* pDummy;
TCHAR pstrQuery[256];

// 쿼리가 입력되는 부분입니다. 즉 프로시져가 들어가는 부분이져.
// 다음과 같이 세 종류의 쿼리가 입력될 수 있습니다.
sprintf(pstrQuery, "sp_MyTest1 ? OUT " );
sprintf(pstrQuery, "sp_MyTest2 ?, ? OUT " );
sprintf(pstrQuery, "sp_MyTest3 ?, ? OUT " );

//  이 다음부터는 공통으로 사용되는 코드입니다.
hRet = m_Cmd.Create(m_Session, pstrQuery);
if(FAILED(hRet))
{
    AtlTraceErrorRecords(hRet);
    return FALSE;
}

hRet = m_Cmd.Prepare();
if(FAILED(hRet))
{
    AtlTraceErrorRecords(hRet);
    return FALSE;
}

hRet = m_Cmd.BindParameters(&m_Cmd.m_hParameterAccessor, m_Cmd.m_spCommand, &pDummy);
if(FAILED(hRet))
{
    AtlTraceErrorRecords(hRet);
    return FALSE;
}

// 입력 파라미터를 설정하는 부분입니다.
// 첫번째 파라미터의 값이 2라는 말입니다. ^^ 첫번째 프로시져를 사용하실 경우는 필요가 없겠죠 ㅍ.ㅍ
LONG nParamValue = 2;
m_Cmd.SetParam(1, &nParamValue);

// 쿼리를 실행합니다. Bind를 하지 않는다고 설정하시는게 나중을 위해 편하답니다 ^^
hRet = m_Cmd.Open(NULL,NULL,false);
if(FAILED(hRet))
{
    AtlTraceErrorRecords(hRet);
    return FALSE;
}

/*================================================================
    출력 파라미터만 받을 경우
================================================================*/
LONG ltemp = 0;
//  아래의 GetNextResult()는 여기서는 반드시 하시지 않아도 상관없습니다.
// 하셔두 되구여... 하지만 클래스화 하시면 하는게 편할지두 ^^
m_Cmd.GetNextResult(<emp);
LONG aa = *(LONG*)(m_Command.GetParam(2));

aa에 출력파라미터의 값이 들어있게 됩니다.

/*================================================================
    반환값과 출력 파라미터를 받을 경우
================================================================*/
// 반환값이 있는 경우라면 Bind를 합니다.
m_Cmd.Bind();

// 반환된 레코드 셑을 읽어옵니다.
// 각 필드값도 루프를 돌면서 값을 다 읽어 옵니다.
// 만약 레코드셑이 반환됐다면 루프를 돌면서 전체를 다 읽어야 하겠죠 ^^
// 그런건 아시리라 믿구여 ㅎ.ㅎ
// 여기서는 그냥 한개의 필드값만 읽어오는 걸루 ㅋㅋ
LONG dd = *(LONG*)(m_Cmd.GetValue(1));

// 모든 값을 다 읽으셨으면 출력파라미터를 읽을 준비를 합니다.
LONG ltemp = 0;
m_Cmd.GetNextResult(<emp);
LONG aa = *(LONG*)(m_Command.GetParam(2));

결론적으로 dd에는 반환값이, aa에는 출력파라미터값을 읽어오게 됩니다.

전체적인 코드를 보시면 쉽게 아시리라 믿습니다. 너무 설명을 난잡하게 해서 죄송하구요 ^^
제가 짠 OleDB 클래스에서 급하게 따온거라 좀 변수나 이런게 조잡하기는 하지만
전체의 흐름을 한번만 보시면 다른 것에도 쉽게 적용하실수 있을거 같아서.....

그럼 즐프하시구여 ^^ 틀린게 있다면 이해해 주시길 바랍니다.

^^ _beginthread 그거 저도 써도 큰 지장은 없는 줄
알았는데 MS쪽 파워포인트 자료 보다가
알았습니다. 물론 제프리 리쳐 책에도 보면 쓰지 말라고는
얘기있는 것 같은데 확실히 왜 쓰지 말라고는 얘기가
없던걸로 기억되네요. 잘 기억이 나진 않는데
_exitthread 할때 문제가 있다고 적혀있더군요.
지금 집이 아니라 정확하지 않은데..집에 가서 다시 확인해
보겠습니다.



CreateThread, ExitThread만 쓸수 있으면 좋겠지만,
CRT Code들을 어쩔수 없이 써야 하는 경우엔

_beginthread 밖에는 대안이 없겠지요....

뭐 왜 글케 만들었는지는 잘 모르겠습니다. 누가 아시는 분이 설명좀....




일단 _beginthread와 _beginthreadex에 대해서..
MSDN에는 It is safer to use _beginthreadex than _beginthread. 정도로 나와있습니
다. thread handle이 close 되느냐 안되느냐 정도는 큰 논란거리는 안된다고 보입니다.
역시 말 그대로 좀더 안전하다.. 정도로 보면 무리가 없을듯 합니다.

CRT를 쓸때 _beginthread/_endthread를 써야 하는 이유에 대해서..
CRT도 MFC 처럼 내부 resouce를 관리하는데, _endthread를 쓰면 그 내부 resource를 정
리한 후에 ExitThread를 호출한다 라고 되어있습니다. 즉, 그냥 ExitThread를 호출할 경
우 약간의 resource leak이 발생한다는 겁니다. 또 한가지는 CRT를 쓸 경우
CreateThread로 만들어진 thread에 대해서 SuspendThread를 할 때 deadlock의 가능성이
있다고 나와있습니다. C runtime data structure에 대한 access block때문이라는데, 어
쨌든 그래서 CRT를 쓸때는 _begin../_end..를 써야 한다는 거죠.







정정합니다... 4076 0 x86ddk@empal.com 1355 17 10        


작 성 자 _Zealot_(_Zealot_)     첨부
파일  
작성시각 2002-03-16 오후 1:25:08 조 회 수 2082
글 분 류 WinSock


답변을 애매하게 해놓은것 같다는 생각이 들어...  죄송하구요...

정리를 좀 해 놓겠습니다...

다음은 Beginning Windows NT Programmming 에서 발췌한 것입니다...

*_beginthread 는 쓰레드를 생성하고 바로 CloseHandle을 호출합니다...따라서 이때 반
환되는 핸들은 무효할 것이고 더이상 쓰레드 오브젝트와 통신할 수 있는 방법을 가지지
못하게 됩니다..

=> 이렇게 _beginthread가 동작하는 것은 Win32 의 상세함을 숨기기위해 고안되었지만
결국 버그가 되버린 함수가 되버렸고...
_beginthreadex 에서 수정이 된것입니다...


*다중 C 런타임 라이브러리와 같이 사용될 경우...다음과 같은 경우입니다...
1.부동 소수형 변수나 함수를 사용할 경우
2.C의 malloc과 free나 C++ 의 new와 delete 를 사용할경우
3.stdio.h 나 io.h에서 어떤 함수를 호출한다면
4.strtok() 나 rand() 와 같이 정적 버퍼를 사용 하는 어떤 런타임 함수를 호출할 경우

=> 이때는 _beginthreadex를 사용 해야합니다...거의 대부분의 경우에 해당 된다고 보시
면 됩니다...대부분의 프로그램이 C Runtime을 사용하는것이 흔한 일일테니까요..


*위에 열거해 놓은 어떤 동작도 수행 하지 않는 다면 단일 쓰레드 라이브러리와
Createthread 함수를 사용하는 것이 안전합니다...


*MFC를 사용할 경우는 CWinThread를 사용하는 것이 안전합니다...



2) endthread뿐만 아니라 어떤 thread exit함수를 써도 마찬가지입니다.
즉, _endthread, _endthreadex, ExitThread, AfxEndThread등 전부가 그렇습니다.

1, 3) 관련 MSDN원문을 싣습니다.
_beginthread, _beginthreadex 항목
Note   For an executable file linked with LIBCMT.LIB, do not call the Win32
ExitThread API; this prevents the run-time system from reclaiming allocated
resources. _endthread and _endthreadex reclaim allocated thread resources and
then call ExitThread.

C Run-Time Library Functions for Thread Control항목
Warning   If you are going to call C run-time routines from a program built with
LIBCMT.LIB, you must start your threads with the _beginthread function. Do not
use the Win32 functions ExitThread and CreateThread. Using SuspendThread can lead
to a deadlock when more than one thread is blocked waiting for the suspended
thread to complete its access to a C run-time data structure.

.. 소스를 본다고 모든걸 알 수 있는건 아니라고 생각합니다. "모든" 소스를 보기전에
는..

출처 ; 데브피아

이 글은 다음 블로그에 올라온 글입니다.

----------

Many times in my life I have needed to debug a deadlock. You have one thread trying to acquire a critical section, and it can be a pain to determine which thread has it.

Setup: Go get OS Symbols. Having OS symbols is a must, and will make your life easier in many ways. To get OS symbols the easy way, use symbol server. Here is an article about how to do this -- http://support.microsoft.com/default.aspx?scid=kb;en-us;319037. For Visual Studio.NET 2003 (and future versions), symsrv.dll is already included in the product. Here is another article on the subject if you prefer -- http://www.codeproject.com/debug/postmortemdebug_standalone1.asp.

How to:
1. Go to the thread that is trying to acquire the critical section. Your stack should look like:

7ffe0304()
ntdll.dll!_ZwWaitForSingleObject@12() ntdll.dll!RtlpWaitForCriticalSection(_RTL_CRITICAL_SECTION * CriticalSection=0x00452ba0)
ntdll.dll!_RtlEnterCriticalSection@4()
deadlock.exe!ThreadFunc(void * __formal=0x00000000) Line 24 + 0xd bytes C++
kernel32.dll!BaseThreadStart(unsigned long (void *)* lpStartAddress=0x00417681, void * lpParameter=0x00000000) Line 532 + 0x6 bytes C

2. Go to the ntdll.dll!_RtlEnterCriticalSection frame on the callstack
3. Open the memory window, set display to ‘4-byte integer’, and evaluate ‘@vframe’
4. The first DWORD should be the return address. In my example, this would be the address of ‘deadlock.exe!ThreadFunc Line 24 + 0xd bytes’. If this isn’t the case, then the debugger is having difficulty walking the stack. See if you can find the return address.
5. The DWORD after the return address is the address of the critical section. Drag this into the memory window
6. The fourth DWORD is the ID of the thread owning the critical section. You can drag this to the watch window if you want to see this value in decimal.

Alternatively, if @vframe is correct, you can evaluate this in the watch window ‘*((DWORD*)(*(DWORD*)(@vframe+4))+3)’. You still need to be at the ntdll.dll!_RtlEnterCriticalSection@4() frame:

*((DWORD*)(*(DWORD*)(@vframe+4))+3) 3304 unsigned long

Happy debugging.

[16.7] Do I need to check for NULL before delete p?
No!

The C++ language guarantees that delete p will do nothing if p is equal to NULL. Since you might get the test backwards, and since most testing methodologies force you to explicitly test every branch point, you should not put in the redundant if test.

Wrong:


if (p != NULL)
   delete p;
Right:


delete p;


http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.7

   neolith (2003-12-26 01:56:19, Hit : 317, Vote : 0)  



  http://www.lameproof.com


  강력한 Assert 라이브러리


http://www.cuj.com/documents/s=8464/cujcexp0308alexandr/






곤(GON) (2003-12-29 13:42:28)  

와우~!! 멋지군요 ^^;;  

   neolith (2003-12-27 00:19:12, Hit : 291, Vote : 0)  



  http://www.lameproof.com


  Critical Section 의 활용과 데드락, 성능 문제점등의 해결을 위한 조언


http://msdn.microsoft.com/visualc/default.aspx?pull=/msdnmag/issues/03/12/criticalsections/default.aspx






shadowisle (2003-12-27 14:33:23)  

잘 해결 되면 좋겠지만 최악의 경우 수많은 다운 및 성능 하락의 원인이 되는 것들이네요. 저 용어만 들으면 예전
운영체제 배울 때 들었던 생각이 솔솔 나네요. 운영체제가 알아서 잘 해주면 좋으련만...  

IOCP 관련 article 6784 0 stonesim@hotmail.com 6784 0 0        


작 성 자 심준석(stonesim@hotmail.com)     첨부
파일  
작성시각 2004-02-03 오전 11:45:04 조 회 수 148
글 분 류 WinSock



IOCP관련해서 이 정도 쓰면 되겠다 싶은 정도까지 되어있는 article 및 sample입니다. 이미 2002년에 발표된 내용이라서



많이들 보셨으리라 생각되지만 참고 link로 알고 있어도 되겠다 싶어서..



http://www.codeproject.com/internet/jbsocketserver1.asp

http://www.codeproject.com/internet/jbsocketserver2.asp

http://www.codeproject.com/internet/jbsocketserver3.asp

http://www.codeproject.com/internet/reusablesocketserver4.asp



맨 끝에가면 서버 framework 정도까지 가기때문에 참고로 보셔도 좋고, 직접 사용하셔도 좋을 듯 합니다.




- 출처 -
데브피아

        

Network Working Group P. Deutsch

Request for Comments: 1951 Aladdin Enterprises

Category: Informational May 1996

데후레이트 압축 데이터 형식 시방서 버젼1.3

(DEFLATE Compressed Data Format Specification version 1.3)

<<국역;　오오하시 야스시사　k_ohashi@ca2.so-net.ne.jp>>

이 메모의 스테이터스

이 메모는 인터넷 커뮤니티를 위한 정보를 제공한다. 이 메모는 , 어떠한 종류의 인터넷 표준을 규정하는 것은 아니다. 이 메모의 배부에 관한 제한은 없다.

IESG의 노트：

IESG는 이 문서에 포함되는 지적 소유권의 기재가 올바른 것으로 있는지 어떤지 모두 칸치 하지 않는다.

공지사항

Copyright (c) 1996 L. Peter Deutsch

이 문서의 복사와 배부 및 다른 언어에의 번역이나 편집물에의 편입은 저작권 표시와 본고지가 보관 유지되고 있어 , 본질적인 변경이나 삭제가 명확하게 표시되고 있는 한 , 목적을 불문하고 무료이다.

<<권리 , 의무에 관해서는 문서의 마지막에 첨부한 원문을 참조[역자]>>

HTML포맷의 본문서 및 관련하는 문서의 최신판에 대해서는 이하의 것URL을 참조할 수 있다.

<ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>

요약

이 시방서는LZ77알고리즘과Huffman
encode의 병용에 의해 , 현재 이용되고 있는 최고의 범용 압축 방법과 동일한 정도의 효율로 데이터를 압축할 수 있는 무손실 압축 포맷에 대해 규정한다. 임의의 길이로 차례차례 수취되는 데이터 스트림에 대해서도 용량이 제한된 중간 정도의 용량의 기억장치를 사용해 데이터를 생성하거나 이용할 수가 있다. 이 포맷은 특허에 제한되는 일 없이 용이하게 프로그램 할 수가 있다.

목차

1. 처음에

1.1. 목적

1.2. 상정하고 있는 독자

1.3. 범위

1.4. 준거

1.5. 용어의 정의와 관용

1.6. 이전의 버젼으로부터의 변경점

2. 압축 표현 개관

3. 상세 사양

3.1. 기법

3.1.1. 아르바이트에의 패킹

3.2. 압축 블록 포맷

3.2.1. 프레픽스 encode와 허프만 코딩화의 개요

3.2.2. 데후레이트포맛트에서의 허프만 코딩화의 사용법

3.2.3. 블록 포맷의 상세

3.2.4. 비압축 블록(BTYPE=00)

3.2.5. 압축 블록(길이와 거리의 코드)

3.2.6. 고정 하프맨 코드에 의한 압축(BTYPE=01)

3.2.7. 다이나믹 하프맨 코드에 의한 압축(BTYPE=10)

3.3. 준거

4. 압축 알고리즘의 상세

5. References

6. Security Considerations

7. Source code

8. Acknowledgements

9. Author's Address

1. 처음에

1.1. 목적

이 시방서의 목적은 이하의 특징을 가지는 가역 데이터 압축 포맷을 규정하는 것이다.

*CPU타입 ,  operating system , 파일 시스템 , 캐릭터 세트에 의존하지 않는다. 따라서 , 상호 교환을 위해서(때문에) 사용할 수 있다.

*임의의 길이로 차례차례 수취되는 데이터 스트림에 대해서도 용량이 제한된 중간 정도의 용량의 기억장치를 사용해 데이터를 생성하거나 이용할 수가 있다. 따라서 , 데이터 통신가게Unix에서 이용되는 필터와 닮은 기구로 이용할 수가 있다.

*현재 이용되고 있는 최고의 범용 압축 방법과 동일한 정도의 효율로 데이터를 압축할 수 있어 특히"compress"프로그램보다 꽤 효율이 좋다.

*이 포맷은 특허에 제한되는 일 없이 용이하게 프로그램 할 수가 있다. 따라서 자유롭게 시험할 수가 있다.

*현재 넓게 사용되고 있는gzip유틸리티로 만들어지는 포맷과 호환성이 있기 (위해)때문에 , 사양에 따른 신장 프로그램은gzip압축 프로그램으로 만들어진 데이터를 신장 할 수가 있다.

이 사양에 규정되고 있는 데이터 포맷은 이하의 용도에는 적합하지 않는다.

*압축된 데이터에의 랜덤 억세스를 실시한다.

*특별한 데이터(래스터 그래픽스등 ) 를 대상으로 하거나 최고 수준의 특정 알고리즘으로 압축한다.

간단한 논의에 의해 아는 것하지만 , 어떤 입력 데이터에 대해서도 파일 사이즈를 작게 할 수 있는 무손실 압축 알고리즘이라는 것은 존재하지 않는다. 여기서 규정한 포맷의 경우 , 최악의 케이스로32K아르바이트에 대해5아르바이트 증가한다. 즉 , 큰 데이터의 경우 , 파일 사이즈는0.015%증가해 버린다. 영문의 경우 통상1/2.5으로부터1/3정도로 , 실행 파일에서는 약간 압축율이 나빠져 , 래스터 화상과 같은 화상 데이터에서는 좀 더 압축율이 좋아진다.

1.2. 상정하는 독자

이 시방서는 데후레이트("deflate") 포맷으로 데이터를 압축하거나 데후레이트포맛트궔등 데이터를 신장 하는 프로그램을 작성하려고 하는 사람에게 사용하는 것을 의도하고 있다.

이 시방서의 문장은 비트나 그 외의 기본적 데이터 표현 레벨의 프로그래밍에 관한 기초적인 지식이 있는 것을 전제로 쓰여져 있다. 하프맨(Huffman) encode에 관한 기술을 이해하고 있으면 도움이 되지만 , 필수는 아니다.

1.3. 범위

이 시방서는 아르바이트의 열을 (통상은 짧다 ) 비트의 열로 변환하는 방법과 비트열을 아르바이트열에 패킹 하는 방법에 대해 규정하고 있다.

1.4. 준거

이하에 명기되는 것 이외 , 이 사양에 준거하는 신장기는 사양에 있는 모든 방법에 따른 데이터 세트를 받아 신장 할 수 없으면 안 된다. 이 사양에 준거하는 압축기는 사양에 있는 모든 방법에 따라 데이터 세트를 생성할 수 없으면 안 된다.

1.5. 용어의 정의와 관용

아르바이트(Byte):하나의 덩어리로서 보관되거나 전송 되거나 하는8비트. 이 사양 중(안)에서는 비록 문자를8과는 다른 비트수로 보존하는 기계로 사용되는 경우에서도 1바이트는 엄밀하게8비트이다. 1아르바이트 중(안)에서의 비트순서에 대해서는 이하의 설명을 보는 것.

string(String):임의의 길이의 아르바이트열

1.6. 이전의 버젼으로부터의 변경점

버젼1.1의 시방서로부터 데후레이트포맛트에 관한 기술적인 변경은 없다. 버젼1.2에서는 용어의 변경이 있었다. 버젼1.3에서는RFC양식으로 시방서를 변경했다.

2. 압축 표현 개관

압축된 데이터 세트는 입력 데이터가 연속하는 블록에 대응해 , 일련의 블록으로부터 되어 있다. 블록은 , 비압축 블록이65,535아르바이트 이하에 제한되고 있는 이외는 임의의 크기가 되어 있다.

각각의 블록은 ,LZ77알고리즘과 하프맨
encode의 결합에 의해 압축된다. 각각의 블록의 하프맨 트리는 전후의 블록에 대해서 독립한 것이 이용된다. LZ77알고리즘에서는 전의 블록으로 처리한 입력 데이터에 대해서도 최대32K아르바이트전이면 , 중복 한 캐릭터 라인에의 참조를 실시할 수가 있다.

각각의 블록은 두 개의 부분 , 압축 데이터 부분의 표현을 기술한 한 벌의 하프맨 트리와 압축 데이터로부터 되어 있다. (하프맨 트리 자체도 하프맨
encode로 압축되고 있다. ) 압축된 데이터는2종류의 요소로부터 되어 있다. 2종류의 요소란 , 캐릭터 라인의 아스키 표기 그 자체(그 이전의32K아르바이트의 입력 캐릭터 라인에 나타나지 않은 캐릭터 라인) 와 중복되고 있는 캐릭터 라인에의 참조 기호이다. 참조 기호는 중복 캐릭터 라인의 길이 (이 이후는"길이"와 표기한다 ) 와 중복 부분의 개시 위치(이 이후는"거리"라고 표기한다 ) 의 한 벌로 나타난다. 데후레이트포맛트로 이용되고 있는 표현은 길이가258이내에서 , 거리가32K아르바이트에 제한되고 있지만 , 전에 말한 비압축 블록은 제외해 블록의 길이에 제한은 없다.

압축 데이터 부분의 문자 , 거리 , 길이라고 하는 각각의 타입의 값은 , 문자와 길이를 위한 트리와 거리의 트리를 사용해 하프맨
부호로 표현되고 있다. 블록 마다의 트리는 컴팩트하게 정리된 형식에서 그 블록의 압축 데이터 부분의 앞에 쓰여져 있다.

3. 상세 사양

3.1. 기법

다음의 박스는 1바이트를 나타낸다.

+---+
| | <-- 종선은 쓰여지지 않는 경우가 있는
+---+

다음의 박스는 수 아르바이트를 나타낸다.

+==============+
| |
+==============+

컴퓨터 중(안)에서 보존될 때 아르바이트는 항상 하나의 단위로서 다루어지기 (위해)때문에 비트 오더를 가지지 않는다. 그렇지만 ,1아르바이트를0로부터255의 정수로 생각했을 때 최상정도 비트(MSB)나 최하정도 비트(LSB)를 생각할 수가 있다. 숫자를 쓸 때 위의 높은 숫자를 왼쪽으로 쓰는 것과 같게 , 여기에서는 최상정도 비트를 좌단에 쓰기로 한다. 최상정도 비트를7, 최하정도 비트를0로서 아래의 그림과 같이 써 나타내기로 한다.

+--------+
|76543210|
+--------+

컴퓨터의 내부에서는 , 복수의 아르바이트로 수치를 나타내는 일이 있다. 여기에서는 복수 아르바이트의 수치는 , 최하정도 아르바이트를 선두(메모리아드레스의 낮은 편) 에 보존되고 있다고 한다. 예를 들면 ,10진수로520는 이하와 같이 보존된다.

0 1

+--------+--------+
|00001000|00000010|
+--------+--------+

^ ^

| |

| + 상위 아르바이트= 2 x 256

+ 하위 아르바이트= 8

3.1.1. 아르바이트에의 패킹

최종적인 데이터 포맷에서는 비트 단위의 차례는 아니고 아르바이트 단위의 차례가 기본이 되고 있기 (위해)때문에 , 이 문서에서는 비트 단위의 차례가 기본이 되는 미디어에 아르바이트안의 비트가 어떤 차례로 전송 될까에 대해서는 취급하지 않는다. 그렇지만 , 이하에 말하는 압축 블록의 포맷에서는 아르바이트의 줄이 아니고 , 다양한 bit length의 데이터 요소의 및 대해 말한다. 따라서 , 우리는 , 아르바이트순서에 줄지어 있는 최종적인 압축 데이터를 얻기 위해서(때문에) , 데이터 요소를 어떻게 해 아르바이트에 담을까에 임해서 명확하게 할 필요가 있다.

*데이터 요소의 아르바이트에의 패킹은 , 아르바이트 중(안)에서 비트 번호가 커질 방향으로 실시한다. 즉 , 아르바이트의 최하정도 비트로부터 스타트 한다.

*하프맨 코드 이외의 데이터 요소는 , 데이터 요소의 최하정도 비트로부터 채운다.

*하프맨 코드는 코드의 최상정도 비트로부터 채운다.

바꿔 말하면 , 아르바이트열로서의 압축 데이터를 프린트 아웃할 때에 , 최상정도 비트는 통상 대로 좌단으로 해 , 1번째 의 아르바이트를 오른쪽 마진으로 왼쪽을 향해 처리를 계속한다. 그러자(면) , 금방 다른 곳으로고정폭의 요소가 올바른MSB으로부터LSB에의 차례가 되어 결과를 쫓을 수가 있다. 하프맨 코드는 비트가 통상과 역의 차례(코드의 제1비트가 상대적으로 최하정도 비트 측에 오도록(듯이) )가 된다.

3.2. 압축 블록 포맷

3.2.1. 프레픽스 encode와 허프만 코딩화의 개요

프레픽스
encode 는 알파벳으로부터의 기호를 비트열로 완성된 코드로 나타낸다. 하나의 기호에 하나의 코드가 대응해 , 다른 기호는 다른 길이의 비트열로 나타날지도 모른다. 그러나 , 코드화 된 기호를 틀림없이 이해할 수가 있다.

우리의 정의하는 프레픽스코드는2분목의 용어로 말하면 , 노드로부터 분기 한 두 개의 가지는0과1에 라벨 붙이고 되는 , 잎 노드는 알파벳의 기호에 대응한다. 그리고 , 기호에 대한 코드는 루트 노드(최상정도에 있는 노드)로부터 기호가 있는 잎 노드까지의0와1의 숫자의 줄로 주어진다. 예를 들면 , 이하와 같이 표시된다.

NATURALSIZEFLAG="3">

복호는 코드의 비트열(0와1의 숫자의 줄)에 따라 루트 노드로부터 가지를 선택해 기호가 있는 잎 노드의 기호를 알 수가 있다.

기호의 출현 빈도를 알 수 있고 있는 경우 , 하프맨 알고리즘은 출현 빈도가 높은 기호에 비트수가 적은 프레픽스코드를 사용하기 (위해)때문에 최적화된 프레픽스코드를 생성할 수가 있다. 그러한 코드를 하프맨 코드라고 한다. (하프맨 코드에 대한 자세하게 알고 싶은 경우는 , 참고 문헌 1의 5장을 보는 것. )

데후레이트포맛트에서는 알파벳 기호에게 주는 하프맨 코드는 있는 bit length보다 길어져서는 안 된다. 이 제약이 기호의 출현 빈도로부터 코드의 길이를 계산하는 알고리즘을 복잡한 것으로 하고 있다. 자세하게는 , 참고 문헌 1의 5장을 보는 것.

3.2.2. 데후레이트포맛트에서의 허프만 코딩화의 사용법

데후레이트포맛트에서는 알파벳 기호에의 하프맨 코드의 주는 방법에 두 개의 룰을 추가했다.

*bit length가 주어졌을 때 기호가 사전의 차례로 되도록(듯이) 코드를 할당한다.

*bit length가 짧은 코드는 사전적으로 bit length가 긴 코드에 선행한다.

알파벳이ABCD의 순서일 때 , 이러한 룰에 따라 코드를 할당하면(자) 이하와 같이 된다.

기호 　코드

------ ----

A 10

B 0

C 110

D 111

즉 , (비트수의 짧다 )0는10의 전이 되어 있어 ,10는110,111의 전에 있다. 110(와)과111는 기호의 사전순서에 할당할 수 있고 있다.

이 룰에 따르면 , 기호의 사전적 차례로 기호 마다의 코드의 bit length 주는 것만으로 하프맨 코드를 알 수가 있다. 앞의 예에서는 bit length의 줄은(2, 1, 3,
3)된다. 이하의 알고리즘은 정수(상위 비트로부터 하위 비트를 향해 읽는다 ) 로서 코드를 생성한다. 코드장은tree[I].Len그리고 주어져 코드는tree[I].Code에 만들어진다.

1) 코드장마다 코드의 수를 카운트 한다. N>=1의 때 ,bl_count[N]를 코드장N의 코드 수라고 한다.

2) 코드장마다 최소의 코드의 수치를 찾아낸다.

code = 0;

bl_count[0] = 0;

for (bits = 1; bits <= MAX_BITS; bits++) {

code = (code + bl_count[bits-1]) << 1;

next_code[bits] = code;

}

3) 같은 bit length의 코드에는 스텝2에서 결정한 최소의 코드치로부터 일련 번호를 붙이는 것으로 , 모든 코드에 수치를 할당한다. 한번도 나타나지 않는 기호(bit length 0)에는 수치를 할당해서는 안 된다.

for (n = 0; n <= max_code; n++) {

len = tree[n].Len;

if (len != 0) {

tree[n].Code = next_code[len];

next_code[len]++;

}

}

예：

알파벳ABCDEFGH이 bit length(3, 3, 3, 3, 3, 2, 4, 4)의 경우를 생각한다. 스텝1이 끝나면(자) 이하와 같이 된다.

N bl_count[N]

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

2 1

3 5

4 2

스텝2에서는 다음의next_code값을 얻을 수 있다.

N next_code[N]

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

1 0

2 0

3 2

4 14

스텝3에서는 이하의 코드치를 얻을 수 있다.

Symbol Length Code

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

A 3 010

B 3 011

C 3 100

D 3 101

E 3 110

F 2 00

G 4 1110

H 4 1111

3.2.3. 블록 포맷의 상세

압축 데이터의 각각의 블록은 이하의 데이터로부터 되는3비트의 헤더로부터 시작된다.

제1비트 　BFINAL

다음의2비트 　BTYPE

블록은 정수 아르바이트이다고는 할 수 없기 때문에 , 헤더 비트는 반드시 아르바이트의 선두로부터 시작되지 않는 것에 주의하지 않으면 안 된다.

BFINAL(은)는 최종 블록일 때만 세트 된다.

BTYPE(은)는 이하와 같이 압축 방법을 나타내고 있다.

00 - 비압축

01 - 고정 하프맨 코드 압축

10 - 다이나믹 하프맨 코드 압축

11 - 예약(에러)

2종류의 압축 방법의 차이는 , 문자/길이 용무와 거리용의 하프맨 코드의 정의의 방법에 의하는 것이다.

모든 케이스에 대해서 실제의 데이터의 신장 알고리즘은 이하와 같은 것이다.

do

read block header from input stream.

if stored with no compression

skip any remaining bits in current partially

processed byte

read LEN and NLEN (see next section)

copy LEN bytes of data to output

otherwise

if compressed with dynamic Huffman codes

read representation of code trees (see

subsection below)

loop (until end of block code recognized)

decode literal/length value from input stream

if value < 256

copy value (literal byte) to output stream

otherwise

if value = end of block (256)

break from loop

otherwise (value = 257..285)

decode distance from input stream

move backwards distance bytes in the output

stream, and copy length bytes from this

position to the output stream.

end loop

while not last block

중복 한 캐릭터 라인에의 참조는 전의 블록에도 미치는 것에 주의가 필요하다. 즉 , 신장 끝난 캐릭터 라인에의 거리는 수 블록전의 것이 될 수도 있다. 그렇지만 , 거리는 , 출력 캐릭터 라인의 개시점보다 멀리 될 것은 없다. (고정 사전을 사용하고 있는 어플리케이션은 출력 캐릭터 라인의 일부를 파기하는 일이 있다. 거기에 따르지 않고 , 거리는 출력도 초조해지고 개의 파기된 부분을 참조할 수가 있다. ) 게다가 주의가 필요한 일하지만 , 참조되는 캐릭터 라인은 현재의 장소에 부분적과 겹쳐지도록(듯이) 참조될지도 모른다. 예를 들면 , 신장 끝난 마지막2문자가x와y에서 만났을 때 ,<length
= 5, distance = 2>그리고 캐릭터 라인이 참조되면 ,XYXYX을 출력한다.

그런데 , 개개의 압축 방법을 차례로 설명한다.

3.2.4. 비압축 블록(BTYPE=00)

다음의 아르바이트 경계까지 모든 비트를 무시한다.

나머지의 블록은 다음과 같은 정보로부터 되어 있다.

0 1 2 3 4...

+---+---+---+---+================================+
| LEN | NLEN |... LEN
bytes of literal
data...|
+---+---+---+---+================================+

LEN(은)는 블록에 들어가 있는 데이터의 아르바이트수. NLEN(은)는LEN의1의 보수.

3.2.5. 압축 블록(길이와 거리의 코드)

지금까지 말해 온 것처럼 , 데후레이트포맛트의 코드화 된 데이터의 블록은3종류의 개념이 다른 알파벳으로부터 끌린 기호의 열로부터 되어 있다.

3종류의 개념이 다른 알파벳이란 ,(0..255)의 아르바이트치를 가지는 문자 , 혹은 , 길이와 귀가 방향의 거리로부터 되는 한 벌의 기호이다. 길이는(3..258)중에서 선택되어 거리는(1..32,768)으로부터 선택된다. 실제는 문자와 길이는(0..285)의 하나의 알파벳에 합성되어0..255는 문자를 ,256은 블록의 종단 ,257..285은 경우에 의해 계속하는 추가 비트를 가져 길이의 기호를 의미한다.

Extra Extra Extra

Code Bits Length(s) Code Bits Lengths Code Bits Length(s)

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

257 0 3 267 1 15,16 277 4 67-82

258 0 4 268 1 17,18 278 4 83-98

259 0 5 269 2 19-22 279 4 99-114

260 0 6 270 2 23-26 280 4 115-130

261 0 7 271 2 27-30 281 5 131-162

262 0 8 272 2 31-34 282 5 163-194

263 0 9 273 3 35-42 283 5 195-226

264 0 10 274 3 43-50 284 5 227-257

265 1 11,12 275 3 51-58 285 0 258

266 1 13,14 276 3 59-66

추가 비트는 최상정도 비트가 선두가 되는 차례로 기록된 정수이며 , 예를 들면1110은14이라고 하는 값이 된다.

Extra Extra Extra

Code Bits Dist Code Bits Dist Code Bits Distance

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

0 0 1 10 4 33-48 20 9 1025-1536

1 0 2 11 4 49-64 21 9 1537-2048

2 0 3 12 5 65-96 22 10 2049-3072

3 0 4 13 5 97-128 23 10 3073-4096

4 1 5,6 14 6 129-192 24 11 4097-6144

5 1 7,8 15 6 193-256 25 11 6145-8192

6 2 9-12 16 7 257-384 26 12 8193-12288

7 2 13-16 17 7 385-512 27 12 12289-16384

8 3 17-24 18 8 513-768 28 13 16385-24576

9 3 25-32 19 8 769-1024 29 13 24577-32768

3.2.6. 고정 하프맨 코드에 의한 압축(BTYPE=01)

2종류의 알파벳에 대한 하프맨 코드는 고정되고 있어 , 데이터안에는 나타나지 않았다. 문자·길이의 알파벳에 대한 코드장은 이하와 같다.

Lit Value Bits Codes

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

0 - 143 8 00110000 through

10111111

144 - 255 9 110010000 through

111111111

256 - 279 7 0000000 through

0010111

280 - 287 8 11000000 through

11000111

코드장은 실제의 코드를 생성하는데 충분한 길이를 가지고 있다. 알기 쉽게 위의 테이블에서는 코드도 가리켜 두었다. 문자Ⅱ堧缺?값으로286-287는 실제로는 결코 압축 데이터안에 나타나지 않지만 , 코드의 구성에 필요하고 있다.

거리 코드0-31는 고정장의5비트로 ,3.2.5의 겉(표)로 가리킨 것처럼 필요에 따라서 추가 비트를 가진다. 거리 코드30-31는 실제로는 결코 압축 데이터안에 나타나지 않는다.

3.2.7. 다이나믹 하프맨 코드에 의한 압축(BTYPE=10)

2종류의 알파벳에 대한 하프맨 코드는 헤더 비트의 직후에 압축 데이터 부분의 앞에 문자Ⅱ堧?코드 , 거리 코드의 순서로 쓰여져 있다. 각각의 코드는3.2.2으로 쓴 것처럼 코드장을 늘어놓은 것이 되어 있다. 한층 더 압축율을 올리기 위해서(때문에) , 코드장의 줄 자체가 하프맨 코드가 사용되고 있다. 코드장에의 알파벳은 이하와 같이 되어 있다.

0 - 15: Represent code lengths of 0 - 15

16: Copy the previous code length 3 - 6 times.

The next 2 bits indicate repeat length

(0 = 3, ... , 3 = 6)

Example: Codes 8, 16 (+2 bits 11),

16 (+2 bits 10) will expand to

12 code lengths of 8 (1 + 6 + 5)

17: Repeat a code length of 0 for 3 - 10 times.

(3 bits of length)

18: Repeat a code length of 0 for 11 - 138 times

(7 bits of length)

코드장0은 대응하는 문자·길이와 거리의 알파벳이 그 블록에는 존재하지 않는 것을 나타내고 있다. 그리고 그 코드는 초에 나타낸 하프맨 코드의 구성 알고리즘과 관계되어서는 안 된다. 만약 , 다만 하나의 거리 코드 밖에 사용되지 않을 때에는 ,0비트가 아니고 ,1비트로 기호화하지 않으면 안 된다. 이 경우 코드장 1의 하나의 코드와 사용되지 않은 코드로 구성된다. 0비트의1개의 거리 코드는 완전히 거리 코드가 사용되지 않은 것을 나타낸다. (즉 , 데이터는 모두 문자 코드로부터 된다. )

깨지고 개이고는 , 블록의 포맷을 나타낼 수 있을 단계에 왔다.

5 Bits: HLIT, # of Literal/Length codes - 257 (257 - 286)

5 Bits: HDIST, # of Distance codes - 1 (1 - 32)

4 Bits: HCLEN, # of Code Length codes - 4 (4 - 19)

(HCLEN + 4) x 3 bits: 코드장을 나타내는 알파벳을 위한 코드장은 이하의 차례로 주어지는: 16, 17, 18, 0, 8,
7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1,15

이러한 코드장은3비트 정수이다고 해석된다. 코드장0은 대응하는 심볼(문자Ⅱ堧?코드 , 거리 코드) 이 사용되지 않은 것을 나타낸다.

HLIT + 257 문자Ⅱ堧?알파벳용의 코드장으로 코드장용 하프맨 코드로 기호화 되고 있는

HDIST + 1 거리 알파벳용의 코드장으로 코드장용 하프맨 코드로 기호화 되고 있는

문자Ⅱ堧?, 거리 하프맨 코드로 기호화 된 , 블록의 실제의 압축 데이터

문자Ⅱ堧?하프맨 코드로 기호화 된 , 문자Ⅱ堧?값256(블록의 종단)

코드장 반복 코드는 HLIT + 257 으로부터HDIST + 1 까지. 바꿔 말하면 , 모든 코드장은 단일의 것HLIT + HDIST +
258의 순서를인가 온다.

3.3. 준거

압축 소프트는 전의 섹션으로 규정된 값의 범위를 한층 더 한정을 더할 수가 있어 그런데도 호환성을 유지할 수 있다. 예를 들면 , 뒤 방향에의 pointer의 거리로서32K보다 적은 값으로 한정할 수가 있다. 같이 블록 사이즈를 제한해 메모리 용량에 맞은 압축 블록으로 할 수가 있다.

신장 소프트는 규정되는 모든 값에 대응해 , 임의의 블록 사이즈에 대응해야 한다.

4. 압축 알고리즘의 상세

특정의 압축 알고리즘에 의하지 않고 데후레이트포맛트를 규정하는 것이 본문서의 목적이지만 , 이 포맷은LZ77(Lempel-Ziv 1977,
문헌[2]참조)에 의해 만들어진 압축 포맷에 관련하고 있다. LZ77(이)가 많은 변형판이 특허가 되고 있으므로 , 압축 프로그램의 작성은 여기서 소개하는 특허에 묶이지 않는 알고리즘에 따르는 것을 강하게 권한다. 이 장은 사양은 아니기 때문에 , 호환성의 관점으로부터는 압축 소프트는 이것들에 따를 필요는 없다.

압축기는 새로운 하프맨목을 만드는 것이 좋다고 판단했을 때 , 혹은 , 블록 사이즈가 블록 버퍼를 넘을 것 같게 되었을 때에 블록을 종료시킨다.

압축기는 중복 하고 있는 캐릭터 라인을 찾아내기 위해서(때문에)3아르바이트 캐릭터 라인에 대한 연결된 해시 테이블을 사용한다. 압축 과정의 어느 시점에서도 상관없지만 ,xyz이 다음에 압축하려고 하고 있는 캐릭터 라인이었다고 하자. 물론xyz이 모두 다른 문자일 필요는 없다. 압축기는 제1에xyz에 대한 해시 체인을 조사한다. 만약 , 그 체인이 하늘에서 만났을 때에는 압축기는x을 써내 입력을 하나 먼저 진행한다. 만약 , 체인이 하늘이 아니었을 때에는 ,xyz(혹은 , 불행하게 해 , 같은 해시치를 가지는 다른3아르바이트 캐릭터 라인일지도 모르지만 , ) 의 캐릭터 라인은 과거에 있던 것이  되어 , 압축기는 현시점의 pointer로부터 시작되는 입력 캐릭터 라인과xyz해시 체인에 있는 모든 캐릭터 라인을 비교해 , 가장 길게 일치하고 있는 캐릭터 라인을 선택한다.

압축기는 거리가 작을 정도 하프맨 코드가 짧아지므로 , 최근의 캐릭터 라인으로부터 해시 체인을 찾기 시작한다. 해시 체인은 단일의 링크이다. 해시 체인으로부터의 삭제는 실시하지 않는다. 알고리즘은 거리가 긴 성냥은 버리고 간다. 최악의 상황을 피하기 위해서(때문에) , 매우 긴 해시 체인은 실행시의 파라미터에 의해 있는 길이에 임의로 줄일 수 있다.

전체의 압축 성능을 향상시키기 위해서(때문에) , 압축기는 옵션으로 일치의 결정을 먼저 늘리는("lazy
matching")일이 생긴다. 길이N의 일치가 있었을 때 압축기는 다음의 입력 아르바이트로부터 시작되고 말이야들 에게 긴 일치가 있을까 조사한다. 한층 더 긴 일치가 발견되었을 때에는 , 전에 찾아낸 일치 캐릭터 라인은 1문자에 감소 해 (따라 , 한 개의 문자를 출력한다 ) , 나중에 찾아냈던 것보다 긴 일치 캐릭터 라인을 채용한다. 한층 더 긴 캐릭터 라인이 발견되지 않았던 경우는 , 처음의 일치 캐릭터 라인을 채용한다. 그리고 , 전에 말한 것처럼N아르바이트분 먼저 진행한다.

실행시의 파라미터로"lazy
match"의 조건을 설정할 수 있다. 만약 , 압축율이 가장 중요한 경우 , 압축기는 처음의 일치 캐릭터 라인의 길이에 관계없이 , 제2의 일치를 찾는다. 통상의 설정의 것에서는 , 일치한 캐릭터 라인이 충분히 길 때 , 압축기는 한층 더 긴 일치를 찾지 않고 , 처리를 고속화한다. 처리 스피드가 가장 중요한 때에는 , 일치하지 않는 캐릭터 라인의 경우인가 , 일치가 짧을 때만 새로운 캐릭터 라인을 해시 테이블에 삽입한다. 이것에 의해 , 압축비는 저하하지만 , 삽입과 검색의 양쪽 모두를 줄이기 (위해)때문에 , 시간을 짧게 할 수가 있다.

5. References

[1] Huffman, D. A., "A Method for the Construction of Minimum

Redundancy Codes", Proceedings of the Institute of Radio

Engineers, September 1952, Volume 40, Number 9, pp. 1098-1101.

[2] Ziv J., Lempel A., "A Universal Algorithm for Sequential Data

Compression", IEEE Transactions on Information Theory, Vol. 23,

No. 3, pp. 337-343.

[3] Gailly, J.-L., and Adler, M., ZLIB documentation and sources,

available in ftp://ftp.uu.net/pub/archiving/zip/doc/

[4] Gailly, J.-L., and Adler, M., GZIP documentation and sources,

available as gzip-*.tar in ftp://prep.ai.mit.edu/pub/gnu/

[5] Schwartz, E. S., and Kallick, B. "Generating a canonical prefix

encoding." Comm. ACM, 7,3 (Mar. 1964), pp. 166-169.

[6] Hirschberg and Lelewer, "Efficient decoding of prefix codes,"

Comm. ACM, 33,4, April 1990, pp. 449-459.

6. Security Considerations

Any data compression method involves the reduction of redundancy in

the data. Consequently, any corruption of the data is likely to have

severe effects and be difficult to correct. Uncompressed text, on

the other hand, will probably still be readable despite the presence

of some corrupted bytes.

It is recommended that systems using this data format provide some

means of validating the integrity of the compressed data. See

reference [3], for example.

7. Source code

Source code for a C language implementation of a "deflate" compliant

compressor and decompressor is available within the zlib package at

ftp://ftp.uu.net/pub/archiving/zip/zlib/.

8. Acknowledgements

Trademarks cited in this document are the property of their

respective owners.

Phil Katz designed the deflate format. Jean-Loup Gailly and Mark

Adler wrote the related software described in this specification.

Glenn Randers-Pehrson converted this document to RFC and HTML format.

9. Author's Address

L. Peter Deutsch

Aladdin Enterprises

203 Santa Margarita Ave.

Menlo Park, CA 94025

Phone: (415) 322-0103 (AM only)

FAX: (415) 322-1734

EMail: <ghost@aladdin.com>

Questions about the technical content of this specification can be

sent by email to:

Jean-Loup Gailly <gzip@prep.ai.mit.edu> and

Mark Adler <madler@alumni.caltech.edu>

Editorial comments on this specification can be sent by email to:

L. Peter Deutsch <ghost@aladdin.com> and

Glenn Randers-Pehrson <randeg@alumni.rpi.edu>

이 메모의 스테이터스 ,IESG의 노트 , 공지사항의 원문

Status of This Memo

This memo provides information for the Internet community. This memo

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

IESG Note:

The IESG takes no position on the validity of any Intellectual

Property Rights statements contained in this document.

Notices

Copyright (c) 1996 L. Peter Deutsch

Permission is granted to copy and distribute this document for any

purpose and without charge, including translations into other

languages and incorporation into compilations, provided that the

copyright notice and this notice are preserved, and that any

substantive changes or deletions from the original are clearly

marked.

  

  

---

     target=_top href='http://j2k.naver.com/j2k_frame.php/korean/www.asahi-net.or.jp/~WR9K-OOHS/Pages/Nigel' s/Nigel58/nigel58.html'>돌아온다