Microsoft MVP성태의 닷넷 이야기
닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점 [링크 복사], [링크+제목 복사],
조회: 10354
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)

C# - SuperSimpleTcp 사용 시 주의할 점

혹시 SuperSimpleTcp를 사용하는 분이 계실까요?

SuperSimpleTcp
; https://github.com/jchristn/supersimpletcp

^^ 지난 글에도 한 번 언급한 라이브러리인데,

C# - TCP KeepAlive에 새로 추가된 Retry 옵션
; https://www.sysnet.pe.kr/2/0/13531

그런대로 사용법이 재미있습니다. 우선, 간단하게 서버를 README에 있는 기본 예제 코드를 살짝 바꿔 시작해 보겠습니다.

using SuperSimpleTcp;
using System;
using System.Text;

namespace ConsoleApp1
{
    // Install-Package SuperSimpleTcp
    internal class Program
    {
        static void Main(string[] args)
        {
            // instantiate
            using (SimpleTcpServer server = new SimpleTcpServer("*:18500"))
            {

                // set events
                server.Events.ClientConnected += ClientConnected;
                server.Events.ClientDisconnected += ClientDisconnected;
                server.Events.DataReceived += DataReceived;

                // let's go!
                server.Start();

                Console.ReadKey();
            }
        }

        static void ClientConnected(object sender, ConnectionEventArgs e)
        {
            Log($"[{e.IpPort}] client connected");
        }

        static void ClientDisconnected(object sender, ConnectionEventArgs e)
        {
            Log($"[{e.IpPort}] client disconnected: {e.Reason}");
        }

        static void DataReceived(object sender, DataReceivedEventArgs e)
        {
            Log($"[{e.IpPort}]: Received - {Encoding.UTF8.GetString(e.Data.Array, 0, e.Data.Count)}");

            SimpleTcpServer socket = sender as SimpleTcpServer;
            if (socket == null)
            {
                return;
            }

            socket.Send(e.IpPort, "Hello World from server");
        }

        private static void Log(string text)
        {
            Console.WriteLine($"[{DateTime.Now:mm ss fff}] {text}");
        }
    }
}

위의 코드를 보면, 서버이면서도 Accept를 이용한 클라이언트 소켓을 내부적으로 감춰 클라이언트로의 Send, Receive를 "Ip:Port"의 조합으로 식별해 송수신할 수 있도록 추상화시켰습니다.

// 클라이언트에서 오는 데이터는 SimpleTcpServer.DataReceived 이벤트로 처리하고,
static void DataReceived(object sender, DataReceivedEventArgs e)
{
    // 데이터를 보낸 클라이언트의 식별은 "e.IpPort"를 이용
    Log($"[{e.IpPort}]: Received - {Encoding.UTF8.GetString(e.Data.Array, 0, e.Data.Count)}");

    SimpleTcpServer socket = sender as SimpleTcpServer;
    if (socket == null)
    {
        return;
    }

    // 해당 클라이언트로의 데이터 송신은 "e.IpPort"로 식별해 처리
    socket.Send(e.IpPort, "Hello World from server");
}

클라이언트도 유사한 사용자 경험으로 처리하도록 추상화를 했기 때문에 사용법이 비슷합니다. 단지, 서버를 식별할 필요는 없으므로 IpPort에 대한 식별만 Send 시에 할 필요가 없습니다.

using SuperSimpleTcp;
using System;
using System.Text;

namespace ConsoleApp2
{
    // Install-Package SuperSimpleTcp
    internal class Program
    {
        static void Main(string[] args)
        {
            string host = "192.168.100.50";

            // instantiate
            SimpleTcpClient client = new SimpleTcpClient($"{host}:18500");

            // set events
            client.Events.Connected += Connected;
            client.Events.Disconnected += Disconnected;
            client.Events.DataReceived += DataReceived;

            // let's go!
            client.Connect();

            // once connected to the server...
            client.Send("Hello, world!");
            Console.ReadKey();
        }

        static void Connected(object sender, ConnectionEventArgs e)
        {
            Log($"*** Server {e.IpPort} connected");
        }

        static void Disconnected(object sender, ConnectionEventArgs e)
        {
            Log($"*** Server {e.IpPort} disconnected");
        }

        static void DataReceived(object sender, DataReceivedEventArgs e)
        {
            Log($"[{e.IpPort}] {Encoding.UTF8.GetString(e.Data.Array, 0, e.Data.Count)}");
        }

