TCP 연결 종료 과정 (4-way handshake)

C:\Users\B210145_BK\Downloads\exture_3_5_ubuntu_ticker\send>netstat -an | findstr 21111
  TCP    0.0.0.0:21111          0.0.0.0:0              LISTENING
  TCP    127.0.0.1:52028        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52039        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52041        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52042        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52043        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52044        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52045        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52047        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52048        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52049        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52050        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52054        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52059        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52060        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52062        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52064        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52065        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52066        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52067        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52068        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52069        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52070        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52071        127.0.0.1:21111        TIME_WAIT
  TCP    127.0.0.1:52072        127.0.0.1:21111        TIME_WAIT

TIME_WAIT 상태가 발생하는 이유는 TCP 연결이 정상적으로 종료될 때 클라이언트 또는 서버가 잠시 동안 연결을 유지하는 과정에서 발생합니다. 이 상태는 연결이 완전히 종료되기 전에 남아있는 패킷들이 네트워크에서 잘못 전달되는 것을 방지하고, 이전에 사용된 소켓 번호가 재사용될 때 발생할 수 있는 문제를 방지하기 위해 설계되었습니다.

TCP 연결 종료 과정 (4-way handshake):

  1. FIN_WAIT-1: 클라이언트가 연결 종료를 요청하며 FIN 패킷을 전송합니다.
  2. CLOSE_WAIT: 서버가 FIN 패킷을 받고 ACK(확인 응답)를 보냅니다.
  3. FIN_WAIT-2: 서버가 연결 종료를 요청하며 FIN 패킷을 전송합니다.
  4. TIME_WAIT: 클라이언트가 서버로부터 FIN 패킷을 받고, ACK를 보낸 후 일정 시간 동안 기다립니다.


    TIME_WAIT 상태가 생기는 이유:
    1. 잔여 패킷 방지: 네트워크에서 늦게 도착한 패킷이 새로운 연결에 영향을 주지 않도록 하기 위해, TCP는 TIME_WAIT 상태를 유지하여 그 연결에 대한 패킷이 모두 소진되었음을 확인합니다.
    2. 포트 재사용 방지: 동일한 소켓 번호(포트)를 사용하는 새 연결이 바로 발생할 경우, 이전 연결의 잔여 패킷이 새 연결에 영향을 줄 수 있습니다. TIME_WAIT 상태는 이러한 상황을 방지하는 역할을 합니다.
    기본적으로 TIME_WAIT 상태는 일정 시간이 지나면 자동으로 종료되며, 이는 운영체제에 따라 다를 수 있습니다(일반적으로 2배의 Maximum Segment Lifetime, MSL). TIME_WAIT 상태가 너무 많으면 시스템의 소켓 리소스를 소모할 수 있지만, 이는 TCP 프로토콜의 정상적인 동작의 일환이므로 필요 이상으로 걱정할 필요는 없습니다.

Title) Multi HomeTrade & Redis Connect & Data Request - Response

HomeTrade(1) - LOGIN -> Private QueueName Send - (212700163791921682149)

HomeTrade(2) - LOGIN -> Private QueueName Send - (112700163791921682149)


DIAGRAM.BASIC LOGIN

 

 

Linux에서)

1. 리눅스 종류

sinfo@sinfo:~$ uname -a
Linux sinfo 5.4.0-192-generic #212-Ubuntu SMP Fri Jul 5 09:47:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

2. 네트워크 연결상태

sinfo@sinfo:~$ netstat -an | grep 21111
tcp        0      0 0.0.0.0:21111           0.0.0.0:*               LISTEN
tcp        0      0 192.168.45.48:21111     192.168.45.106:50236    ESTABLISHED
tcp        0      0 192.168.45.48:21111     192.168.45.106:50232    ESTABLISHED
sinfo@sinfo:~$ netstat -an | grep 6379
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN
tcp        0      0 192.168.45.48:6379      192.168.45.106:50237    ESTABLISHED
tcp        0      0 127.0.0.1:6379          127.0.0.1:44420         ESTABLISHED
tcp        0      0 127.0.0.1:6379          127.0.0.1:45878         ESTABLISHED
tcp        0      0 192.168.45.48:6379      192.168.45.106:50243    ESTABLISHED
tcp        0      0 192.168.45.48:6379      192.168.45.106:50233    ESTABLISHED
tcp        0      0 127.0.0.1:45878         127.0.0.1:6379          ESTABLISHED
tcp        0      0 127.0.0.1:44420         127.0.0.1:6379          ESTABLISHED
sinfo@sinfo:~$

3. 프로세스 확인

