석수코딩교육

아래검색파일에서 Value="14"를 Value="10"으로 변경하고자, 구글링하려고 했으나, (CHAT.GPT)를 이용하니, 바로 리눅스명령어 알려줌
아래검색파일에서 Value="14"를 Value="10"으로 변경하고자, 구글링하려고 했으나, (CHAT.GPT)를 이용하니, 바로 리눅스명령어 알려줌

xterm@DESKTOP-VVAIF4D MINGW64 ~/Downloads/tmp/WindowsPresenFoundation/WINPAYCalcM
$ find ./ -name "*.xaml" | xargs grep FontSize | grep Value=
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="14"/>
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="14"/>
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="14"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="14"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="14"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="14"/>
./MainWindow.xaml:            <Setter Property="FontSize" Value="10"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="14"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="14"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="14"/>

xterm@DESKTOP-VVAIF4D MINGW64 ~/Downloads/tmp/WindowsPresenFoundation/WINPAYCalcM
$ sed -i 's/Value="10"/Value="11"/g' ./BasicInfoDialog.xaml ./FileListNM.xaml ./SpecificDialog.xaml

xterm@DESKTOP-VVAIF4D MINGW64 ~/Downloads/tmp/WindowsPresenFoundation/WINPAYCalcM
$ find ./ -name "*.xaml" | xargs grep FontSize | grep Value=
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="10"/>
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="10"/>
./BasicInfoDialog.xaml:            <Setter Property="FontSize" Value="10"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="10"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="10"/>
./FileListNM.xaml:        <Setter Property="FontSize" Value="10"/>
./MainWindow.xaml:            <Setter Property="FontSize" Value="10"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="10"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="10"/>
./SpecificDialog.xaml:        <Setter Property="FontSize" Value="10"/>

xterm@DESKTOP-VVAIF4D MINGW64 ~/Downloads/tmp/WindowsPresenFoundation/WINPAYCalcM
$

접속표준서(TCP) 공통정보(송신채널_정보구분)

접속표준서(TCP) 공통정보(송신채널_정보구분)
1.
- 그룹별로 3,4개의 포트로 구성됨.
- 수신사는(예를 들어 네이버, 팍스넷, 싱크풀등등) 데이타를 수신하는 서버프로그램을 작성해야 한다.


2.
- 보통 포트별로 한개의 서버가 1:1로 통신하는 방식을 취한다.
- 한번 맺은 세션은 끊어지지 않는다. 즉 하나의 포트를 담당하는 수신서버는 Accept를 한번 하는 꼴이다.
- 한번 맺은 세션은 끊어지지 않는다. Accept후에 데이타를 수신해서 데이타를 파싱하는 로직이 들어가면 된다.
- 한번 맺은 세션은 끊어지지 않는다. Accept후에 데이타를 수신하는 과정에서, 패킷은 헤더와 테일은 존재하지 않는다.
- 한번 맺은 세션은 끊어지지 않는다. Accept후에 데이타를 수신하는 과정에서, 데이타를 구분짓는 구분자 0xff만 존재
- 구체적으로 10,000바이트를 받았다면 여러개의 정보데이타를 끊어서 저장해야한다.
- 정보데이타의 길이정보를 이용해서 수신받는 데이타를 분리한다면, 제도변경시에 좋지 않는 방법이다.
- Ack가 없는 관계의 TCP 수신,송신방법이다.
- 송신하는쪽도 일방적으로 데이타를 보낸다. 수신하는쪽이 잘 받았는지 못받았는지는 신경쓰지 않는다.
(마치 UDP처럼)
- 수신하는쪽도 송신하는쪽에 Ack신호를 보내지 않는다. 무조건 데이타를 받기만한다.
- 만약에 수신쪽의 서버나 네트웍이 불안해서 송신데이타를 보내는쪽에서 프로그램이 죽는다면, ㅠㅠㅠㅠ(?)
- 만약에 수신쪽의 서버나 네트웍이 불안해서 송신데이타를 보내는쪽에서 프로그램이 죽는다면, ㅠㅠㅠㅠ(?)
- 만약에 수신쪽의 서버나 네트웍이 불안해서 송신데이타를 보내는쪽에서 프로그램이 죽는다면, ㅠㅠㅠㅠ(?)
(절대 그렇게 설계를 해서는 안되지만, 장애로 분리되겠다.)

- UDP는 송신쪽에서 보내기만 할뿐, 수신쪽과 상관없기떄문에, 송신쪽 프로그램이 죽는경우는 발생하지 않는다.
(즉 수신쪽의 프로그램의 정상여부를 알수가 없다. 하지만 TCP는 알수 있기떄문에 통보해줄수 있다.)


