석수코딩교육

FTP로 파일을 전송 시 아스키(ASCII) 모드와 바이너리(Binary) 모드 두 가지가 있습니다. 
아스키 모드로 전송하는 경우 수신 컴퓨터에서 파일을 읽지 못하는 문제가 발생할 수 있습니다. 
ftp로 전송했는데 파일에 문제가 있다면 혹시 아스키 모드로 보냈는지 확인해보세요.

FTP 전송 모드
바이너리 모드로 보내야 하는 경우
바이너리 모드는 파일을 0과 1로 구성된 원시 데이터로 전송하는 모드입니다. 
가공되지 않은 원본 데이터이기 때문에 발송자가 보내는 파일과 수신자가 받는 파일이 정확히 같습니다.

반드시 바이너리 모드로 전송해야만 하는 파일들이 존재합니다. 
이미지 파일(.jpg, bmp, png), 사운드 파일(.mp3, .avi, .wma), 비디오 파일(.flv, .mkv, .mov, .mp4), 아카이브 파일(.zip, .rar, .tar), 그 외 실행 및 문서 파일(.exe, .doc, .xls, .pdf) 등이 그렇습니다. 사실 이렇게 나열할 필요도 없고 텍스트 형식이 아니면 그냥 바이너리로 보내야 한다고 보시면 됩니다.

아스키 모드 사용 이유
아스키 모드는 파일을 텍스트로 전송할 때 사용되는 모드입니다. 
ASCII는 American Standard Code for Information Interchange의 약자입니다. 정보 교환을 위해 만든 미국의 표준 코드입니다. .txt, html, .php, .cgi, .js, .txt, .css 등 확장자를 보낼 때 아스키 모드가 권고되기도 합니다.
당연하게도 텍스트 파일 역시 바이너리로 전송해도 됩니다. 
다만 아스키 모드로 전송 시 CR(Carriage Return)이 제거된다는 장점(?)이 있습니다. 
이게 무슨 말이냐 하면, 운영체제 간 행바꿈을 표현하는 기호의 차이를 보정해준다는 것입니다.

굳이 아스키 모드 안 써도 되는 이유
그럼에도 아스키 모드는 현재로서 영향력을 잃어가는 추세입니다. 
왜냐하면 바이너리 모드로도 별 문제가 없기 때문입니다. 
위에서 언급한 형식의 문제는 이미 상용 프로그램들이 스스로 보정을 해주기 때문입니다.
게다가 아스키 모드는 한국어, 일본어, 중국어 등의 문자를 처리하지 못합니다. 
텍스트 파일이라 할지라도 한글로 쓴 문서는 어차피 바이너리로 보내야 합니다.
이런 흐름을 반영하듯 sftp에선 모든 데이터는 바이너리 모드로 전송됩니다. 아스키 모드는 없습니다. 

비고)
윈도우는 띄어쓰기를 하면 캐리지 리턴(CR)과 라인피드(LF)가 모두 표기됩니다. 
두 용어는 과거 타자기에서 유래된 용어인데, 그게 중요한 건 아니고 결과적으로 아래의 예시 같은 차이가 발생한다는 것만 이해하시면 됩니다.
윈도우의 경우 줄을 바꾸면 \r\n
이렇게 \r\n 둘이 표시됩니다.
리눅스, 맥, FreeBSD, AIX 등 유닉스 시스템의 경우 줄을 바꾸면 \n
이렇게 \n만 표시됩니다.
그러니 윈도우에서 작성한 텍스트 파일을 리눅스에 보낼 때 아스키 모드는 CR(\n)을 제거해 차이를 보정해주기 때문에 이점이 있습니다.

클로바 AI에게 물어본결과)
FTP(File Transfer Protocol)는 파일 전송을 위한 프로토콜로, ASCII와 Binary 모드를 구분하여 사용합니다.
ASCII 모드: 텍스트 파일 전송에 사용되며, 각 문자를 7비트의 ASCII 코드로 변환하여 전송합니다. 전송 과정에서 데이터의 손실이나 변형이 일어날 가능성이 적습니다.
Binary 모드: 이미지, 동영상, 압축 파일 등의 바이너리 파일 전송에 사용되며, 파일의 원래 형태를 그대로 유지하여 전송합니다.
모드의 선택은 전송할 파일의 종류와 특성에 따라 달라집니다. 이를 고려하여 적절한 모드를 선택해야 합니다.

TCP의 흐름 제어/Ack/Console/Multi File Send/Recv/Thread/Windows/
TCP의 흐름 제어/Ack/Console/Multi File Send/Recv/Thread/Windows/
TCP의 흐름 제어/Ack/Console/Multi File Send/Recv/Thread/Windows/

SEND(Console)

RECV(Console)

TCP(Transmission Control Protocol)은 원활한 통신을 위해 전송하는 데이터 흐름을 제어하고 네트워크의 혼잡 상태를 파악해서 대처하는 기능을 프로토콜 자체에 포함하고 있다.
만약 TCP가 이런 기능들을 제공해주지 않는다면 개발자가 일일히 데이터를 어떤 단위로 보낼 것인지 정의해야하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에 TCP가 제공해주는 이러한 기능들 덕분에 우리는 온전히 상위 레이어의 동작에만 집중할 수 있는 것이다.
보통 TCP의 전송 제어 방법은 전송되는 데이터의 양을 조절하는 흐름 제어, 통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방법인 오류 제어, 네트워크 혼잡에 대처하는 혼잡 제어로 나누어진다.
물론 TCP 같은 전송 계층의 프로토콜을 어플리케이션 레이어에서 활동하는 개발자가 건드릴 일은 많이 없다. 그러나 혹시라도 이 부분에서 뭔가 문제가 발생했을 경우, TCP가 어떤 식으로 작동하는지 모른다면 고치는 건 둘째치고 원인 파악조차 하지 못하는 슬픈 상황이 발생할 수 있으므로 여러모로 알아두는 것이 좋다고 생각한다. (더불어 야근도 따라올 것이다)
그런 의미에서 이번 포스팅에서는 TCP의 흐름 제어 기법들과 오류 제어 기법들에 대한 이야기를 한번 해보려고 한다.

