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

비밀번호

댓글 작성자
 




... 136  137  138  139  140  141  142  143  [144]  145  146  147  148  149  150  ...
NoWriterDateCnt.TitleFile(s)
1454정성태5/31/201326285Java: 15. Java 7 Control Panel 실행시키는 방법
1453정성태5/22/201325329기타: 32. Microsoft FTP 사이트에 접속하는 방법
1452정성태5/21/201333038Windows: 73. TabProcGrowth 값 삭제 후 IE를 실행시키면 다시 복원되는 경우 [3]
1451정성태5/17/201331960Windows: 72. 윈도우 서버 2012 기초 사용법
1450정성태5/16/201322733오류 유형: 176. SQL10007N Message "0" could not be retrieved. Reason code: "3"
1449정성태5/15/201329842오류 유형: 175. SpeechRecognitionEngine 사용 시 오류 유형 2가지
1448정성태5/14/201324835VC++: 68. #pragma warning(disable: ...)로 오류 제어가 안된다면?
1447정성태5/3/201326519개발 환경 구성: 191. Debugging Tools for Windows 독립 설치 버전 [1]
1446정성태4/30/201327318.NET Framework: 368. Encoding 타입의 대체(fallback) 메카니즘 [1]
1445정성태4/26/201325538디버깅 기술: 54. NT 서비스의 Main 메서드 안에서 Process.GetProcessesByName 호출 시 멈춤 현상 [1]
1444정성태4/26/201329548기타: 31. Internet Explorer: 자바스크립트로 숨겨진 파일 다운로드 경로를 알아내는 방법 [1]
1443정성태4/24/201325226개발 환경 구성: 190. Azure PaaS 웹 응용 프로그램 배포 후 SMTP 서버 구성 [2]
1442정성태4/21/201328795기타: 30. 마이크로소프트 워드의 CPU 점유 현상으로 글자 입력이 느려졌다면? [1]
1441정성태4/21/201335401.NET Framework: 367. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 [14]
1440정성태4/19/201324131오류 유형: 174. dumpbin.exe 실행시 mspdb110.dll 로드 오류
1439정성태4/18/201327984VS.NET IDE: 76. Visual Studio 2012와 Itanium 빌드 옵션 [2]
1438정성태4/17/201327398.NET Framework: 366. 다른 프로세스에 환경 변수 설정하는 방법 - 두 번째 이야기 [1]파일 다운로드1
1437정성태4/17/201327622VC++: 67. CRT(C Runtime DLL: msvcr...dll)에 대한 의존성 제거
1436정성태4/17/201333005.NET Framework: 365. Local SYSTEM 권한으로 코드를 실행하는 방법파일 다운로드1
1435정성태4/15/201341889Windows: 71. ad-hoc 보다 더 편리한 "가상 Wifi" 를 이용한 인터넷 공유 [2]
1434정성태4/9/201323179오류 유형: 173. TFS 서버의 이벤트 로그 오류 - WebHost failed to process a request. Parameter name: certificate
1433정성태4/9/201323475개발 환경 구성: 189. TFS에 설치된 SharePoint 의 PowerShell 콘솔 띄우는 방법
1432정성태4/5/201324486오류 유형: 172. System.Web.PipelineModuleStepContainer.GetEventCount 에서 NullReferenceException 이 발생한다면?
1431정성태4/5/201325124기타: 29. 부팅 가능한 (외장) HDD를 기존 부팅 메뉴에 추가하는 방법
1430정성태4/4/201326992제니퍼 .NET: 23. 모바일용 웹 사이트에서 발생하는 응답 시간 지연 현상 [5]파일 다운로드1
1429정성태3/29/201323357개발 환경 구성: 188. SCOM 2012 - ASP.NET 모니터링 방법
... 136  137  138  139  140  141  142  143  [144]  145  146  147  148  149  150  ...