3.
- 구분해서 분리되어진 정보데이타패킷은 저장하는 방법으로 여러가지가 있을것이다.(메모리,디비,메모리디비,파일등등)
- netstat -an | grep Listen 으로 명령어를 실행하면 수신 포트갯수만큼 나올것이다.
- netstat -an | grep ESTABLISHED 으로 명령어를 실행하면 수신 포트갯수만큼 나올것이다.

1. 기존 Windows Form방식)
- 기존 Form방식에서 사용되어진 Form 화면디자인을 WPF방식에는 이용할수 없다는점이 아쉽다.
- Form과 WPF를 동시에 코딩을 원한다면, 화면과 로직을 분리하는 설계를 잘해야한다.
- 즉 Form Class에 로직코드에 해당되는 부분은 클래스파일을 따로 만들어서 작성하도록 한다.

2. Windows.Presentation.Foundation(WPF) 방식
- 디자인파트
- 코드파트로 나눌수 있다는점에서 웹프로그래밍과 일맥상통하다.(xaml/cs)

<Window x:Class="WINPAYCalcM.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:WINPAYCalcM"
        mc:Ignorable="d"
        Title="원리금균등상환계산기(대출상환포함)" Height="1000" Width="1400"
KeyDown="Window_KeyDown">
    <Window.Resources>
        <Style TargetType="DataGrid">
            <Setter Property="ColumnHeaderHeight" Value="40"/>
            <Setter Property="RowHeight" Value="30"/>
            <Setter Property="FontSize" Value="14"/>
            <Setter Property="HorizontalGridLinesBrush" Value="LightGray"/>
            <Setter Property="VerticalGridLinesBrush" Value="LightGray"/>
            <Setter Property="AlternatingRowBackground" Value="LightCyan"/>
            <Setter Property="Background" Value="White"/>
        </Style>
        <Style TargetType="DataGridColumnHeader">
            <Setter Property="Background" Value="SlateGray"/>
            <Setter Property="Foreground" Value="White"/>
            <Setter Property="FontWeight" Value="Bold"/>
            <Setter Property="HorizontalContentAlignment" Value="Center"/>
        </Style>
        <Style TargetType="DataGridRow">
            <EventSetter Event="MouseEnter" Handler="DataGridRow_MouseEnter"/>
            <EventSetter Event="MouseLeave" Handler="DataGridRow_MouseLeave"/>
            <Setter Property="Background" Value="White"/>
        </Style>
    </Window.Resources>
    <DockPanel>
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="_Information">
                <MenuItem Header="기초정보입력" Click="BasicInfoMenuItem_Click"/>
                <MenuItem Header="상환정보입력(자동)" Click="RepayMenuItem_Click"/>
                <MenuItem Header="상환정보입력(수동)" Click="RepayManualMenuItem_Click"/>
                <Separator/>
                <MenuItem Header="_Exit" Click="ExitMenuItem_Click"/>
            </MenuItem>
            <MenuItem Header="_File">
                <MenuItem Header="_Save" Click="SaveFileMenuItem_Click"/>
                <MenuItem Header="_Open" Click="OpenFileMenuItem_Click"/>
            </MenuItem>
            <MenuItem Header="_Help">
                <MenuItem Header="_About" Click="AboutMenuItem_Click"/>
            </MenuItem>
        </Menu>
        <!-- 다른 컨텐츠 -->
        <Grid>
            <DataGrid x:Name="dataGrid" AutoGenerateColumns="False" IsReadOnly="False" CanUserAddRows="True"
                  CanUserDeleteRows="True" CanUserResizeColumns="True" CanUserSortColumns="True" Margin="10">
                <DataGrid.Columns>
                    <DataGridTextColumn Header="번호" Binding="{Binding index}" Width="*"/>
                    <DataGridTextColumn Header="상환방법" Binding="{Binding repaymethod}" Width="*"/>
                    <DataGridTextColumn Header="날짜" Binding="{Binding date}" Width="*"/>
                    <DataGridTextColumn Header="이자금액" Binding="{Binding rate_real_to_bank}" Width="*"/>
                    <DataGridTextColumn Header="원금금액" Binding="{Binding reapy_real_to_bank}" Width="*"/>
                    <DataGridTextColumn Header="이자상환합계" Binding="{Binding rate_real_to_bank_sum}" Width="*"/>
                    <DataGridTextColumn Header="현재원금" Binding="{Binding remain_original_pay}" Width="*"/>
    <DataGridTextColumn Header="원리금균등상환금액(일정)" Binding="{Binding original_rent_pay}" Width="*"/>
                    <DataGridTextColumn Header="이자+원금합계" Binding="{Binding calc_pricipal_plus_interest_sum}" Width="*"/>
                    <DataGridTextColumn Header="상환금액합계(원금+매달일정상환)" Binding="{Binding remain_repay_except_interest_sum}" Width="*"/>
                </DataGrid.Columns>

            </DataGrid>
        </Grid>
    </DockPanel>
</Window>

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)