TCP의 흐름 제어

송신 측과 수신 측이 서로 데이터를 주고 받을 때, 여러가지 요인에 따라 이 두 친구들의 처리 속도가 달라질 수 있다. 이때 데이터를 받는 수신 측의 처리 속도가 송신 측보다 빠른 경우는 사실 별 문제가 없다.
주는 족족 빠르게 처리해주니 딱히 문제될 것이 없는 것이다. 그러나 수신 측의 처리 속도보다 송신 측이 더 빠른 경우 문제가 생긴다.
송신 측과 수신 측은 모두 데이터를 저장할 수 있는 버퍼를 가지고 있다. 이때 수신 측이 자신의 버퍼 안에 있는 데이터를 처리하는 속도보다 송신 측이 데이터를 전송하는 속도가 더 빠르다면, 당연히 수신 측의 버퍼는 언젠가 꽉 차버릴 것이기 때문이다.
수신 측의 버퍼가 꽉 찬 상태에서 도착한 데이터는 더 이상 담아둘 공간이 없기 때문에 폐기 처분된다. 물론 이런 상황에서는 송신 측이 다시 데이터를 보내주기는 하겠지만, 데이터 전송이라는게 네트워크 환경에 따라 변수가 워낙 많은 작업이기 때문에 사실 이 작업을 줄일 수 있으면 줄이는 것이 가장 좋다.
그래서 송신 측은 수신 측의 데이터 처리 속도를 파악하고 자신이 얼마나 빠르게, 많은 데이터를 전송할 지 결정해야한다. 이것이 바로 TCP의 흐름 제어인 것이다.
수신 측은 자신이 처리할 수 있는 데이터의 양을 의미하는 윈도우 크기(Window Size)를 자신의 응답 헤더에 담아서 송신 측에게 전해주게 되고, 송신 측은 상대방에게 데이터를 보낼 때 이 윈도우 크기와 네트워크의 현재 상황을 참고해서 알맞은 양의 데이터를 보냄으로써 전체적인 데이터의 흐름을 제어하게 된다.

1. Stop and Wait
Stop and Wait 방식은 이름 그대로 상대방에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 모든 방식을 통칭하는 말이다. 이때 데이터를 받는 수신 측은 잘 받았어!와 못 받았어... 등의 대답을 해주게 되는데, 수신 측이 어떤 대답을 해주냐에 따라 사용할 수 있는 오류 제어 방법이 나눠지기도 한다.
Stop and Wait로 흐름 제어를 할 경우의 대원칙은 단순히 상대방이 응답을 하면 데이터를 보낸다이기 때문에 구현 자체도 간단하고 개발자가 어플리케이션의 작동 원리를 파악하기도 쉬운 편이다.
기본적인 ARQ(Automatic Repeat Request)를 구현한다고 생각해보면, 수신 측의 윈도우 크기를 1 byte로 설정하고 처리 가능 = 1, 처리 불가능 = 0과 같은 식으로 대충 구현해도 돌아가기는 하기 때문이다.
하지만 서로 처리 가능, 처리 불가능 정도의 의미만 주고받는 방식은 간단한만큼 비효율적이라고 할 수도 있다. 왜냐하면 송신 측은 자신이 직접 데이터를 보내봐야 이 데이터를 수신 측이 처리할 수 있는지 알 수 있기 때문이다. 쉽게 말해서 이런 기초적인 Stop and Wait 방식은 그냥 될 때까지 주구장창 보내는 방식이라고 봐도 무방하다.
그런 이유로 Stop and Wait 방식을 사용하여 흐름 제어를 할 경우에는, 이런 비효율성을 커버하기 위해 이런 단순한 구현이 아닌 여러가지 오류 제어 방식을 함께 도입해서 사용한다.

2. Sliding Window

방금 알아본 바와 같이 Stop and Wait를 사용하여 흐름 제어를 하게 되면 비효율적인 부분이 있기 때문에, 오늘날의 TCP는 특별한 경우가 아닌 이상 대부분 슬라이딩 윈도우(Sliding Window) 방식을 사용한다.
슬라이딩 윈도우는 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 데이터의 흐름을 제어하는 방식이다.
Stop and Wait과 여러 가지 차이점이 있겠지만, 
사실 가장 큰 차이점은 송신 측이 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점이다. 
이 정보를 알고 있기 때문에 굳이 수신 측이 처리 가능이라는 대답을 일일히 해주지 않아도 데이터를 보내기 전에 이게 처리될 지 어떨지 어느 정도 예측이 가능하다는 말이다.

패킷의 흐름과 오류를 제어하는 TCP | Evans Library (evan-moon.github.io)

TCP의 흐름 제어/Ack/Stop and Wait>File Send/Recv/Windows/Guage/Thread/
TCP의 흐름 제어/Ack/Stop and Wait>File Send/Recv/Windows/Guage/Thread/
TCP의 흐름 제어/Ack/Stop and Wait>File Send/Recv/Windows/Guage/Thread/

Send하는 파트에서 Thread 활용시에 다중 데이타를 송신/수신할수 있다.
Send하는 파트에서 Thread 활용시에 다중 데이타를 송신/수신할수 있다.
Send하는 파트에서 Thread 활용시에 다중 데이타를 송신/수신할수 있다.