        private static void Log(string text)
        {
            Console.WriteLine($"[{DateTime.Now:mm ss fff}] {text}");
        }
    }
}

대충 사용법을 아시겠죠? ^^




그런데, SuperSimpleTcp가 너무 추상화를 잘해서 간과할 수 있는 문제점이 하나 있는데요, 바로 TCP 통신은 Stream-oriented 방식이므로 단순히 한 번의 DataReceived만으로 처리할 수 없는 경우가 발생할 수 있다는 점입니다.

일례로, 대개의 경우는 TCP로 데이터 송/수신을 할 때 패킷의 구조를 정의할 것이고 그로 인해 가변적인 데이터 길이를 갖는 것이 일반적입니다. 하지만 위의 경우는 DataReceived 측에서 단순히 TCP 레벨에서 올려주는 한 번의 recv 호출로 받은 데이터만을 다루기 때문에 재조합에 따른 문제가 발생합니다.

재현을 위해, 위의 예제에서 서버 측의 DataReceived에서 Send를 2번 호출하도록 바꾸면,

static void DataReceived(object sender, DataReceivedEventArgs e)
{
    Log($"[{e.IpPort}]: Received - {Encoding.UTF8.GetString(e.Data.Array, 0, e.Data.Count)}");

    SimpleTcpServer socket = sender as SimpleTcpServer;
    if (socket == null)
    {
        return;
    }

    socket.Send(e.IpPort, "Hello World from server");
    socket.Send(e.IpPort, "Hello World from server");
}

이제 클라이언트는 네트워크 상황에 따라 이렇게 데이터를 나눠 받거나,

[53 19 549] *** Server 192.168.0.22:18500 connected
[53 19 581] [192.168.0.22:18500] Hello World from server
[53 19 581] [192.168.0.22:18500] Hello World from server

두 번의 send 데이터를 한 번에 수신하기도 하거나,

[53 21 564] *** Server 192.168.0.22:18500 connected
[53 21 575] [192.168.0.22:18500] Hello World from serverHello World from server

만약 두 번에 이은 send 전송이 또 있다면 연이어 받기도 합니다.

[53 21 564] *** Server 192.168.0.22:18500 connected
[53 19 581] [192.168.0.22:18500] Hello World from server
[53 19 581] [192.168.0.22:18500] Hello World from server이어진 데이터

위의 경우는 단순한 텍스트였지만, 만약 JSON 데이터를 Send/Receive로 받는 식이었다면,

// json을 2번 전송한다고 가정

Send({ "name": "kevin", "age": 5 })
Send({ "name": "winnie", "age": 5 })

수신 측에서는 다음과 같이 한꺼번에 오는 경우도 발생하기 때문에,

{ "name": "kevin", "age": 5 }{ "name": "winnie", "age": 5 }

DataReceived에서 곧바로 JsonSerializer.Deserialize를 호출했다면 오류가 발생할 수 있습니다. 또한, 데이터 길이가 긴 데이터를 송신한다면 수신 측에서는 나눠서 받는 상황도 고려해야 합니다. (이런 경우에도 Json 데이터라면 완벽하게 조합되지 않아 Deserialize에 실패합니다.)

이런 문제를 없애려면, 송신 측에서는 반드시 데이터 길이에 대한 정보를 줘야 하고,

string text = new string('a', 16384 * 2);

byte [] buffer = BitConverter.GetBytes(text.Length);
socket.Send(e.IpPort, buffer); // 처음 4바이트는 무조건 데이터 길이
socket.Send(e.IpPort, text); // 이후 해당하는 데이터만큼 전송

수신 측에서는 (대충 만들어도 복잡한) 패킷 조합을 하는 코드를 다음과 같이 추가해야 합니다.

static MemoryStream _assembleBuffer;

static void DataReceived(object sender, DataReceivedEventArgs e)
{ 
    // 먼저 4바이트를 읽어 데이터의 전체 크기를 알아내고,
    int dataLength = BitConverter.ToInt32(e.Data.Array, 0);

    if (_assembleBuffer == null && dataLength == e.Data.Count - 4)
    {
        // 한 번에 전체 데이터를 받았다면 처리
        ProcessData(e.Data.Array, 4);
        return;
    }

    // 한 번에 받지 못했다면, 패킷 조합을 위한 단계로 진입
    if (_assembleBuffer == null)
    {
        _assembleBuffer = new MemoryStream(dataLength);
        _assembleBuffer.Write(e.Data.Array, 4, e.Data.Count - 4);
        return;
    }
    else
    {
        _assembleBuffer.Write(e.Data.Array, 0, e.Data.Count);
        if (_assembleBuffer.Position != _assembleBuffer.Capacity)
        {
            return;
        }
    }

    // 모든 데이터가 조합이 되었다면 처리
    ProcessData(_assembleBuffer.ToArray(), 0);
    return;
}

