Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 4개 있습니다.)
.NET Framework: 333. 코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)
; https://www.sysnet.pe.kr/2/0/1334

.NET Framework: 334. 스레드 비정상 종료로 발생하는 CLOSE_WAIT 소켓 상태
; https://www.sysnet.pe.kr/2/0/1336

.NET Framework: 849. C# - Socket의 TIME_WAIT 상태를 없애는 방법
; https://www.sysnet.pe.kr/2/0/11996

.NET Framework: 2062. C# - 코드로 재현하는 소켓 상태(SYN_SENT, SYN_RECV)
; https://www.sysnet.pe.kr/2/0/13153




스레드 비정상 종료로 발생하는 CLOSE_WAIT 소켓 상태

보통, 서버 측 소켓에서는 Accept 후 클라이언트 측 과의 통신을 별도의 스레드에 할당해서 처리합니다. 간략하게 코드를 만들어 보면 다음과 같은 식인데요.

static void Main(string[] args)
{
    TcpListener listener = new TcpListener(6000);
    listener.Start();
            
    while (true)
    {
        TcpClient childSocket = listener.AcceptTcpClient();

        Thread thread = new Thread(tcpClient_Connected);
        thread.Start(childSocket); // 혹은 스레드 풀을 사용하거나.
    }
}

static void tcpClient_Connected(object obj)
{
    TcpClient socket = obj as TcpClient;
    Thread.Sleep(1000 * 10); // 테스트를 위해 10초 동안 대기
    socket.Close();
}

그런데, 여기서 만약 tcpClient_Connected 메서드를 처리하는 스레드가 비정상 종료하는 상황이 발생했다고 가정해 보겠습니다.

static void Main(string[] args)
{
    ... [생략] ...
    
        Thread thread = new Thread(tcpClient_Connected);
        thread.Start(childSocket);
        ThreadPool.QueueUserWorkItem(abortThread, thread);
    
    ... [생략] ...

}

static void tcpClient_Connected(object obj)
{
    ... [생략] ...
}

static void abortThread(object obj)
{
    Thread thread = obj as Thread;
    Thread.Sleep(5000); // 5초 후에 스레드 강제 종료
    thread.Abort();
}

이렇게 되면, 당연히 서버 측 대응 소켓은 Close 메서드를 호출하지 못하게 되고 클라이언트 측 소켓이 Close를 하는 시점에 CLOSE_WAIT으로 빠지게 됩니다.

CLOSE_WAIT 상태에 대해서는 지난번 글에서 자세히 설명했으므로 여기서는 넘어가겠습니다.

코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)
; https://www.sysnet.pe.kr/2/0/1334

이런 상황을 개선하려면 tcpClient_Connected 메서드 내에서 예외 처리를 추가해 줄 수 있습니다.

static void tcpClient_Connected(object obj)
{
    TcpClient socket = obj as TcpClient;

    try
    {
        Thread.Sleep(1000 * 10); // 테스트를 위해 10초 동안 대기
    } 
    catch { }
    finally
    {
        socket.Close();
    }
}

finally에 의해서 소켓은 닫히게 되도록 했지만, 그래도 뭔가 미심쩍습니다. 왜냐하면 스레드 비정상 종료 현상은 이후의 어떤 코드도 실행하지 못할 가능성이 더 크기 때문에 저 정도의 처리로는 부족하기 때문입니다.

바로 이럴 때 적합하게 사용할 수 있는 것이 CER(constrained execution region)입니다.

RuntimeHelpers.PrepareConstrainedRegions Method 
; https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.runtimehelpers.prepareconstrainedregions

예외처리 블록을 CER로 지정해 주면 해당 코드는 반드시 실행되도록 JIT 컴파일까지 미리 시켜 놓기 때문에 안전하게 Close 메서드를 호출할 수 있게 됩니다. 방법도 그다지 어렵지 않은데, 단순히 try 블록이 시작되기 전에 RuntimeHelpers.PrepareConstrainedRegions 메서드만 불러주면 됩니다.

그리하여, 스레드 비정상 종료에도 안전하게 소켓을 해제하는 코드는 다음의 형태를 갖게 됩니다.

static void tcpClient_Connected(object obj)
{
    TcpClient socket = obj as TcpClient;
    RuntimeHelpers.PrepareConstrainedRegions();
    try
    {
        Thread.Sleep(5000 * 60);
    }
    catch
    { }
    finally
    {
        socket.Close();
    }
}

단순한 TCP 서버에서는 위와 같은 처리를 안해도 무리는 없지만, 24시간/365일 구동되는 시스템이라면 꼭 필요한 장치일 수 있겠지요. ^^