TCP(Transmission Control Protocol)은 원활한 통신을 위해 전송하는 데이터 흐름을 제어하고 네트워크의 혼잡 상태를 파악해서 대처하는 기능을 프로토콜 자체에 포함하고 있다.
만약 TCP가 이런 기능들을 제공해주지 않는다면 개발자가 일일히 데이터를 어떤 단위로 보낼 것인지 정의해야하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에 TCP가 제공해주는 이러한 기능들 덕분에 우리는 온전히 상위 레이어의 동작에만 집중할 수 있는 것이다.
보통 TCP의 전송 제어 방법은 전송되는 데이터의 양을 조절하는 흐름 제어, 통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방법인 오류 제어, 네트워크 혼잡에 대처하는 혼잡 제어로 나누어진다.
물론 TCP 같은 전송 계층의 프로토콜을 어플리케이션 레이어에서 활동하는 개발자가 건드릴 일은 많이 없다. 그러나 혹시라도 이 부분에서 뭔가 문제가 발생했을 경우, TCP가 어떤 식으로 작동하는지 모른다면 고치는 건 둘째치고 원인 파악조차 하지 못하는 슬픈 상황이 발생할 수 있으므로 여러모로 알아두는 것이 좋다고 생각한다. (더불어 야근도 따라올 것이다)
그런 의미에서 이번 포스팅에서는 TCP의 흐름 제어 기법들과 오류 제어 기법들에 대한 이야기를 한번 해보려고 한다.

TCP의 흐름 제어

송신 측과 수신 측이 서로 데이터를 주고 받을 때, 여러가지 요인에 따라 이 두 친구들의 처리 속도가 달라질 수 있다. 이때 데이터를 받는 수신 측의 처리 속도가 송신 측보다 빠른 경우는 사실 별 문제가 없다.
주는 족족 빠르게 처리해주니 딱히 문제될 것이 없는 것이다. 그러나 수신 측의 처리 속도보다 송신 측이 더 빠른 경우 문제가 생긴다.
송신 측과 수신 측은 모두 데이터를 저장할 수 있는 버퍼를 가지고 있다. 이때 수신 측이 자신의 버퍼 안에 있는 데이터를 처리하는 속도보다 송신 측이 데이터를 전송하는 속도가 더 빠르다면, 당연히 수신 측의 버퍼는 언젠가 꽉 차버릴 것이기 때문이다.
수신 측의 버퍼가 꽉 찬 상태에서 도착한 데이터는 더 이상 담아둘 공간이 없기 때문에 폐기 처분된다. 물론 이런 상황에서는 송신 측이 다시 데이터를 보내주기는 하겠지만, 데이터 전송이라는게 네트워크 환경에 따라 변수가 워낙 많은 작업이기 때문에 사실 이 작업을 줄일 수 있으면 줄이는 것이 가장 좋다.
그래서 송신 측은 수신 측의 데이터 처리 속도를 파악하고 자신이 얼마나 빠르게, 많은 데이터를 전송할 지 결정해야한다. 이것이 바로 TCP의 흐름 제어인 것이다.
수신 측은 자신이 처리할 수 있는 데이터의 양을 의미하는 윈도우 크기(Window Size)를 자신의 응답 헤더에 담아서 송신 측에게 전해주게 되고, 송신 측은 상대방에게 데이터를 보낼 때 이 윈도우 크기와 네트워크의 현재 상황을 참고해서 알맞은 양의 데이터를 보냄으로써 전체적인 데이터의 흐름을 제어하게 된다.

1. Stop and Wait
Stop and Wait 방식은 이름 그대로 상대방에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 모든 방식을 통칭하는 말이다. 이때 데이터를 받는 수신 측은 잘 받았어!와 못 받았어... 등의 대답을 해주게 되는데, 수신 측이 어떤 대답을 해주냐에 따라 사용할 수 있는 오류 제어 방법이 나눠지기도 한다.
Stop and Wait로 흐름 제어를 할 경우의 대원칙은 단순히 상대방이 응답을 하면 데이터를 보낸다이기 때문에 구현 자체도 간단하고 개발자가 어플리케이션의 작동 원리를 파악하기도 쉬운 편이다.
기본적인 ARQ(Automatic Repeat Request)를 구현한다고 생각해보면, 수신 측의 윈도우 크기를 1 byte로 설정하고 처리 가능 = 1, 처리 불가능 = 0과 같은 식으로 대충 구현해도 돌아가기는 하기 때문이다.
하지만 서로 처리 가능, 처리 불가능 정도의 의미만 주고받는 방식은 간단한만큼 비효율적이라고 할 수도 있다. 왜냐하면 송신 측은 자신이 직접 데이터를 보내봐야 이 데이터를 수신 측이 처리할 수 있는지 알 수 있기 때문이다. 쉽게 말해서 이런 기초적인 Stop and Wait 방식은 그냥 될 때까지 주구장창 보내는 방식이라고 봐도 무방하다.
그런 이유로 Stop and Wait 방식을 사용하여 흐름 제어를 할 경우에는, 이런 비효율성을 커버하기 위해 이런 단순한 구현이 아닌 여러가지 오류 제어 방식을 함께 도입해서 사용한다.

>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)

while (true)
{
    while(true)
    {
        bytesSent = sender.Send(fileByte);
        bytesSent = sender.Receive(recvByte);

        string flagTxt = Encoding.UTF8.GetString(recvByte, 0, bytesSent);

        if (flagTxt == "no") continue;
        else if (flagTxt == "go") break;
    }
}

>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)

while (true)
{
    int sz = handler.Receive(bytes);

    if (sz == -1) break;
    else if (sz != PACKSZ) //제대로 받지를 못했다고 판단했을때에
    {
if (sz + cur < filesz) //실제로 마지막데이타도 아니라면
{
    handler.Send("no");
    continue;
}
    }

    cur += sz;

    handler.Send("go");

    if (cur > filesz) break;
    else if (filesz == cur) break;
}

TCP의 흐름 제어/Stop and Wait>File Recv/Windows/Guage/
TCP의 흐름 제어/Stop and Wait>File Recv/Windows/Guage/

TCP의 흐름 제어/ Stop and Wait>File Send/Windows/
TCP의 흐름 제어/ Stop and Wait>File Send/Windows/

TCP의 흐름 제어/No-Ack/Sliding Window/File Send/Recv/Windows/Guage/Thread/
TCP의 흐름 제어/No-Ack/Sliding Window/File Send/Recv/Windows/Guage/Thread/
TCP의 흐름 제어/No-Ack/Sliding Window/File Send/Recv/Windows/Guage/Thread/