static private void ProcessData(byte[] array, int offset)
{
    string text = Encoding.UTF8.GetString(array, offset, array.Length - offset);
    text = text.Substring(0, 100);
    Log($"offset: {offset}, length: {array.Length}, {text}");
}

실제로 제가 테스트한 환경에서는 서버에서 Send(4), Send(32768) 2번의 호출에 대해 수신 시 다음과 같이 다양한 유형으로 처리가 되었습니다.

[유형 1]
Recv(4 + 32768) 모두 한 번에 수신

[유형 2]
Recv(4), Recv(32768)로 두 번에 수신

[유형 3]
Recv(4), Recv(7300), Recv(20440), Recv(5028)과 같은 식으로 다중 수신

심지어 위의 코드는, 송신 측에서 전달한 데이터가 또다시 연이어 붙어 있는 경우를 고려하지도 않은 것입니다. 예를 들어, Send(4), Send(32768), Send(4), Send(80)과 같은 식으로 4번 데이터 송신을 한 경우에, Recv(32768)을 완성하는 마지막 패킷에 4바이트가 따라붙는 경우는 무시한 코드입니다.

따라서, 현실적으로 저 코드를 만들려면 SimpleTcpClient를 상속해 Stream-oriented를 고려해 데이터를 수신하는 DataReceived 이벤트 핸들러를 완성하고, 다시 그렇게 해서 조합된 데이터를 외부에 이벤트로 알리는 PacketReceived와 같은 유형의 이벤트 핸들러를 제공해야 합니다. 게다가, 저 Recv를 서버 측에서 구현하려면 더더욱 복잡해지는데요, 서버는 IpPort로 클라이언트를 구분하기 때문에 DataReceived 코드에서 그에 대한 처리도 추가해야 합니다.

이런 것을 고려해 봤을 때, 과연 저 코드가 SuperSimpleTcp의 이름에 걸맞은지 충분히 고민을 해야 합니다.




이 외에도, Stream-oriented라는 성격에 걸맞지 않은 또 다른 문제점이 DataReceived에 대한 이벤트를 ThreadPool에 태워 발생시킨다는 점입니다. 아래는 수신 후 이벤트를 발생시키는 코드인데,

// https://github.com/jchristn/SuperSimpleTcp/blob/master/src/SuperSimpleTcp/SimpleTcpClient.cs#L903

// ....[생략]...

if (data != null)
{
    _lastActivity = DateTime.Now;

    Action action = () => _events.HandleDataReceived(this, new DataReceivedEventArgs(ServerIpPort, data));
    if (_settings.UseAsyncDataReceivedEvents)
    {
        _ = Task.Run(action, token);
    }
    else
    {
        action.Invoke();
    }

    _statistics.ReceivedBytes += data.Count;

    return data;
}

// ....[생략]...

저렇게 UseAsyncDataReceivedEvents 옵션(기본값: true)에 따라 스레드 풀을 사용하고 있으므로, 결국 차례대로 Recv가 호출되었다고 해도 스레드 풀의 상황에 따라 순서가 지켜지지 않는 문제가 발생합니다. 달리 말해, (순서가 지켜진다는 특징을 가진) TCP의 데이터 수신이 순서에 맞지 않을 수 있다는 것이고, 심지어 그것이 기본 동작이라는 점입니다. (github 이슈에도 이 문제로 질문이 있습니다.)

물론, 이 문제는 단순히 옵션을 false로 하면 해결되므로 이전에 다뤘던 재조합의 문제보다는 가볍습니다.




마지막으로, 원래 Socket의 경우 서버로 동작했을 때 Close를 하면 기존에 Accept 시킨 Socket에 대해서는 아무런 영향을 미치지 않습니다.

C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
; https://www.sysnet.pe.kr/2/0/13550

하지만, SuperSimpleTcp의 경우 (Stop이 아닌) Dispose 메서드를 호출하면 내부적으로 관리하고 있던 모든 자식 Socket을 닫는 코드를 수행한다는 차이점이 있습니다. 이 경우는 부작용이라기보다는 때로는 이렇게 동작하는 것을 원할 수 있기 때문에 장점으로 보입니다. ^^




