Microsoft MVP성태의 닷넷 이야기
닷넷: 2205. C# - SuperSimpleTcp 사용 시 주의할 점 [링크 복사], [링크+제목 복사],
조회: 2936
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  [53]  54  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12330정성태9/18/202010969.NET Framework: 939. C# - 전위/후위 증감 연산자에 대한 오버로딩 구현 [2]파일 다운로드1
12329정성태9/16/202012888오류 유형: 650. ASUS 메인보드 관련 소프트웨어 설치 후 ArmouryCrate.UserSessionHelper.exe 프로세스 무한 종료 현상
12328정성태9/16/202013133VS.NET IDE: 150. TFS의 이력에서 "Get This Version"과 같은 기능을 Git으로 처리한다면?
12327정성태9/12/202010672.NET Framework: 938. C# - ICS(Internet Connection Sharing) 제어파일 다운로드1
12326정성태9/12/202010139개발 환경 구성: 516. Azure VM의 Network Adapter를 실수로 비활성화한 경우
12325정성태9/12/20209711개발 환경 구성: 515. OpenVPN - 재부팅 후 ICS(Internet Connection Sharing) 기능이 동작 안하는 문제
12324정성태9/11/202010945개발 환경 구성: 514. smigdeploy.exe를 이용한 Windows Server 2016에서 2019로 마이그레이션 방법
12323정성태9/11/20209873오류 유형: 649. Copy Database Wizard - The job failed. Check the event log on the destination server for details.
12322정성태9/11/202011443개발 환경 구성: 513. Azure VM의 RDP 접속 위치 제한 [1]
12321정성태9/11/20209185오류 유형: 648. netsh http add urlacl - Error: 183 Cannot create a file when that file already exists.
12320정성태9/11/202010459개발 환경 구성: 512. RDP(원격 데스크톱) 접속 시 비밀 번호를 한 번 더 입력해야 하는 경우
12319정성태9/10/202010257오류 유형: 647. smigdeploy.exe를 Windows Server 2016에서 실행할 때 .NET Framework 미설치 오류 발생
12318정성태9/9/20209628오류 유형: 646. OpenVPN - "TAP-Windows Adapter V9" 어댑터의 "Network cable unplugged" 현상
12317정성태9/9/202011963개발 환경 구성: 511. Beats용 Kibana 기본 대시 보드 구성 방법
12316정성태9/8/202010359디버깅 기술: 170. WinDbg Preview 버전부터 닷넷 코어 3.0 이후의 메모리 덤프에 대해 sos.dll 자동 로드
12315정성태9/7/202012663개발 환경 구성: 510. Logstash - FileBeat을 이용한 IIS 로그 처리 [2]
12314정성태9/7/202011353오류 유형: 645. IIS HTTPERR - Timer_MinBytesPerSecond, Timer_ConnectionIdle 로그
12313정성태9/6/202012410개발 환경 구성: 509. Logstash - 사용자 정의 grok 패턴 추가를 이용한 IIS 로그 처리
12312정성태9/5/202016278개발 환경 구성: 508. Logstash 기본 사용법 [2]
12311정성태9/4/202011537.NET Framework: 937. C# - 간단하게 만들어 보는 리눅스의 nc(netcat), json_pp 프로그램 [1]
12310정성태9/3/202010817오류 유형: 644. Windows could not start the Elasticsearch 7.9.0 (elasticsearch-service-x64) service on Local Computer.
12309정성태9/3/202010615개발 환경 구성: 507. Elasticsearch 6.6부터 기본 추가된 한글 형태소 분석기 노리(nori) 사용법
12308정성태9/2/202011845개발 환경 구성: 506. Windows - 단일 머신에서 단일 바이너리로 여러 개의 ElasticSearch 노드를 실행하는 방법
12307정성태9/2/202012558오류 유형: 643. curl - json_parse_exception / Invalid UTF-8 start byte
12306정성태9/1/202010802오류 유형: 642. SQL Server 시작 오류 - error code 10013
12305정성태9/1/202011694Windows: 172. "Administered port exclusions"이 아닌 포트 범위 항목을 삭제하는 방법
... 46  47  48  49  50  51  52  [53]  54  55  56  57  58  59  60  ...