1) Using Send Thread
Send하는 파트에서 Thread 활용시에 다중 데이타를 송신/수신할수 있다.
Send하는 파트에서 Thread 활용시에 다중 데이타를 송신/수신할수 있다.
2) Using Send Basic class
Send하는 파트에서 Thread 활용을 안해도 다중 데이타를 송신/수신할수 있다.
Send하는 파트에서 Thread 활용을 안해도 다중 데이타를 송신/수신할수 있다.

TCP의 흐름 제어/Sliding Window

2. Sliding Window
방금 알아본 바와 같이 Stop and Wait를 사용하여 흐름 제어를 하게 되면 비효율적인 부분이 있기 때문에, 오늘날의 TCP는 특별한 경우가 아닌 이상 대부분 슬라이딩 윈도우(Sliding Window) 방식을 사용한다.
슬라이딩 윈도우는 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 데이터의 흐름을 제어하는 방식이다.
Stop and Wait과 여러 가지 차이점이 있겠지만, 
사실 가장 큰 차이점은 송신 측이 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점이다. 
이 정보를 알고 있기 때문에 굳이 수신 측이 처리 가능이라는 대답을 일일히 해주지 않아도 데이터를 보내기 전에 이게 처리될 지 어떨지 어느 정도 예측이 가능하다는 말이다.

File Send/Recv/Guage12/Multi Socket Thread/
File Send/Recv/Guage12/Multi Socket Thread/

File Sender
When Enter Key Pressed,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
1. file size sender
2. file name sender
3. file data sender

File Receiver
1. file size receive
2. file name receive( -> Rename: YYYYMMDDHHMISS_0000_filename)
3. file read receive(Guage display)

TCP의 흐름 제어/Sliding Window

2. Sliding Window
방금 알아본 바와 같이 Stop and Wait를 사용하여 흐름 제어를 하게 되면 비효율적인 부분이 있기 때문에, 오늘날의 TCP는 특별한 경우가 아닌 이상 대부분 슬라이딩 윈도우(Sliding Window) 방식을 사용한다.
슬라이딩 윈도우는 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 데이터의 흐름을 제어하는 방식이다.
Stop and Wait과 여러 가지 차이점이 있겠지만, 
사실 가장 큰 차이점은 송신 측이 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점이다. 
이 정보를 알고 있기 때문에 굳이 수신 측이 처리 가능이라는 대답을 일일히 해주지 않아도 데이터를 보내기 전에 이게 처리될 지 어떨지 어느 정도 예측이 가능하다는 말이다.

File Recv/Send-Thread/ProgressBar(feat. Thread)

TCP의 흐름 제어/Sliding Window

2. Sliding Window
방금 알아본 바와 같이 Stop and Wait를 사용하여 흐름 제어를 하게 되면 비효율적인 부분이 있기 때문에, 오늘날의 TCP는 특별한 경우가 아닌 이상 대부분 슬라이딩 윈도우(Sliding Window) 방식을 사용한다.
슬라이딩 윈도우는 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 데이터의 흐름을 제어하는 방식이다.
Stop and Wait과 여러 가지 차이점이 있겠지만, 
사실 가장 큰 차이점은 송신 측이 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점이다. 
이 정보를 알고 있기 때문에 굳이 수신 측이 처리 가능이라는 대답을 일일히 해주지 않아도 데이터를 보내기 전에 이게 처리될 지 어떨지 어느 정도 예측이 가능하다는 말이다.

File Send/Recv - Window form/Thread/Recv/

1. 파일사이즈 전송

2. 파일이름 전송

3. 파일데이타 전송

4. 수신받는 서버는 파일이름을 YYYYMMDDHHMISS_FILENAME으로 저장

file recv/send/delemeter(0x0d,0x0e,0xff)/멀티수신/windows src

1. 다중 클라이언트 파일 송신

2. 멀티수신서버

3. 수신방법은 delemeter(0x0d,0x0e,0xff) 사용

4. 파일명은 YYYYMMDDHHMISS_FILENAME으로 설정

TCP(Transmission Control Protocol)은 원활한 통신을 위해 전송하는 데이터 흐름을 제어하고 네트워크의 혼잡 상태를 파악해서 대처하는 기능을 프로토콜 자체에 포함하고 있다.
만약 TCP가 이런 기능들을 제공해주지 않는다면 개발자가 일일히 데이터를 어떤 단위로 보낼 것인지 정의해야하고, 패킷이 유실되면 어떤 예외처리를 해야하는 지까지 신경써야하기 때문에 TCP가 제공해주는 이러한 기능들 덕분에 우리는 온전히 상위 레이어의 동작에만 집중할 수 있는 것이다.
보통 TCP의 전송 제어 방법은 전송되는 데이터의 양을 조절하는 흐름 제어, 통신 도중에 데이터가 유실되거나 잘못된 데이터가 수신되었을 경우 대처하는 방법인 오류 제어, 네트워크 혼잡에 대처하는 혼잡 제어로 나누어진다.
물론 TCP 같은 전송 계층의 프로토콜을 어플리케이션 레이어에서 활동하는 개발자가 건드릴 일은 많이 없다. 그러나 혹시라도 이 부분에서 뭔가 문제가 발생했을 경우, TCP가 어떤 식으로 작동하는지 모른다면 고치는 건 둘째치고 원인 파악조차 하지 못하는 슬픈 상황이 발생할 수 있으므로 여러모로 알아두는 것이 좋다고 생각한다. (더불어 야근도 따라올 것이다)
그런 의미에서 이번 포스팅에서는 TCP의 흐름 제어 기법들과 오류 제어 기법들에 대한 이야기를 한번 해보려고 한다.

TCP의 흐름 제어