전체적으로, 제 평가는, SuperSimpleTcp는 웬만하면 쓰지 말라는 권고를 드리고 싶습니다. Toy 프로젝트 정도의 단순한 통신이라면 모를까, 현업에서 사용할 만한 라이브러리는 아니라고 봅니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/18/2024]

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

비밀번호

댓글 작성자
 




... 151  152  153  154  155  156  [157]  158  159  160  161  162  163  164  165  ...
NoWriterDateCnt.TitleFile(s)
1124정성태9/17/201126415.NET Framework: 240. System.Collections.ArrayList가 .NET 4.5에서 지원이 안된다??? [2]
1123정성태9/17/201165259Windows: 53. 2가지 모드의 Internet Explorer 10과 ActiveX [6]
1122정성태9/16/201132929Windows: 52. 새롭게 지원되는 WinRT 응용 프로그램 [7]
1121정성태9/12/201127724Java: 5. WTP 내에서 서블릿을 실행하는 환경
1120정성태9/11/201127647.NET Framework: 239. IHttpHandler.IsReusable 속성 이야기파일 다운로드1
1119정성태9/11/201126731Java: 4. 이클립스에 WTP SDK가 설치되지 않는다면? [2]
1118정성태9/11/201138389Java: 3. 이클립스에서 서블릿 디버깅하는 방법 [4]
1117정성태9/9/201125639제니퍼 .NET: 17. 제니퍼 닷넷 적용 사례 (2) - 웹 애플리케이션 hang의 원인을 알려주다.
1116정성태9/8/201156685Java: 2. 자바에서 "Microsoft SQL Server JDBC Driver" 사용하는 방법
1115정성태9/4/201130259Java: 1. 닷넷 개발자가 처음 실습해 본 서블릿
1114정성태9/4/201134736Math: 2. "Zhang Suen 알고리즘(세선화, Thinning/Skeletonization)"의 C# 버전 [4]파일 다운로드1
1113정성태9/2/201134324개발 환경 구성: 129. Hyper-V에 CentOS 설치하기
1112정성태9/2/201151092Linux: 1. 리눅스 <-> 윈도우 원격 접속 프로그램 사용 [3]
1111정성태8/29/201125445제니퍼 .NET: 16. 적용 사례 (1) - DB Connection Pooling을 사용하지 않았을 때의 성능 저하를 알려주다. [1]
1110정성태8/26/201126828오류 유형: 136. RDP 접속이 불연속적으로 끊기는 문제
1109정성태8/26/201129719오류 유형: 135. 어느 순간 Active Directory 접속이 안되는 문제
1108정성태8/22/201131174오류 유형: 134. OLE/COM Object Viewer - DllRegisterServer in IVIEWERS.DLL failed. [1]
1107정성태8/21/201129003디버깅 기술: 43. Windows Form의 Load 이벤트에서 발생하는 예외가 Visual Studio에서 잡히지 않는 문제
1106정성태8/20/201127299웹: 26. FailedRequestTracing 설정으로 인한 iisexpress.exe 비정상 종료 문제
1105정성태8/19/201127241.NET Framework: 238. Web Site Model 프로젝트에서 Trace.WriteLine 출력이 dbgview.exe에서 확인이 안 되는 문제파일 다운로드1
1104정성태8/19/201127445웹: 25. WebDev보다 IIS Express가 더 나은 점 - 다중 가상 디렉터리 매핑 [1]
1103정성태8/19/201133348오류 유형: 133. WCF 포트 바인딩 실패 오류 - TCP error(10013) [1]
1102정성태8/19/201131045Math: 1. 방탈출3 - Room 10의 '중복가능한 조합' 문제를 위한 C# 프로그래밍 [2]파일 다운로드1
1101정성태8/19/201129694.NET Framework: 237. WCF AJAX 서비스와 JavaScript 간의 DateTime 연동 [1]파일 다운로드1
1100정성태8/17/201128810.NET Framework: 236. SqlDbType - DateTime, DateTime2, DateTimeOffset의 차이점파일 다운로드1
1099정성태8/15/201128253오류 유형: 132. 어느 순간 갑자기 접속이 안 되는 TFS 서버
... 151  152  153  154  155  156  [157]  158  159  160  161  162  163  164  165  ...