sinfo@sinfo:~$ ps -ef | grep redis
redis       1056       1  0 21:36 ?        00:00:13 /usr/bin/redis-server 0.0.0.0:6379
sinfo       5828    5350  0 23:02 pts/1    00:00:00 grep --color=auto redis
sinfo@sinfo:~$ ps aux | grep dotnet
sinfo       5538  1.2  2.6 274724316 215040 pts/0 Sl  22:53   0:07 /usr/share/dotnet/dotnet exec /usr/share/dotnet/sdk/7.0.410/Roslyn/bincore/VBCSCompiler.dll -pipename:MhsDIaqs8oyke8Na2IDl4QN9EwVUpE+Cpyfj50fyAN4
sinfo       5676  0.5  2.0 274830744 163780 pts/0 Sl+ 22:56   0:02 dotnet run
sinfo       5844  0.0  0.0   6432   720 pts/1    S+   23:03   0:00 grep --color=auto dotnet
sinfo@sinfo:~$ ps aux | grep mdi
sinfo       5706  0.3  1.3 274329620 112340 pts/0 Sl+ 22:56   0:01 /data/sinfo/exture_3_0_ticker/mdiwebrowser/bin/Debug/net7.0/mdiwebrowser
sinfo       5852  0.0  0.0   6300   656 pts/1    S+   23:03   0:00 grep --color=auto mdi
sinfo@sinfo:~$


4. 클라이언트는 Windows////////

 

GetInstance를 활용한 List<string> 예제,ㅡㅡㅡ,ㅡㅡㅡ
GetInstance를 활용한 List<string> 예제,ㅡㅡㅡ,ㅡㅡㅡ

public List<string> redisSenderQueueNM

using System;
using System.Collections.Generic;

public class APMMemory
{
    private static APMMemory apmMemory;
    private List<string> redissenderqueuenm = new List<string>();

    public List<string> redisSenderQueueNM
    {
        get { return redissenderqueuenm; }
        set { redissenderqueuenm = value; }
    }

    private APMMemory() { }

    public static APMMemory GetInstance
    {
        get
        {
            if (apmMemory == null)
                apmMemory = new APMMemory();
            return apmMemory;
        }
    }

    // 문자열을 추가할 때 중복을 체크하는 메서드
    public void AddQueueName(string queueName)
    {
        if (!redissenderqueuenm.Contains(queueName))
        {
            redissenderqueuenm.Add(queueName);
            Console.WriteLine($"Added: {queueName}");
        }
        else
        {
            Console.WriteLine($"Queue name '{queueName}' already exists and was not added.");
        }
    }
}

public class Program
{
    public static void Main(string[] args)
    {
        // Singleton instance 가져오기
        APMMemory apmMemory = APMMemory.GetInstance;

        // 중복되지 않게 문자열을 리스트에 추가
        apmMemory.AddQueueName("Queue1");
        apmMemory.AddQueueName("Queue2");
        apmMemory.AddQueueName("Queue3");

        // 중복되는 문자열 추가 시도
        apmMemory.AddQueueName("Queue2");  // 이미 존재하는 문자열
        apmMemory.AddQueueName("Queue4");

        // redisSenderQueueNM 리스트 출력
        Console.WriteLine("\nFinal Redis Sender Queue Names:");
        foreach (string queueName in apmMemory.redisSenderQueueNM)
        {
            Console.WriteLine(queueName);
        }
    }
}

[A 경제용어사전] '베어마켓·불마켓(bear·bull market)'


황소(Bull)
황소 시장(Bull Market)은 주가가 전반적으로 상승하는 시장 상태를 나타내며, 이는 경제의 성장, 기업 실적 호조, 투자자들의 신뢰 증가 등으로 인해 발생합니다.
황소는 뿔을 위로 치켜들며 공격하는 습성 때문에 상승을 상징하게 되었습니다.
황소 시장에서는 투자자들이 적극적으로 주식을 매수하며, 이러한 매수세는 주가를 더욱 끌어올립니다.
역사적으로, '황소'는 19세기 초부터 금융가들 사이에서 사용되기 시작했습니다.
이 용어는 특히 뉴욕 증권거래소(NYSE)가 발달하면서 더욱 널리 퍼졌습니다.
황소 시장은 경제의 번영기와 맞물리며, 투자자들에게 높은 수익을 안겨주는 시기로 평가받습니다.

곰 (Bear)
곰은 증권시장에서 비관적인 분위기와 하락장을 상징합니다.
곰 시장(Bear Market)은 주가가 전반적으로 하락하는 시장 상태를 의미하며, 이는 경제 불황, 기업 실적 악화, 투자자들의 불안감 증가 등으로 인해 발생합니다.
곰은 발톱을 아래로 내리치는 습성 때문에 하락을 상징하게 되었습니다.
곰 시장에서는 투자자들이 주식을 매도하며, 이러한 매도세는 주가를 더욱 끌어내립니다.
'곰' 역시 19세기 초부터 금융가들 사이에서 사용되기 시작했습니다.
곰 시장은 경제의 불황기와 맞물리며, 투자자들에게 큰 손실을 안겨주는 시기로 평가받습니다.

 