송신 측과 수신 측이 서로 데이터를 주고 받을 때, 여러가지 요인에 따라 이 두 친구들의 처리 속도가 달라질 수 있다. 이때 데이터를 받는 수신 측의 처리 속도가 송신 측보다 빠른 경우는 사실 별 문제가 없다.
주는 족족 빠르게 처리해주니 딱히 문제될 것이 없는 것이다. 그러나 수신 측의 처리 속도보다 송신 측이 더 빠른 경우 문제가 생긴다.
송신 측과 수신 측은 모두 데이터를 저장할 수 있는 버퍼를 가지고 있다. 이때 수신 측이 자신의 버퍼 안에 있는 데이터를 처리하는 속도보다 송신 측이 데이터를 전송하는 속도가 더 빠르다면, 당연히 수신 측의 버퍼는 언젠가 꽉 차버릴 것이기 때문이다.
수신 측의 버퍼가 꽉 찬 상태에서 도착한 데이터는 더 이상 담아둘 공간이 없기 때문에 폐기 처분된다. 물론 이런 상황에서는 송신 측이 다시 데이터를 보내주기는 하겠지만, 데이터 전송이라는게 네트워크 환경에 따라 변수가 워낙 많은 작업이기 때문에 사실 이 작업을 줄일 수 있으면 줄이는 것이 가장 좋다.
그래서 송신 측은 수신 측의 데이터 처리 속도를 파악하고 자신이 얼마나 빠르게, 많은 데이터를 전송할 지 결정해야한다. 이것이 바로 TCP의 흐름 제어인 것이다.
수신 측은 자신이 처리할 수 있는 데이터의 양을 의미하는 윈도우 크기(Window Size)를 자신의 응답 헤더에 담아서 송신 측에게 전해주게 되고, 송신 측은 상대방에게 데이터를 보낼 때 이 윈도우 크기와 네트워크의 현재 상황을 참고해서 알맞은 양의 데이터를 보냄으로써 전체적인 데이터의 흐름을 제어하게 된다.

1. Stop and Wait
Stop and Wait 방식은 이름 그대로 상대방에게 데이터를 보낸 후 잘 받았다는 응답이 올 때까지 기다리는 모든 방식을 통칭하는 말이다. 이때 데이터를 받는 수신 측은 잘 받았어!와 못 받았어... 등의 대답을 해주게 되는데, 수신 측이 어떤 대답을 해주냐에 따라 사용할 수 있는 오류 제어 방법이 나눠지기도 한다.
Stop and Wait로 흐름 제어를 할 경우의 대원칙은 단순히 상대방이 응답을 하면 데이터를 보낸다이기 때문에 구현 자체도 간단하고 개발자가 어플리케이션의 작동 원리를 파악하기도 쉬운 편이다.
기본적인 ARQ(Automatic Repeat Request)를 구현한다고 생각해보면, 수신 측의 윈도우 크기를 1 byte로 설정하고 처리 가능 = 1, 처리 불가능 = 0과 같은 식으로 대충 구현해도 돌아가기는 하기 때문이다.
하지만 서로 처리 가능, 처리 불가능 정도의 의미만 주고받는 방식은 간단한만큼 비효율적이라고 할 수도 있다. 왜냐하면 송신 측은 자신이 직접 데이터를 보내봐야 이 데이터를 수신 측이 처리할 수 있는지 알 수 있기 때문이다. 쉽게 말해서 이런 기초적인 Stop and Wait 방식은 그냥 될 때까지 주구장창 보내는 방식이라고 봐도 무방하다.
그런 이유로 Stop and Wait 방식을 사용하여 흐름 제어를 할 경우에는, 이런 비효율성을 커버하기 위해 이런 단순한 구현이 아닌 여러가지 오류 제어 방식을 함께 도입해서 사용한다.

>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)
>>>>보내는쪽에서의 개략소스)

while (true)
{
    while(true)
    {
        bytesSent = sender.Send(fileByte);
        bytesSent = sender.Receive(recvByte);

        string flagTxt = Encoding.UTF8.GetString(recvByte, 0, bytesSent);

        if (flagTxt == "no") continue;
        else if (flagTxt == "go") break;
    }
}

>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)
>>>>받는쪽에서 개략소스)

while (true)
{
    int sz = handler.Receive(bytes);

    if (sz == -1) break;
    else if (sz != PACKSZ) //제대로 받지를 못했다고 판단했을때에
    {
if (sz + cur < filesz) //실제로 마지막데이타도 아니라면
{
    handler.Send("no");
    continue;
}
    }

    cur += sz;

    handler.Send("go");

    if (cur > filesz) break;
    else if (filesz == cur) break;
}


TCP의 흐름 제어/Sliding Window

2. Sliding Window

방금 알아본 바와 같이 Stop and Wait를 사용하여 흐름 제어를 하게 되면 비효율적인 부분이 있기 때문에, 오늘날의 TCP는 특별한 경우가 아닌 이상 대부분 슬라이딩 윈도우(Sliding Window) 방식을 사용한다.
슬라이딩 윈도우는 수신 측이 한 번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신 측에 알려줘서 데이터의 흐름을 제어하는 방식이다.
Stop and Wait과 여러 가지 차이점이 있겠지만, 
사실 가장 큰 차이점은 송신 측이 수신 측이 처리할 수 있는 데이터의 양을 알고 있다는 점이다. 
이 정보를 알고 있기 때문에 굳이 수신 측이 처리 가능이라는 대답을 일일히 해주지 않아도 데이터를 보내기 전에 이게 처리될 지 어떨지 어느 정도 예측이 가능하다는 말이다.

변형적인 file recv/send(windows)

1. 파일이름을 보낸다.(서버에서 파일중복검사를 하지 않고, YYYYMMDDHHMISS_FILENAME으로 처리)

2. 파일내용을 읽어서 보낸다.

문의)xterm92@naver.com

일반적인 file send/recv(windows src)

1. 클라이언트에서 파일사이즈를 보내고

2. 클라이언트에서 파일이름을 보내고

3. 파일을 읽어서 전송

c# 으로 작성되어진 delemeter(0xff)로 구분되어진 데이타 수신서버