(첨부파일은 위의 상황을 테스트 할 수 있는 간략한 예제입니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 6/27/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2012-08-31 08시57분
[Lyn] 으아... 닷넷 깊이 들어가면 끝도 없군요
[guest]
2012-08-31 02시37분
꼭 닷넷이라고 한정지을 필요는 없을 것 같습니다. 다른 플랫폼에서도, 스레드가 강제 종료하는 상황에서 자원을 해제할 수 있는 코드가 실행됨을 보장해야 하는 방법이 "내재해 있거나" 또는 "없거나" 또는 "제공되어야만" 할 테니까요. ^^
정성태

... [151]  152  153  154  155  156  157  158  159  160  161  162  163  164  165  ...
NoWriterDateCnt.TitleFile(s)
1308정성태7/3/201227289.NET Framework: 330. IEnumerator는 언제나 읽기 전용일까?파일 다운로드1
1307정성태6/30/201229631개발 환경 구성: 154. Sysnet, Azure를 만나다. [5]
1306정성태6/29/201230093제니퍼 .NET: 22. 눈으로 확인하는 connectionManagement의 maxconnection 설정값 [4]
1305정성태6/28/201228415오류 유형: 157. IIS 6 - WCF svc 호출 시 404 Not Found 발생
1304정성태6/27/201229212개발 환경 구성: 153. sysnet 첨부 파일을 Azure Storage에 마이그레이션 [3]파일 다운로드1
1303정성태6/26/201228789개발 환경 구성: 152. sysnet DB를 SQL Azure 데이터베이스로 마이그레이션
1302정성태6/25/201230727개발 환경 구성: 151. Azure 웹 사이트에 사용자 도메인 네임 연결하는 방법
1301정성태6/20/201227050오류 유형: 156. KB2667402 윈도우 업데이트 실패 및 마이크로소프트 Answers 웹 사이트 대응
1300정성태6/20/201233575.NET Framework: 329. C# - Rabin-Miller 소수 생성방법을 이용하여 RSACryptoServiceProvider의 개인키를 직접 채워보자 [1]파일 다운로드2
1299정성태6/18/201234194제니퍼 .NET: 21. 제니퍼 닷넷 - Ninject DI 프레임워크의 성능 분석 [2]파일 다운로드2
1298정성태6/14/201235838VS.NET IDE: 72. Visual Studio에서 pfx 파일로 서명한 경우, 암호는 어디에 저장될까? [2]
1297정성태6/12/201232340VC++: 63. 다른 프로세스에 환경 변수 설정하는 방법파일 다운로드1
1296정성태6/5/201228880.NET Framework: 328. 해당 DLL이 Managed인지 / Unmanaged인지 확인하는 방법 - 두 번째 이야기 [4]파일 다운로드1
1295정성태6/5/201226304.NET Framework: 327. RSAParameters와 System.Numerics.BigInteger 이야기파일 다운로드1
1294정성태5/27/201250373.NET Framework: 326. 유니코드와 한글 - 유니코드와 닷넷을 이용한 한글 처리 [7]파일 다운로드2
1293정성태5/24/201230830.NET Framework: 325. System.Drawing.Bitmap 데이터를 Parallel.For로 처리하는 방법 [2]파일 다운로드1
1292정성태5/24/201224542.NET Framework: 324. First-chance exception에 대해 조건에 따라 디버거가 멈추게 할 수는 없을까? [1]파일 다운로드1
1291정성태5/23/201231448VC++: 62. 배열 초기화를 위한 기계어 코드 확인 [2]
1290정성태5/18/201236335.NET Framework: 323. 관리자 권한이 필요한 작업을 COM+에 대행 [7]파일 다운로드1
1289정성태5/17/201240651.NET Framework: 322. regsvcs.exe로 어셈블리 등록 시 시스템 변경 사항 [5]파일 다운로드2
1288정성태5/17/201227639.NET Framework: 321. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (3) - Type Library파일 다운로드1
1287정성태5/17/201230439.NET Framework: 320. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (2) - .NET 4.0 + .NET 2.0 [2]
1286정성태5/17/201239326.NET Framework: 319. regasm.exe로 어셈블리 등록 시 시스템 변경 사항 (1) - .NET 2.0 + x86/x64/AnyCPU [5]
1285정성태5/16/201234457.NET Framework: 318. gacutil.exe로 어셈블리 등록 시 시스템 변경 사항파일 다운로드1
1284정성태5/15/201226900오류 유형: 155. Windows Phone 연결 상태에서 DRIVER POWER STATE FAILURE 블루 스크린 뜨는 현상
1283정성태5/12/201234530.NET Framework: 317. C# 관점에서의 Observer 패턴 구현 [1]파일 다운로드1
... [151]  152  153  154  155  156  157  158  159  160  161  162  163  164  165  ...