(한국.거래소의 황소와 곰의 모습)

KRX 정보분배데이타,수신서버및 HomeTrade 제작

내용)

1. KRX 정보분배데이타 송신 SYSTEM 제작
2. KRX 정보분배데이타 수신 SYSTEM 제작
2.1 - KRX 정보분배데이타 수신
2.2 - KRX 정보분배데이타 저장(SQLite)
2.3 - KRX 정보분배데이타 REDIS전송
2.4 - 클라이언트 로그인 관리
2.5 - 클라이언트 조회요청시 데이타 전송
3. Like HomeTradeSystem - Win MDI Application
3.1 - 로그인
3.2 - 조회및 데이타 실시간수신
4. 디버깅 - Windows SendMessage 활용


기술)
1. KRX 정보분배데이타 송신 SYSTEM 제작 -> c
2. KRX 정보분배데이타 수신 SYSTEM 제작 -> c# Console
2.1 - KRX 정보분배데이타 수신
2.2 - KRX 정보분배데이타 저장(SQLite) - SQLite DataBase
2.3 - KRX 정보분배데이타 REDIS전송 - Redis Server
2.4 - 클라이언트 로그인 관리
2.5 - 클라이언트 조회요청시 데이타 전송
3. Like HomeTradeSystem - Win MDI Application - c# Win Form
3.1 - 로그인
3.2 - 조회및 데이타 실시간수신


MENU& TREE를 동시에 구성


일별.캔들차드 추가(feat. CHAT.GPT)

 

REDIS.QUEUE.NAME WHEN RCV/SND
REDIS.QUEUE.NAME WHEN RCV/SND

 


dotnet new wpf -n sampleNM

error CS0246: 'Newtonsoft' 형식또는 네임스페이스 이름을 찾을 수 없습니다. using 지시문 또는 어셈블리 참조가 있는지 확인하세요.
>dotnet add package Newtonsoft.Json

error CS0246: 'ServiceStack' 형식 또는 네임스페이스 이름을 찾을 수 없습니다. using 지시문 또는 어셈블리 참조가 있는지 확인하세요.
>dotnet add package ServiceStack

error CS0246: 'RedisClient' 형식 또는 네임스페이스 이름을 찾을 수 없습니다. using 지시문 또는 어셈블리 참조가 있는지 확인하세요.
>dotnet add package ServiceStack.Redis

KeyValuePair<TKey, TValue>는 C#에서 제공하는 구조체(struct)로, 키와 값을 쌍으로 묶어서 관리할 수 있게 해줍니다. 주로 컬렉션에서 특정 항목의 키와 값을 함께 다룰 때 사용됩니다.

주요 특징

  1. 제네릭 타입: KeyValuePair는 제네릭 타입으로, 키와 값의 데이터 타입을 지정할 수 있습니다. 예를 들어, KeyValuePair<int, string>는 정수형 키와 문자열 값을 가지는 쌍을 의미합니다.
  2. 구성: KeyValuePair는 두 개의 읽기 전용 속성, Key와 Value,으로 구성됩니다. Key는 쌍의 키를, Value는 쌍의 값을 나타냅니다.
  3. 불변성: KeyValuePair의 키와 값은 읽기 전용 속성으로 정의되어 있으며, 한 번 생성된 후에는 변경할 수 없습니다.

사용 예제

다음은 KeyValuePair를 사용하는 몇 가지 예제입니다.

1. 기본 사용

// KeyValuePair 생성 KeyValuePair<int, string> kvp = new KeyValuePair<int, string>(1, "Value"); // 키와 값에 접근 Console.WriteLine($"Key: {kvp.Key}, Value: {kvp.Value}");

2. Dictionary에서 사용

Dictionary 클래스는 내부적으로 KeyValuePair를 사용하여 키와 값을 저장합니다.

Dictionary<string, int> dictionary = new Dictionary<string, int>(); // 키와 값을 추가 dictionary.Add("Apple", 1); dictionary.Add("Banana", 2); // Dictionary의 모든 항목을 반복 foreach (KeyValuePair<string, int> kvp in dictionary) { Console.WriteLine($"Key: {kvp.Key}, Value: {kvp.Value}"); }

3. LINQ와 함께 사용

LINQ를 사용할 때 KeyValuePair를 반환하는 메서드를 사용할 수 있습니다.

var list = new List<KeyValuePair<string, int>>() { new KeyValuePair<string, int>("Apple", 1), new KeyValuePair<string, int>("Banana", 2), }; var result = list.Where(kvp => kvp.Value > 1); foreach (var kvp in result) { Console.WriteLine($"Key: {kvp.Key}, Value: {kvp.Value}"); }

이와 같이 KeyValuePair는 다양한 상황에서 유용하게 사용될 수 있으며, 특히 컬렉션과 관련된 작업에서 많이 활용됩니다.

+ Recent posts