애플리케이션이 작동을 멈추면, 사용자에게 부정적인 경험을 주기 전에 미리 아는 것이 좋습니다. APM을 통해 팀은 문제를 신속하게 파악하고 해결할 수 있으며, 향후에도 문제를 방지할 수 있습니다. 포괄적인 APM 도구를 통해, 팀은 다음과 같은 이점을 얻을 수 있습니다.

• 안정성 및 가동 시간 향상
• 인시던트 감소
• 문제를 보다 신속하게 해결
• 고품질 소프트웨어 출시
• 인프라 개선 사항 파악
• 생산성 향상
• 더 나은 사용자 경험 만들기
• 매출 증대

APM 도구의 주요 기능

적절한 APM 도구를 선택할 때 어떤 점을 고려해야 하나요? 엔드 투 엔드 트랜잭션, 애플리케이션 및 코드 레벨 성능을 모니터링할 수 있는 다양한 APM 솔루션이 있지만, 현재와 미래의 기술적 필요에 맞는 솔루션을 선택하는 것이 중요합니다.

기술적 역량

조직에 대한 체크리스트를 작성합니다. 그런 다음, 필요에 따라 도구 기능을 비교할 수 있습니다. APM 기술적 역량의 예를 몇 가지 소개하면 다음과 같습니다.

• 웹사이트 및/또는 애플리케이션 성능 추적
• 애플리케이션 및 서비스 종속성 매핑 및 관리
• 엔드 투 엔드 가시성을 위해 분산 추적 수집
• 실시간 사용자 모니터링(클라이언트 및 서버) 제공
• 앱 성능을 비즈니스 목표에 연결
• 머신 러닝 및 AI 기반 분석 활용
• 다양한 데이터 유형, 데이터 소스 및 언어 지원

엔드 투 엔드 가시성

APM 데이터는 애플리케이션에서 실제로 어떤 일이 일어나고 있는지를 조직에 알릴 수 있는 기능을 가지고 있습니다. 그러나 모든 것을 잘 모니터링할 수 있어야 어떻게 작동하고 있는지에 대한 명확한 비전을 얻을 수 있습니다.

개별 추적은 이 스토리의 일부만 보여주기 때문에, APM 도구는 한 단계 더 나아가 트랜잭션을 전체 과정에서 모니터링해야 합니다. 그런 다음, 여러 추적을 함께 연결하여 개괄적인 전체 보기에서 코드 레벨 문제로 전환할 수 있습니다.

엔드 투 엔드 가시성도 AIOps의 중요한 요소입니다.

통합

서드파티 서비스 및 애플리케이션과의 통합을 통해 APM 도구는 조직의 보다 규모가 큰 에코시스템에 원활하게 꼭 들어맞을 수 있습니다. 인증에서 CI/CD 프레임워크에 이르기까지, 이러한 통합을 사전에 조사하는 것이 중요합니다.

사용 용이성

조직 내에는 APM 기능에 액세스해야 하는 다양한 사용자가 있습니다. 직관적인 UI를 통해 각 사용자의 필요에 맞추세요. 또한 APM 솔루션의 배포, 관리 및 확장이 얼마나 쉬운지 확인해 보세요.

배포 옵션

운영 및 관리 비용을 절감하려는 경우 ,클라우드 기반 SaaS 옵션을 고려해 볼 수 있습니다. 그러나 고려해야 할 다른 배포 옵션이 있습니다. 일부 APM 도구는 멀티 클라우드 또는 하이브리드 전략을 지원할 수 있지만, 다른 도구는 선호하는 클라우드 서비스 제공자에 따라 제한이 있을 수 있습니다.

개방형 표준/개방형 데이터 지원

Observability 공간은 끊임없이 진화하고 있습니다. 새로운 도구와 표준이 시장에 진입함에 따라, 적응할 수 있는 유연한 플랫폼이 필요합니다. 또한 OpenTelemetry와 같은 개방형 표준 및 기술을 사용하면 도구 집합의 미래를 보장하는 데 도움이 될 수 있습니다.

참조)
APM - 애플리케이션 성능 모니터링이란 무엇인가요? | 포괄적인 APM 안내서 | Elastic

클라이언트에서 555사이즈 packet을 400번 보내면 서버에서 받는모습은(?)

1. 클라이언트에서 555사이즈 packet을 400번 보내면 555 * 400 = 222,000이다.

2. 파일에서의 사이즈는 229,200이다.("\r\n" + 기타정보를 추가로 입력했기때문에 사이즈가 늘어났다.)
-rw-r--r-- 1 B210145_BK 197121    229200 Apr 22 08:32 packefile_2024_04_22_08_32_24.txt
-rw-r--r-- 1 B210145_BK 197121    229200 Apr 22 08:34 packefile_2024_04_22_08_34_02.txt
-rw-r--r-- 1 B210145_BK 197121    229200 Apr 22 08:35 packefile_2024_04_22_08_34_58.txt

3. 클라이언트에서 555를 보낸다고해서, 서버에서 555을 받지는 않는다.
장비 네크워크 사정, 서버의 처리속도, 등등을 따져서 서버에서 받는 수신 packet 의 사이즈는 틀려진다.

4. 마지막 서버에서 모든 수신된 packet의 길이를 더하면 클라이언트에서 보낸 사이즈와 같다.

유실이 없다.(tcp/ip)

5. 위의 화면을 보면, 클라이언트에서 보내는 모습과 서버에서 받는모습이 나타나있다.
자세히 보면, 어떻게 클라이언트와 서버가 데이타를 주고받는지 알수 있다.

궁금한점은 xterm92@naver.com으로,ㅡㅡ,ㅡㅡㅡㅡ

//11.txt
//{"param":{"loginid":"admin","pwd":"admin123"},"proto":"r","sender":"/cli/admin/10.1.181.79/25216","id":"login_client.0000919860.001","ts":"1713428639","method":"login_client"}

using System;
using System.IO;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel;

class Program
{
    public static void Main(string[] args)
    {
        if (args.Length == 1)
        {
            CHKNM nmm = new CHKNM();
            nmm.RUN(args[0]);
        }
        else
        {
            CHKNM nmm = new CHKNM();
            nmm.RUN();
        }
    }
}
class CHKNM
{
    public void RUN(string fileText)
    {
        string lines = File.ReadAllText(fileText);

        Console.WriteLine(lines);

        byte[] bytes = Encoding.UTF8.GetBytes(lines);
        PrintByteArray(bytes);
    }
    public void RUN()
    {
        byte[] buffer = new byte[] { 123, 34, 112, 97, 114, 97, 109, 34, 58, 123, 34, 108, 111, 103, 105, 110, 105, 100, 34, 58, 34, 97, 100, 109, 105, 110, 34, 44, 34, 112, 119, 100, 34, 58, 34, 97, 100, 109, 105, 110, 49, 50, 51, 34, 125, 44, 34, 112, 114, 111, 116, 111, 34, 58, 34, 114, 34, 44, 34, 115, 101, 110, 100, 101, 114, 34, 58, 34, 47, 99, 108, 105, 47, 97, 100, 109, 105, 110, 47, 49, 48, 46, 49, 46, 49, 56, 49, 46, 55, 57, 47, 50, 53, 50, 49, 54, 34, 44, 34, 105, 100, 34, 58, 34, 108, 111, 103, 105, 110, 95, 99, 108, 105, 101, 110, 116, 46, 48, 48, 48, 48, 57, 49, 57, 56, 54, 48, 46, 48, 48, 49, 34, 44, 34, 116, 115, 34, 58, 34, 49, 55, 49, 51, 52, 50, 56, 54, 51, 57, 34, 44, 34, 109, 101, 116, 104, 111, 100, 34, 58, 34, 108, 111, 103, 105, 110, 95, 99, 108, 105, 101, 110, 116, 34, 125, 13, 10, };
        string strText = Encoding.Default.GetString(buffer);

        Console.WriteLine(strText);
    }
    public void PrintByteArray(byte[] bytes)
    {
        var sb = new StringBuilder("new byte[] { ");
        foreach (var b in bytes)
        {
            sb.Append(b + ", ");
        }
        sb.Append("}");
        Console.WriteLine(sb.ToString());
    }
}

windows_send_basic.exe 127.0.0.1 21111 "E:\exture_plus_raw_internet_log_20230418\home\release\Paxfeed_x64\backup\TickerplantRaw_EXTURE_PLUS_INTERNET_REAL_STANDBY\20230418_13_internet_Kse_32114.log"

-rw-r--r-- 1 B210145_BK 197121       2944 Apr 18  2023 20230418_20_internet_Kse_32113.log
-rw-r--r-- 1 B210145_BK 197121       2944 Apr 18  2023 20230418_20_internet_Kse_32112.log
-rw-r--r-- 1 B210145_BK 197121       2944 Apr 18  2023 20230418_20_internet_Kosdaq_33112.log
-rw-r--r-- 1 B210145_BK 197121    3013444 Apr 18  2023 20230418_20_internet_Kse_32115.log
-rw-r--r-- 1 B210145_BK 197121       3264 Apr 18  2023 20230418_20_internet_FutureIndex_35115.log
-rw-r--r-- 1 B210145_BK 197121       3264 Apr 18  2023 20230418_20_internet_OptionIndex_36112.log
-rw-r--r-- 1 B210145_BK 197121       3264 Apr 18  2023 20230418_20_internet_OptionIndex_36111.log
-rw-r--r-- 1 B210145_BK 197121       2944 Apr 18  2023 20230418_20_internet_Kse_45111.log
-rw-r--r-- 1 B210145_BK 197121       3264 Apr 18  2023 20230418_20_internet_FutureIndex_35114.log
-rw-r--r-- 1 B210145_BK 197121       2944 Apr 18  2023 20230418_20_internet_Kse_32114.log
-rw-r--r-- 1 B210145_BK 197121       5520 Apr 18  2023 20230418_20_internet_Elw_34913.log
-rw-r--r-- 1 B210145_BK 197121       5460 Apr 18  2023 20230418_20_internet_Kse_40116.log
-rw-r--r-- 1 B210145_BK 197121       5460 Apr 18  2023 20230418_20_internet_Kse_40112.log
-rw-r--r-- 1 B210145_BK 197121       5460 Apr 18  2023 20230418_20_internet_Kse_40111.log
-rw-r--r-- 1 B210145_BK 197121       5520 Apr 18  2023 20230418_20_internet_Elw_34912.log
-rw-r--r-- 1 B210145_BK 197121       5612 Apr 18  2023 20230418_20_internet_Elw_34914.log

플랫버퍼에서 데이터를 읽고 쓰는 방법은 다음과 같습니다.

1.데이터 구조 정의: 먼저 플랫버퍼에서 사용할 데이터 구조를 정의해야 합니다. 이를 위해 플랫버퍼에서 제공하는 FlatBufferBuilder 클래스를 사용합니다. FlatBufferBuilder 클래스는 데이터 구조를 생성하고, 데이터를 추가하며, 최종적으로 직렬화된 데이터를 생성하는 데 사용됩니다.

2.데이터 추가: FlatBufferBuilder 클래스를 사용하여 데이터 구조에 데이터를 추가합니다. 데이터를 추가할 때는 FlatBufferBuilder 클래스의 메소드를 사용합니다. 예를 들어, int 타입의 데이터를 추가하려면 FlatBufferBuilder.addInt 메소드를 사용합니다.

3.데이터 직렬화: 데이터 추가가 완료되면, FlatBufferBuilder 클래스의 Finish 메소드를 사용하여 데이터를 직렬화합니다. Finish 메소드는 직렬화된 데이터를 반환합니다.

4.데이터 읽기: 직렬화된 데이터를 읽으려면, FlatBufferBuilder 클래스에서 제공하는 GetRootAs 메소드를 사용합니다. 이 메소드는 직렬화된 데이터에서 원하는 데이터 구조를 추출하는 데 사용됩니다. 추출된 데이터 구조는 해당 언어에서 제공하는 방식으로 사용할 수 있습니다.

5.데이터 수정: 추출된 데이터 구조를 수정하려면, 해당 언어에서 제공하는 방식으로 데이터를 수정합니다. 수정된 데이터를 다시 직렬화하려면, FlatBufferBuilder 클래스를 사용하여 데이터를 추가하고, Finish 메소드를 사용하여 데이터를 직렬화합니다.

다음은 C++에서 플랫버퍼를 사용하여 데이터를 읽고 쓰는 예제입니다.

#include "flatbuffers/flatbuffers.h"

struct Person {
    int id;
    std::string name;
    int age;
};

int main() {
    // 데이터 구조 정의
    FlatBufferBuilder builder;

    // 데이터 추가
    auto nameOffset = builder.CreateString("John");
    auto person = CreatePerson(builder, 1, nameOffset, 30);

    // 데이터 직렬화
    FinishPersonBuffer(builder, person);

    // 데이터 읽기
    auto buffer = builder.GetBufferPointer();
    auto person_ = GetPerson(buffer);

    // 데이터 출력
    std::cout << "ID: " << person_->id() << std::endl;
    std::cout << "Name: " << person_->name()->c_str() << std::endl;
    std::cout << "Age: " << person_->age() << std::endl;

    return 0;
}

SBE (Simple Binary Encoding)는 성능에 민감한 애플리케이션을 위한 경량의 고성능 바이너리 데이터 인코딩 및 직렬화 형식입니다. SBE는 금융 서비스, IoT, 산업 자동화, 네트워크 모니터링 등 다양한 산업 분야에서 사용됩니다.

다음은 SBE의 주요 특징입니다:

1.고성능: SBE는 경량의 바이너리 형식을 사용하여 데이터를 인코딩하고 직렬화하므로, 데이터 전송 및 처리 속도가 빠릅니다.

2.유연성: SBE는 사용자가 데이터 구조를 정의하고, 필드의 길이, 데이터 타입, 값의 범위 등을 지정할 수 있습니다. 이를 통해 사용자는 자신의 요구사항에 맞게 데이터를 인코딩할 수 있습니다.

3.다양한 언어 지원: SBE는 C++, Java, .NET, Python, JavaScript 등 다양한 언어를 지원합니다. 이를 통해 여러 언어로 작성된 애플리케이션 간에 데이터를 쉽게 교환할 수 있습니다.

4.안전성: SBE는 데이터 무결성을 보장하기 위해 체크섬을 사용합니다. 또한, 데이터가 손상되는 것을 방지하기 위해 오류 검사를 수행합니다.

5.확장성: SBE는 대규모 데이터 처리를 위한 확장성이 높습니다. 이를 통해 대량의 데이터를 빠르고 안정적으로 처리할 수 있습니다.

6.표준화: SBE는 금융 서비스 산업에서 널리 사용되는 FIX (Financial Information eXchange) 프로토콜을 기반으로 개발되었습니다. 이를 통해 SBE는 금융 서비스 분야에서 표준화된 데이터 인코딩 형식으로 자리 잡았습니다.

SBE는 금융 서비스 분야에서 널리 사용되고 있으며, 다른 산업 분야에서도 점차 도입되고 있습니다. SBE를 사용하면 데이터 전송 및 처리 속도를 향상시키고, 데이터 무결성을 보장하며, 다양한 언어로 작성된 애플리케이션 간에 데이터를 쉽게 교환할 수 있습니다.

플랫버퍼(FlatBuffers)는 C++, C#, C, Go, Java, Kotlin, JavaScript, Lobster, Lua, TypeScript, PHP, Python, Rust 및 Swift를 위한 효율적인 크로스 플랫폼 직렬화 라이브러리입니다. 원래 게임 개발 및 기타 성능에 민감한 애플리케이션을 위해 구글에서 만들었습니다.

플랫버퍼는 데이터를 효율적으로 저장하고 전송하기 위해 설계되었습니다. 이는 메모리 사용량과 직렬화 및 역직렬화 시간을 최소화함으로써 이루어집니다. 또한 다양한 언어를 지원하므로 여러 언어로 작성된 애플리케이션 간에 데이터를 쉽게 교환할 수 있습니다.

플랫버퍼는 다음과 같은 특징을 가지고 있습니다:

1.효율성: 플랫버퍼는 데이터를 압축하여 저장하므로 메모리 사용량을 최소화합니다. 또한 직렬화 및 역직렬화 시간이 매우 빠릅니다.

2.다양한 언어 지원: 플랫버퍼는 다양한 언어를 지원하므로 여러 언어로 작성된 애플리케이션 간에 데이터를 쉽게 교환할 수 있습니다.

3.유연성: 플랫버퍼는 사용자가 데이터 구조를 정의하고 직렬화할 수 있게 해줍니다. 또한 사용자가 직렬화된 데이터를 수정하고 역직렬화할 수 있습니다.

4.빠른 속도: 플랫버퍼는 데이터를 빠르게 읽고 쓸 수 있으므로 게임 개발이나 실시간 데이터 처리와 같은 성능에 민감한 애플리케이션에 적합합니다.

5.안전성: 플랫버퍼는 데이터 무결성을 보장하기 위해 체크섬을 사용합니다. 또한 데이터가 손상되는 것을 방지하기 위해 오류 검사를 수행합니다.

6.오픈 소스: 플랫버퍼는 오픈 소스 라이브러리이므로 누구나 자유롭게 사용하고 수정할 수 있습니다.

플랫버퍼는 게임 개발, 머신 러닝, 빅 데이터 처리 등 다양한 분야에서 사용됩니다. 또한 웹 개발에서도 사용되며, JSON과 같은 다른 직렬화 형식보다 더 효율적이고 빠릅니다.

json 데이타를 c# 구조체 모델링 코드화 해주는 사이트
json 데이타를 c# 구조체 모델링 코드화 해주는 사이트
json 데이타를 c# 구조체 모델링 코드화 해주는 사이트

https://json2csharp.com/