리버스 프록시(Reverse Proxy)

리버스 프록시(Reverse Proxy) 서버는 인터넷으로부터의 클라이언트 요청을 받아 백엔드 서버(실제 콘텐츠나 애플리케이션을 호스팅하는 서버)로 전달하고,

백엔드 서버로부터 받은 응답을 다시 클라이언트에게 전달하는 서버입니다.

정리하자면 웹 서비스의 최전선에 위치하여 클라이언트와 실제 서버 사이의 중개자 역할

일반적인 포워드 프록시(Forward Proxy)가 클라이언트가 인터넷에 접속하기 위해 사용하는 것(예: 회사 네트워크에서 외부 웹사이트 접속)과는 반대로,

리버스 프록시(Reverse Proxy)는 서버 앞단에서 서버로 들어오는 요청을 처리합니다.

리버스 프록시는 왜 사용하는가?

리버스 프록시는 아래과 같은 주요 이점 때문에 웹 아키텍처에서 필수적인 요소로 자리를 잡았습니다.

1⃣ 보안 강화 (Security)

• 직접적인 서버 노출 방지:
  실제 백엔드 서버의 IP 주소나 내부 구조를 외부 클라이언트에게 숨겨 보안 위험을 줄입니다. 공격자는 리버스 프록시만 볼 수 있습니다.
• 공격 방어:
  DDoS 공격, SQL Injection, XSS 공격 등 다양한 웹 공격에 대한 1차 방어선 역할을 수행합니다. 수상한 트래픽을 필터링하거나 차단할 수 있습니다.
• SSL/TLS 암호화 종료 (SSL/TLS Termination):
  클라이언트와의 암호화된 통신(HTTPS)을 리버스 프록시가 대신 처리하고, 백엔드 서버와의 통신은 암호화되지 않은 HTTP로 전환할 수 있습니다.
  이는 백엔드 서버의 부하를 줄여주고, SSL 인증서 관리의 중앙화를 가능하게 합니다.

2⃣ 로드 밸런싱 (Load Balancing)

• 리버스 프록시는 여러 개의 백엔드 서버로 트래픽을 효율적으로 분산하여 특정 서버에 부하가 집중되는 것을 방지합니다.
  이를 통해 서비스의 안정성과 가용성을 높이고, 대규모 트래픽을 처리할 수 있도록 확장성을 제공합니다.
• 서버 중 하나에 문제가 발생하면, 해당 서버로의 트래픽을 중단하고 정상 작동하는 다른 서버로 요청을 보낼 수 있습니다.

3⃣ 성능 최적화 (Performance Optimization)

• 캐싱 (Caching):
  자주 요청되는 정적 콘텐츠(이미지, CSS, JavaScript 파일 등)를 리버스 프록시 서버에 캐싱하여,
  백엔드 서버로의 요청을 줄이고 클라이언트에게 더 빠르게 응답할 수 있습니다.
• 압축 (Compression):
  클라이언트에게 보내는 응답 데이터를 압축하여 전송량을 줄이고 로딩 속도를 향상시킵니다.

4⃣ 쉬운 유지보수 및 확장 (Maintainability & Scalability)

• 백엔드 서버를 추가하거나 제거할 때, 클라이언트는 리버스 프록시의 주소만 알기 때문에 변경 사항을 알 필요가 없습니다.
  이는 서버 아키텍처를 유연하게 관리할 수 있도록 해줍니다.
• A/B 테스트, URL 재작성, 특정 요청 라우팅 등 복잡한 트래픽 관리 정책을 구현하기 용이합니다.

동작 방식 요약

1. 클라이언트 요청:
   웹 브라우저와 같은 클라이언트가 특정 웹 서비스(예: www.example.com)에 요청을 보냅니다.
2. 리버스 프록시 수신:
   이 요청은 DNS 설정을 통해 리버스 프록시 서버로 전달됩니다.
3. 요청 처리 및 전달:
   리버스 프록시 서버는 요청을 검사하고, 설정된 규칙(로드 밸런싱 알고리즘, URL 경로 등)에 따라 적절한 백엔드 서버를 선택하여 요청을 전달합니다.
   (이때, SSL/TLS 종료가 이루어질 수 있습니다.)
4. 응답 수신 및 전달:
   백엔드 서버는 요청을 처리하고 응답을 리버스 프록시 서버로 보냅니다.
   리버스 프록시는 이 응답을 받아 (캐싱, 압축 등의 처리를 거쳐) 최종적으로 클라이언트에게 전달합니다.

대표적인 리버스 프록시 소프트웨어

• Nginx (엔진엑스):
  가장 널리 사용되는 웹 서버이자 리버스 프록시 서버입니다. 고성능과 경량성이 특징입니다.
• Apache HTTP Server (아파치):
  mod_proxy 모듈을 통해 리버스 프록시 기능을 제공합니다.
• HAProxy:
  고가용성 로드 밸런싱 및 프록싱에 특화된 솔루션입니다.
• Envoy Proxy:
  마이크로서비스 아키텍처에서 많이 사용되는 최신 프록시입니다.

The post 리버스 프록시(Reverse Proxy) 개념 appeared first on 어제와 내일의 나 그 사이의 이야기.

.NET의 파이프 작업

https://learn.microsoft.com/en-us/dotnet/standard/io/pipe-operations

파이프는 프로세스 간 통신(Interprocess Communication, IPC)을 위한 수단을 제공합니다.

파이프에는 두 가지 유형이 있습니다:

• 익명 파이프 (Anonymous Pipes)
• 명명된 파이프 (Named Pipes)

익명 파이프 (Anonymous Pipes)

익명 파이프는 로컬 컴퓨터에서 프로세스 간 통신을 제공합니다.

익명 파이프는 명명된 파이프보다 오버헤드가 적지만 제공하는 서비스가 제한적입니다.

익명 파이프는 단방향이며 네트워크를 통해 사용할 수 없습니다. 또한 단일 서버 인스턴스만 지원합니다.

익명 파이프는 스레드 간 통신, 또는 파이프 핸들을 자식 프로세스가 생성될 때 쉽게 전달할 수 있는 부모-자식 프로세스 간 통신에 유용합니다.

.NET에서는 AnonymousPipeServerStream 및 AnonymousPipeClientStream 클래스를 사용하여 익명 파이프를 구현합니다.

익명 파이프 (Anonymous Pipes) 사용 방법

https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-anonymous-pipes-for-local-interprocess-communication

예제 1: 서버 프로세스 (부모 프로세스)

다음 예제는 익명 파이프를 사용하여 부모 프로세스에서 자식 프로세스로 문자열을 보내는 방법을 보여줍니다.

이 예제에서는 부모 프로세스에 PipeDirection.Out 값을 가진 AnonymousPipeServerStream 객체를 생성합니다.

그런 다음 부모 프로세스는 클라이언트 핸들을 사용하여 AnonymousPipeClientStream 객체를 생성하는 자식 프로세스를 시작합니다.

자식 프로세스는 PipeDirection.In 값을 가집니다.

이후 부모 프로세스는 사용자가 입력한 문자열을 자식 프로세스로 보냅니다.

해당 문자열은 자식 프로세스의 콘솔에 표시됩니다. 다음은 서버 프로세스(부모 프로세스) 코드입니다.

using System;
using System.IO;
using System.IO.Pipes;
using System.Diagnostics; // Process 클래스를 사용하기 위해 추가

class PipeServer
{
    static void Main()
    {
        Process pipeClient = new Process(); // 자식 프로세스를 제어할 Process 객체 생성

        pipeClient.StartInfo.FileName = "pipeClient.exe"; // 실행할 자식 프로세스의 파일 이름 설정

        // AnonymousPipeServerStream 객체 생성
        // PipeDirection.Out: 서버 -> 클라이언트로 데이터를 보냄 (단방향)
        // HandleInheritability.Inheritable: 자식 프로세스가 이 파이프 핸들을 상속받을 수 있도록 설정
        using (AnonymousPipeServerStream pipeServer =
            new AnonymousPipeServerStream(PipeDirection.Out,
            HandleInheritability.Inheritable))
        {
            Console.WriteLine($"[SERVER] 현재 전송 모드: {pipeServer.TransmissionMode}.");

            // 자식 프로세스에게 서버 파이프의 클라이언트 핸들을 문자열로 전달합니다.
            pipeClient.StartInfo.Arguments =
                pipeServer.GetClientHandleAsString();
            pipeClient.StartInfo.UseShellExecute = false; // 셸 실행 대신 직접 프로세스 시작
            pipeClient.Start(); // 자식 프로세스 시작

            // 자식 프로세스가 핸들을 상속받은 후, 부모 프로세스는 자신의 클라이언트 핸들 복사본을 해제합니다.
            // 이는 불필요한 리소스 유지를 방지합니다.
            pipeServer.DisposeLocalCopyOfClientHandle();

            try
            {
                // 사용자 입력을 읽고 그 내용을 클라이언트 프로세스로 보냅니다.
                using (StreamWriter sw = new StreamWriter(pipeServer))
                {
                    sw.AutoFlush = true; // 매 쓰기 작업 후 스트림 자동 플러시 설정

                    // '동기화 메시지'를 클라이언트로 보내고 클라이언트가 이를 받을 때까지 기다립니다.
                    sw.WriteLine("SYNC");
                    pipeServer.WaitForPipeDrain(); // 파이프에 기록된 모든 데이터가 전송될 때까지 대기

                    // 콘솔 입력을 클라이언트 프로세스로 보냅니다.
                    Console.Write("[SERVER] 텍스트를 입력하세요: ");
                    sw.WriteLine(Console.ReadLine());
                }
            }
            // 파이프가 끊어지거나 연결이 해제될 때 발생하는 IOException을 잡습니다.
            catch (IOException e)
            {
                Console.WriteLine($"[SERVER] 오류: {e.Message}");
            }
        } // using 블록을 벗어나면 pipeServer는 자동으로 Dispose됩니다.

        // 자식 프로세스가 종료될 때까지 기다립니다.
        pipeClient.WaitForExit();
        // 자식 프로세스 객체를 닫습니다.
        pipeClient.Close();
        Console.WriteLine("[SERVER] 클라이언트 종료. 서버도 종료합니다.");
    }
}

예제 2: 클라이언트 프로세스 (자식 프로세스)

다음 예제는 클라이언트 프로세스를 보여줍니다.

서버 프로세스는 클라이언트 프로세스를 시작하고 해당 프로세스에 클라이언트 핸들을 전달합니다.

클라이언트 코드로부터 생성된 실행 파일은 pipeClient.exe라는 이름으로 서버 실행 파일과 동일한 디렉토리에 복사되어야 서버 프로세스를 실행하기 전에 올바르게 동작합니다.

using System;
using System.IO;
using System.IO.Pipes;

class PipeClient
{
    static void Main(string[] args)
    {
        // 프로그램 인수가 있는지 확인합니다.
        // 서버가 클라이언트 핸들을 인수로 전달하기 때문에 필요합니다.
        if (args.Length > 0)
        {
            // AnonymousPipeClientStream 객체를 생성합니다.
            // PipeDirection.In: 클라이언트는 서버로부터 데이터를 받음 (단방향)
            // args[0]: 서버가 전달한 파이프 핸들 문자열
            using (PipeStream pipeClient =
                new AnonymousPipeClientStream(PipeDirection.In, args[0]))
            {
                Console.WriteLine($"[CLIENT] 현재 전송 모드: {pipeClient.TransmissionMode}.");

                // 파이프 스트림에서 텍스트를 읽기 위한 StreamReader 생성
                using (StreamReader sr = new StreamReader(pipeClient))
                {
                    string temp;

                    // 서버로부터 '동기화 메시지'가 올 때까지 기다립니다.
                    do
                    {
                        Console.WriteLine("[CLIENT] 동기화 대기 중...");
                        temp = sr.ReadLine();
                    }
                    while (!temp.StartsWith("SYNC")); // 'SYNC'로 시작하는 메시지를 받을 때까지 반복

                    // 서버 데이터를 읽고 콘솔에 출력합니다.
                    while ((temp = sr.ReadLine()) != null) // 스트림의 끝(null)이 아닐 때까지 읽기
                    {
                        Console.WriteLine("[CLIENT] 에코: " + temp);
                    }
                }
            } // using 블록을 벗어나면 pipeClient는 자동으로 Dispose됩니다.
        }
        Console.Write("[CLIENT] 계속하려면 Enter 키를 누르세요...");
        Console.ReadLine(); // 사용자가 Enter를 누를 때까지 대기
    }
}

명명된 파이프 (Named Pipes)

명명된 파이프는 파이프 서버와 하나 이상의 파이프 클라이언트 간 프로세스 간 통신을 제공합니다.

명명된 파이프는 단방향 또는 양방향이 될 수 있습니다.

이는 메시지 기반 통신을 지원하며, 여러 클라이언트가 동일한 파이프 이름을 사용하여 서버 프로세스에 동시에 연결할 수 있도록 합니다.

명명된 파이프는 또한 가장(impersonation)을 지원하는데, 이를 통해 연결 프로세스가 원격 서버에서 자신의 권한을 사용할 수 있습니다.

.NET에서는 NamedPipeServerStream 및 NamedPipeClientStream 클래스를 사용하여 명명된 파이프를 구현합니다.

가장(Impersonation)이란?

컴퓨터 시스템에서 어떤 리소스(예: 파일, 네트워크 공유, 데이터베이스)에 접근하려면 해당 작업을 수행하는 사용자 계정의 권한이 필요

일반적으로 서버 애플리케이션은 특정 계정(예: 시스템 계정, 서비스 계정)의 권한으로 실행됩니다.

만약 서버가 클라이언트가 요청한 작업을 클라이언트 자신의 권한으로 수행해야 할 때가 있습니다. 예를 들어:

• 클라이언트가 접근 권한을 가진 특정 파일 읽기/쓰기:
  서버는 클라이언트가 보낸 파일 경로에 대해 읽기/쓰기 요청을 받았습니다.
  하지만 서버는 해당 파일에 직접 접근할 권한이 없고, 오직 클라이언트 계정만 그 파일에 접근할 권한을 가지고 있을 수 있습니다.
• 클라이언트의 네트워크 자격 증명 사용:
  클라이언트가 원격 네트워크 공유에 있는 리소스에 접근하고 싶을 때,
  서버가 클라이언트를 ‘가장’하여 클라이언트의 네트워크 자격 증명(사용자 이름과 비밀번호)을 사용하여 해당 공유에 접근할 수 있습니다.

명명된 파이프(Named Pipes) 사용 방법

https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-named-pipes-for-network-interprocess-communication

예제 1: NamedPipeServerStream 클래스를 사용하여 명명된 파이프 생성하기

다음 예제는 NamedPipeServerStream 클래스를 사용하여 명명된 파이프를 생성하는 방법을 보여줍니다.

이 예제에서 서버 프로세스는 4개의 스레드를 생성합니다. 각 스레드는 하나의 클라이언트 연결을 수락할 수 있습니다.

연결된 클라이언트 프로세스는 서버에 파일 이름을 제공합니다.

만약 클라이언트가 충분한 권한을 가지고 있다면, 서버 프로세스는 해당 파일을 열고 그 내용을 다시 클라이언트에게 보냅니다.

using System;
using System.IO;
using System.IO.Pipes;
using System.Text;
using System.Threading;

public class PipeServer
{
    // 동시에 처리할 서버 스레드의 개수 (클라이언트 연결을 수락할 인스턴스 수)
    private static int numThreads = 4;

    public static void Main()
    {
        int i;
        // 서버 스레드를 담을 배열 선언
        Thread?[] servers = new Thread[numThreads];

        Console.WriteLine("\n*** 명명된 파이프 서버 스트림과 가장(impersonation) 예제 ***\n");
        Console.WriteLine("클라이언트 연결 대기 중...\n");

        // numThreads 개수만큼 서버 스레드를 생성하고 시작합니다.
        for (i = 0; i < numThreads; i++)
        {
            servers[i] = new Thread(ServerThread); // ServerThread 메서드를 실행할 새 스레드 생성
            servers[i]?.Start(); // 스레드 시작
        }

        // 서버 스레드가 시작될 시간을 잠시 기다립니다.
        Thread.Sleep(250);

        // 모든 서버 스레드가 작업을 완료할 때까지 대기하는 루프
        // 'i'는 아직 완료되지 않은 스레드의 개수를 추적합니다.
        while (i > 0)
        {
            for (int j = 0; j < numThreads; j++)
            {
                if (servers[j] != null) // 스레드가 아직 활성 상태인 경우
                {
                    // 스레드가 250ms 내에 완료되는지 확인합니다.
                    // 완료되면 해당 스레드를 null로 설정하고 카운트를 줄입니다.
                    if (servers[j]!.Join(250))
                    {
                        Console.WriteLine($"서버 스레드[{servers[j]!.ManagedThreadId}] 작업 완료.");
                        servers[j] = null; // 완료된 스레드 참조 제거
                        i--;               // 완료되지 않은 스레드 개수 감소
                    }
                }
            }
        }
        Console.WriteLine("\n서버 스레드 모두 소진, 종료합니다.");
    }

    // 각 클라이언트 연결을 처리할 서버 스레드의 진입점 메서드
    private static void ServerThread(object? data)
    {
        // NamedPipeServerStream 인스턴스 생성
        // "testpipe": 파이프 이름 (클라이언트가 이 이름으로 연결 시도)
        // PipeDirection.InOut: 양방향 통신
        // numThreads: 이 파이프 이름으로 동시에 허용할 서버 인스턴스(클라이언트 연결)의 최대 수
        NamedPipeServerStream pipeServer =
            new NamedPipeServerStream("testpipe", PipeDirection.InOut, numThreads);

        int threadId = Thread.CurrentThread.ManagedThreadId; // 현재 스레드의 ID

        // 클라이언트가 연결될 때까지 대기합니다.
        // 이 메서드는 블로킹(blocking) 호출입니다.
        pipeServer.WaitForConnection();

        Console.WriteLine($"클라이언트가 스레드[{threadId}]에 연결되었습니다.");
        try
        {
            // 클라이언트로부터 요청을 읽습니다.
            // 클라이언트가 파이프에 데이터를 쓰면, 클라이언트의 보안 토큰을 사용할 수 있게 됩니다.
            StreamString ss = new StreamString(pipeServer);

            // 연결된 클라이언트에게 서버임을 증명하는 문자열을 보냅니다.
            // 클라이언트는 이 문자열을 예상하고 있습니다.
            ss.WriteString("나는 유일한 참된 서버입니다!");
            // 클라이언트로부터 파일 이름을 읽습니다.
            string filename = ss.ReadString();

            // 클라이언트를 가장(impersonate)하여 파일 내용을 읽어 스트림으로 보냅니다.
            // ReadFileToStream 클래스는 파일 읽기 로직을 캡슐화합니다.
            ReadFileToStream fileReader = new ReadFileToStream(ss, filename);

            // 현재 가장하고 있는 사용자의 이름을 출력합니다.
            Console.WriteLine($"파일 읽기: {filename} (스레드[{threadId}]) 사용자: {pipeServer.GetImpersonationUserName()}로.");
            // 클라이언트를 가장한 보안 컨텍스트 내에서 fileReader.Start 메서드를 실행합니다.
            // 이 시점부터 Start() 메서드 내의 파일 접근은 클라이언트의 권한으로 이루어집니다.
            pipeServer.RunAsClient(fileReader.Start);
        }
        // 파이프가 끊어지거나 연결이 해제될 때 발생하는 IOException을 잡습니다.
        catch (IOException e)
        {
            Console.WriteLine($"오류: {e.Message}");
        }
        finally
        {
            // 파이프 서버 스트림을 닫고 리소스를 해제합니다.
            pipeServer.Close();
            Console.WriteLine($"스레드[{threadId}] 파이프 서버 닫힘.");
        }
    }
}

// 스트림에서 문자열을 읽고 쓰기 위한 데이터 프로토콜을 정의하는 클래스
public class StreamString
{
    private Stream ioStream; // 기본 스트림 (NamedPipeServerStream 또는 NamedPipeClientStream)
    private UnicodeEncoding streamEncoding; // 문자열 인코딩 방식

    public StreamString(Stream ioStream)
    {
        this.ioStream = ioStream;
        streamEncoding = new UnicodeEncoding(); // UTF-16 인코딩 사용
    }

    // 스트림에서 문자열을 읽습니다.
    public string ReadString()
    {
        // 먼저 문자열의 길이를 2바이트로 읽습니다. (Big-endian 방식으로)
        int len = 0;
        len = ioStream.ReadByte() * 256; // 첫 번째 바이트 (상위 8비트)
        len += ioStream.ReadByte();      // 두 번째 바이트 (하위 8비트)

        // 읽을 길이만큼의 바이트 배열을 생성합니다.
        byte[] inBuffer = new byte[len];
        // 스트림에서 해당 길이만큼의 바이트를 읽어 버퍼에 채웁니다.
        ioStream.Read(inBuffer, 0, len);

        // 바이트 배열을 문자열로 디코딩하여 반환합니다.
        return streamEncoding.GetString(inBuffer);
    }

    // 스트림에 문자열을 씁니다.
    public int WriteString(string outString)
    {
        // 문자열을 바이트 배열로 인코딩합니다.
        byte[] outBuffer = streamEncoding.GetBytes(outString);
        int len = outBuffer.Length;

        // 문자열 길이가 UInt16.MaxValue (65535)를 초과하면 잘라냅니다.
        // (프로토콜이 2바이트 길이 필드를 사용하므로 최대 65535 바이트까지 표현 가능)
        if (len > UInt16.MaxValue)
        {
            len = (int)UInt16.MaxValue;
        }

        // 문자열의 길이를 2바이트로 스트림에 씁니다. (Big-endian 방식으로)
        ioStream.WriteByte((byte)(len / 256)); // 상위 바이트
        ioStream.WriteByte((byte)(len & 255)); // 하위 바이트
        // 문자열 바이트 배열을 스트림에 씁니다.
        ioStream.Write(outBuffer, 0, len);
        // 버퍼에 남아있는 데이터를 즉시 스트림으로 밀어 넣습니다.
        ioStream.Flush();

        // 전송된 총 바이트 수 (문자열 바이트 + 길이 2바이트)를 반환합니다.
        return outBuffer.Length + 2;
    }
}

// 가장된 사용자(클라이언트)의 컨텍스트에서 실행될 메서드를 포함하는 클래스
public class ReadFileToStream
{
    private string fn; // 읽을 파일 이름
    private StreamString ss; // 파일 내용을 쓸 스트림 (StreamString 헬퍼 사용)

    public ReadFileToStream(StreamString str, string filename)
    {
        fn = filename;
        ss = str;
    }

    // 이 메서드는 pipeServer.RunAsClient()에 의해 호출되며,
    // 호출되는 동안 현재 스레드의 보안 컨텍스트가 클라이언트로 변경됩니다.
    public void Start()
    {
        // 클라이언트의 권한으로 파일을 읽습니다.
        string contents = File.ReadAllText(fn);
        // 읽은 파일 내용을 스트림을 통해 클라이언트에게 다시 보냅니다.
        ss.WriteString(contents);
    }
}

예제 2: NamedPipeClientStream 클래스를 사용하는 클라이언트 프로세스

다음 예제는 NamedPipeClientStream 클래스를 사용하는 클라이언트 프로세스를 보여줍니다.

이 클라이언트는 서버 프로세스에 연결하여 서버로 파일 이름을 전송합니다.

이 예제에서는 가장(impersonation) 기능을 사용하므로, 클라이언트 애플리케이션을 실행하는 사용자 계정에 해당 파일에 접근할 수 있는 권한이 있어야 합니다.

그러면 서버는 파일 내용을 다시 클라이언트에게 전송하고, 클라이언트는 그 내용을 콘솔에 표시합니다.

using System;
using System.Diagnostics; // 프로세스 관련 기능을 위해 추가
using System.IO;          // 파일 및 스트림 관련 기능을 위해 추가
using System.IO.Pipes;    // Named Pipe 관련 기능을 위해 추가
using System.Security.Principal; // TokenImpersonationLevel을 위해 추가
using System.Text;        // 인코딩을 위해 추가
using System.Threading;   // 스레드 및 Sleep을 위해 추가

public class PipeClient
{
    // 생성할 클라이언트 프로세스의 개수
    private static int numClients = 4;

    public static void Main(string[] args)
    {
        // 프로그램이 'spawnclient' 인수를 가지고 실행되었는지 확인합니다.
        // 이 인수는 메인 프로세스가 다른 클라이언트 프로세스를 시작할 때 사용됩니다.
        if (args.Length > 0)
        {
            if (args[0] == "spawnclient")
            {
                // 'spawnclient' 인수가 있는 경우, 명명된 파이프 클라이언트를 생성하고 서버에 연결합니다.
                var pipeClient =
                    new NamedPipeClientStream(
                        ".",                 // 파이프가 로컬 컴퓨터에 있음을 나타냅니다. (서버 주소)
                        "testpipe",          // 연결할 파이프 이름 (서버의 파이프 이름과 일치해야 합니다)
                        PipeDirection.InOut, // 양방향 통신
                        PipeOptions.None,    // 추가 파이프 옵션 없음
                        TokenImpersonationLevel.Impersonation); // 클라이언트의 보안 토큰을 서버로 전송하여 가장을 허용합니다.

                Console.WriteLine("서버에 연결 중...\n");
                // 서버에 연결될 때까지 대기합니다.
                pipeClient.Connect();

                var ss = new StreamString(pipeClient);
                // 서버의 서명 문자열("I am the one true server!")을 읽어 유효성을 검사합니다.
                if (ss.ReadString() == "I am the one true server!")
                {
                    // 첫 번째 쓰기 작업과 함께 클라이언트의 보안 토큰이 서버로 전송됩니다.
                    // 서버가 파일 내용을 반환할 파일 이름을 서버로 보냅니다.
                    ss.WriteString("c:\\textfile.txt"); // 서버가 읽을 파일 경로를 지정합니다.

                    // 서버로부터 파일 내용을 읽어 콘솔에 출력합니다.
                    Console.Write(ss.ReadString());
                }
                else
                {
                    Console.WriteLine("서버를 확인할 수 없습니다.");
                }
                // 파이프 클라이언트 스트림을 닫고 리소스를 해제합니다.
                pipeClient.Close();
                // 클라이언트 프로세스가 결과를 표시할 시간을 주기 위해 4초 동안 대기합니다.
                Thread.Sleep(4000);
            }
        }
        else // 'spawnclient' 인수가 없는 경우, 여러 클라이언트 프로세스를 시작합니다.
        {
            Console.WriteLine("\n*** 가장(impersonation) 예제를 포함한 명명된 파이프 클라이언트 스트림 ***\n");
            // 클라이언트 프로세스를 시작하는 헬퍼 함수를 호출합니다.
            StartClients();
        }
    }

    // 파이프 클라이언트 프로세스를 생성하는 헬퍼 함수
    private static void StartClients()
    {
        // 현재 실행 중인 프로세스의 전체 명령줄을 가져옵니다. (예: "C:\path\to\YourApp.exe")
        string currentProcessName = Environment.CommandLine;

        // Visual Studio에서 실행될 때 추가되는 따옴표나 공백을 제거합니다.
        currentProcessName = currentProcessName.Trim('"', ' ');

        // 확장자를 .exe로 변경하여 실행 파일 경로를 확보합니다.
        currentProcessName = Path.ChangeExtension(currentProcessName, ".exe");
        Process?[] plist = new Process?[numClients]; // 생성될 클라이언트 프로세스들을 저장할 배열

        Console.WriteLine("클라이언트 프로세스들을 생성 중...\n");

        // 현재 디렉토리 경로가 명령줄에 포함되어 있다면 제거합니다.
        // 이는 Process.Start가 올바른 실행 파일을 찾도록 돕기 위함입니다.
        if (currentProcessName.Contains(Environment.CurrentDirectory))
        {
            currentProcessName = currentProcessName.Replace(Environment.CurrentDirectory, String.Empty);
        }

        // Visual Studio 실행 시 발생할 수 있는 추가적인 문자(백슬래시, 따옴표)를 제거합니다.
        currentProcessName = currentProcessName.Replace("\\", String.Empty);
        currentProcessName = currentProcessName.Replace("\"", String.Empty);

        int i;
        for (i = 0; i < numClients; i++)
        {
            // '이' 프로그램(PipeClient) 자체를 새 프로세스로 시작하되,
            // 'spawnclient' 인수를 전달하여 명명된 파이프 클라이언트 모드로 실행되도록 합니다.
            plist[i] = Process.Start(currentProcessName, "spawnclient");
        }

        // 모든 클라이언트 프로세스가 종료될 때까지 대기하는 루프
        // 'i'는 아직 종료되지 않은 프로세스의 개수를 추적합니다.
        while (i > 0)
        {
            for (int j = 0; j < numClients; j++)
            {
                if (plist[j] != null) // 프로세스가 아직 활성 상태인 경우
                {
                    // 프로세스가 종료되었는지 확인합니다.
                    if (plist[j]!.HasExited)
                    {
                        Console.WriteLine($"클라이언트 프로세스[{plist[j]?.Id}]가 종료되었습니다.");
                        plist[j] = null; // 종료된 프로세스 참조 제거
                        i--;             // 종료되지 않은 프로세스 개수 감소
                    }
                    else
                    {
                        // 아직 종료되지 않았다면 잠시 대기합니다.
                        Thread.Sleep(250);
                    }
                }
            }
        }
        Console.WriteLine("\n클라이언트 프로세스들이 모두 완료되어 종료합니다.");
    }
}

// 스트림에서 문자열을 읽고 쓰기 위한 데이터 프로토콜을 정의하는 클래스
// (이 클래스는 서버 예제와 동일합니다)
public class StreamString
{
    private Stream ioStream;           // 기본 스트림 (NamedPipeClientStream)
    private UnicodeEncoding streamEncoding; // 문자열 인코딩 방식

    public StreamString(Stream ioStream)
    {
        this.ioStream = ioStream;
        streamEncoding = new UnicodeEncoding(); // UTF-16 인코딩 사용
    }

    // 스트림에서 문자열을 읽습니다.
    public string ReadString()
    {
        // 먼저 문자열의 길이를 2바이트로 읽습니다. (Big-endian 방식으로)
        int len;
        len = ioStream.ReadByte() * 256; // 첫 번째 바이트 (상위 8비트)
        len += ioStream.ReadByte();      // 두 번째 바이트 (하위 8비트)

        // 읽을 길이만큼의 바이트 배열을 생성합니다.
        var inBuffer = new byte[len];
        // 스트림에서 해당 길이만큼의 바이트를 읽어 버퍼에 채웁니다.
        ioStream.Read(inBuffer, 0, len);

        // 바이트 배열을 문자열로 디코딩하여 반환합니다.
        return streamEncoding.GetString(inBuffer);
    }

    // 스트림에 문자열을 씁니다.
    public int WriteString(string outString)
    {
        // 문자열을 바이트 배열로 인코딩합니다.
        byte[] outBuffer = streamEncoding.GetBytes(outString);
        int len = outBuffer.Length;

        // 문자열 길이가 UInt16.MaxValue (65535)를 초과하면 잘라냅니다.
        // (프로토콜이 2바이트 길이 필드를 사용하므로 최대 65535 바이트까지 표현 가능)
        if (len > UInt16.MaxValue)
        {
            len = (int)UInt16.MaxValue;
        }

        // 문자열의 길이를 2바이트로 스트림에 씁니다. (Big-endian 방식으로)
        ioStream.WriteByte((byte)(len / 256)); // 상위 바이트
        ioStream.WriteByte((byte)(len & 255)); // 하위 바이트
        // 문자열 바이트 배열을 스트림에 씁니다.
        ioStream.Write(outBuffer, 0, len);
        // 버퍼에 남아있는 데이터를 즉시 스트림으로 밀어 넣습니다.
        ioStream.Flush();

        // 전송된 총 바이트 수 (문자열 바이트 + 길이 2바이트)를 반환합니다.
        return outBuffer.Length + 2;
    }
}

강력한 프로그래밍: Named Pipe 클라이언트/서버 설정

이 예제에서 클라이언트와 서버 프로세스는 동일한 컴퓨터에서 실행되도록 설계되었습니다.

그래서 NamedPipeClientStream 객체에 제공된 서버 이름이 “.” 입니다.

만약 클라이언트와 서버 프로세스가 다른 컴퓨터에 있다면, “.” 은 서버 프로세스를 실행하는 컴퓨터의 네트워크 이름으로 대체되어야 합니다.

추가 정리

명명된 파이프에 대한 동작 개념

명명된 파이프는 파일 시스템의 ‘이름’이라는 개념을 빌려와 프로세스들이 서로를 찾아 연결할 수 있게 해주지만, 실제 데이터 교환은 메모리를 통해 이루어지는 IPC(프로세스 간 통신) 메커니즘입니다.

이러한 특성 덕분에 명명된 파이프는 로컬 컴퓨터 내의 여러 프로세스 간 통신에 매우 효율적이며, Windows에서는 네트워크를 통해 다른 컴퓨터의 파이프에도 연결할 수 있어 더욱 유연하게 사용할 수 있습니다.

The post .NET의 파이프 작업 (Pipe Operations in .NET) appeared first on 어제와 내일의 나 그 사이의 이야기.

Connecting server and clients

Netcode for Entities 1.5.0v

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/manual/creating-multiplayer-gameplay.html

서버와 클라이언트 연결

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/manual/network-connection.html

Netcode for Entities는 연결을 관리하기 위해 Unity Transport 패키지를 사용하며, 각 연결을 하나의 엔티티로 저장합니다.

이 엔티티는 NetworkStreamConnection 컴포넌트를 가지며, 연결에 사용된 Transport 핸들을 포함합니다.

연결이 종료되면(서버가 유저 연결을 끊거나 클라이언트가 요청한 경우) 이 엔티티는 삭제됩니다.

명령 수신 대상 설정

[AutoCommandTarget feature]를 사용하지 않거나 더 세밀한 제어가 필요한 경우, CommandTarget을 설정해야 합니다.

이 설정은 클라이언트에서 받은 명령을 저장할 엔티티를 지정합니다.

이 엔티티 참조를 최신 상태로 유지하는 것은 게임 개발자의 책임입니다.

게임 상태 진입

게임은 NetworkStreamInGame 컴포넌트를 연결 엔티티에 수동으로 추가해야 합니다. 이 작업은 자동으로 이루어지지 않습니다.

이 컴포넌트가 추가되기 전에는 클라이언트가 명령을 전송하지 않으며, 서버도 스냅샷을 전송하지 않습니다.

연결 해제 요청

연결을 해제하려면 해당 엔티티에 NetworkStreamRequestDisconnect 컴포넌트를 추가하세요.

Transport 드라이버를 통한 직접적인 연결 해제는 지원되지 않습니다.

수신 버퍼 (Incoming Buffers)

각 연결은 최대 3개의 수신 버퍼를 가질 수 있습니다:

• 명령: IncomingRpcDataStreamBuffer
• RPC: IncomingCommandDataStreamBuffer
• 스냅샷 (클라이언트 전용): IncomingSnapshotDataStreamBuffer

서버에서 클라이언트로 스냅샷이 전송되면 버퍼에 저장되고 나중에 GhostReceiveSystem에 의해 처리됩니다.

RPC 및 명령도 동일한 방식으로 NetworkStreamReceiveSystem이 수집하고, 이후 각각의 시스템이 처리합니다.

서버는 IncomingSnapshotDataStreamBuffer를 가지지 않습니다.

송신 버퍼 (Outgoing Buffers)

각 연결은 최대 2개의 송신 버퍼를 가질 수 있습니다:

• 명령 (클라이언트 전용): OutgoingRpcDataStreamBuffer
• RPC: OutgoingRpcDataStreamBuffer

생성된 명령은 먼저 송신 버퍼에 저장되고, 클라이언트가 매 틱마다 이 버퍼를 전송합니다.

RPC도 마찬가지로 해당 송신 시스템이 버퍼에 인코딩하고, RpcSystem이 이를 묶어 MTU 단위로 전송합니다.

연결 흐름 (Connection flow)

Netcode는 게임 시작 시 자동으로 서버 또는 클라이언트 연결을 설정하지 않습니다.

기본적으로 ClientServerBootstrap는 클라이언트와 서버 월드만 생성합니다.

연결 채널을 여는 방식은 개발자가 결정합니다.

선택 가능한 방법:

• 1⃣ NetworkStreamDriver를 사용하여 직접 Connect 또는 Listen 호출
• 2⃣ AutoConnectPort 및 DefaultConnectAddress 설정
• NetworkStreamRequestConnect 및 NetworkStreamRequestListen 요청 엔티티 생성

주의

연결 중에는 반드시 Application.runInBackground = true로 설정해야 하며, 그렇지 않으면 포커스를 잃었을 때 연결이 끊길 수 있습니다.

1⃣ 수동 연결 / 리스닝 (Manually listen or connect )

NetworkStreamDriver 싱글톤을 사용해 Connect 또는 Listen 메서드를 호출합니다.

코드 예시는 DOTS samples repository 참고

        public void StartClientServer(string sceneName)
        {
            Debug.Log($"[StartClientServer] Called with '{sceneName}'.");
            if (ClientServerBootstrap.RequestedPlayType != ClientServerBootstrap.PlayType.ClientAndServer)
            {
                Debug.LogError($"Creating client/server worlds is not allowed if playmode is set to {ClientServerBootstrap.RequestedPlayType}");
                return;
            }

            var server = ClientServerBootstrap.CreateServerWorld("ServerWorld");
            var client = ClientServerBootstrap.CreateClientWorld("ClientWorld");

            SceneManager.LoadScene("FrontendHUD");

            //Destroy the local simulation world to avoid the game scene to be loaded into it
            //This prevent rendering (rendering from multiple world with presentation is not greatly supported)
            //and other issues.
            DestroyLocalSimulationWorld();
            if (World.DefaultGameObjectInjectionWorld == null)
                World.DefaultGameObjectInjectionWorld = server;
            SceneManager.LoadSceneAsync(sceneName, LoadSceneMode.Additive);

            var port = ParsePortOrDefault(Port.text);

            NetworkEndpoint ep = NetworkEndpoint.AnyIpv4.WithPort(port);
            {
                using var drvQuery = server.EntityManager.CreateEntityQuery(ComponentType.ReadWrite<NetworkStreamDriver>());
                drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.RequireConnectionApproval = sceneName.Contains("ConnectionApproval", StringComparison.OrdinalIgnoreCase);
                drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.Listen(ep);
            }

            ep = NetworkEndpoint.LoopbackIpv4.WithPort(port);
            {
                using var drvQuery = client.EntityManager.CreateEntityQuery(ComponentType.ReadWrite<NetworkStreamDriver>());
                drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.Connect(client.EntityManager, ep);
            }
        }

2⃣ AutoConnectPort 사용 (Using the AutoConnectPort)

ClientServerBootstrap AutoConnectPort필드에는 서버와 클라이언트가 처음 설정될 때 각각 자동으로 수신하고 연결하도록 지시하는 데 사용할 수 있는 두 가지 특수 속성이 포함되어 있습니다.

• DefaultConnectAddress
• DefaultListenAddress

public class AutoConnectBootstrap : ClientServerBootstrap
{
    public override bool Initialize(string defaultWorldName)
    {
        AutoConnectPort = 7979;
        CreateDefaultClientServerWorlds();
        return true;
    }
}

서버는 와일드카드 주소(DefaultListenAddress:AutoConnectPort)에서 리슨을 시작합니다.

DefaultConnectAddress는 기본적으로 NetworkEndpoint.AnyIpv4로 설정되어 있습니다.

클라이언트는 서버 주소(DefaultConnectAddress:AutoConnectPort)로 연결을 시작하며, 이 DefaultConnectAddress는 기본적으로 NetworkEndpoint.Loopback으로 설정되어 있습니다.

참고:

에디터에서는 PlayMode 도구를 사용해 AutoConnectAddress와 AutoConnectPort 값을 오버라이드할 수 있습니다.

그러나 AutoConnectPort를 0으로 설정한 경우에는 PlayMode 도구의 오버라이드 기능이 작동하지 않으며, 이 경우 수동으로 연결을 트리거해야 합니다.

3⃣ NetworkStreamRequest로 연결 흐름 제어

NetworkStreamDriver에서 직접 메서드를 호출하는 대신, 다음과 같은 싱글톤을 생성하여 연결 흐름을 제어할 수 있습니다:

• NetworkStreamRequestConnect singleton : 원하는 서버 주소/포트로 연결을 요청할 때 사용합니다.
• NetworkStreamRequestListen singleton : 서버가 원하는 주소/포트에서 리슨을 시작하도록 요청할 때 사용합니다.

// 클라이언트 월드에서, NetworkStreamRequestConnect가 있는 새 엔티티 생성
// 이 엔티티는 이후 NetworkStreamReceiveSystem에 의해 처리됩니다.
var connectRequest = clientWorld.EntityManager.CreateEntity(typeof(NetworkStreamRequestConnect));
EntityManager.SetComponentData(connectRequest, new NetworkStreamRequestConnect { Endpoint = serverEndPoint });

// 서버 월드에서, NetworkStreamRequestListen이 있는 새 엔티티 생성
// 이 엔티티도 마찬가지로 NetworkStreamReceiveSystem에 의해 처리됩니다.
var listenRequest = serverWorld.EntityManager.CreateEntity(typeof(NetworkStreamRequestListen));
EntityManager.SetComponentData(listenRequest, new NetworkStreamRequestListen { Endpoint = serverEndPoint });

이러한 요청은 런타임에 NetworkStreamReceiveSystem에 의해 소비되어 실제 연결 동작을 수행합니다.

참고 :

실행 중 오류가 발생하면 PlayMode Tools 창을 열고 다시 Play Mode로 진입해 보세요.

만약 월드가 이미 존재한다면, 부트스트랩 코드(위 설명 참조)에 의해 자동으로 월드가 생성되고 있을 가능성이 큽니다.

서버가 이미 리슨 중이거나 클라이언트가 이미 연결 중이라면, 자동 연결 기능이 이미 활성화되어 있는 것입니다.

이 경우 수동 연결 방식을 사용하려면 부트스트랩 코드에서 자동 연결을 비활성화해야 합니다.

4⃣ Network simulator

Unity Transport는 SimulatorUtility를 제공합니다.

이 도구는 Netcode for Entities 패키지에 포함되어 있으며, 에디터 내에서 다음 경로를 통해 접근하고 설정할 수 있습니다:

Multiplayer > PlayMode Tools

실제 네트워크 상황을 보다 현실적으로 반영하기 위해, 시뮬레이터를 활성화한 상태로 자주 게임플레이를 테스트해보는 것이 좋습니다.

클라이언트 연결 이벤트 수신

NetworkStreamDriver 싱글톤을 통해 제공되는 ConnectionEventsForTick (형식: NativeArray<NetCodeConnectionEvent>.ReadOnly) 컬렉션을 사용하여,

클라이언트 및 서버에서 클라이언트 연결 이벤트를 반복(iterate)하면서 반응할 수 있습니다.

이 이벤트는 오직 단일 SimulationSystemGroup 틱 동안만 존재하며, 각각 NetworkStreamConnectSystem과 NetworkStreamListenSystem에서 초기화됩니다.

시스템이 위 시스템들의 job 이후에 실행되면, 같은 틱에서 발생한 이벤트를 수신하게 됩니다.

반면, 그 이전에 컬렉션을 조회하면 이전 틱의 값들을 반복하게 됩니다.

// 예제 시스템
[UpdateAfter(typeof(NetworkReceiveSystemGroup))]
[BurstCompile]
public partial struct NetCodeConnectionEventListener : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        var connectionEventsForClient = SystemAPI.GetSingleton<NetworkStreamDriver>().ConnectionEventsForTick;
        foreach (var evt in connectionEventsForClient)
        {
            UnityEngine.Debug.Log($"[{state.WorldUnmanaged.Name}] {evt.ToFixedString()}!");
        }
    }
}

주의 :

서버는 고정된 델타 타임으로 실행되기 때문에, SimulationSystemGroup은 각 렌더 프레임마다 0번 이상 실행될 수 있습니다.

따라서 ConnectionEventsForTick은 반드시 SimulationSystemGroup 내에서 실행되는 시스템 안에서만 읽어야 합니다.

예를 들어 InitializationSystemGroup, PresentationSystemGroup, 또는 어떤 MonoBehaviour 메서드 내에서 접근하면 다음과 같은 문제가 발생할 수 있습니다:

b) 시뮬레이션이 이 프레임에서 실행되지 않을 경우, 이벤트를 중복 수신

a) 이전 틱 이벤트를 놓치고 현재 틱만 받음

1⃣ NetCodeConnectionEvents on the client

주의 :

클라이언트는 다른 클라이언트의 이벤트를 수신하지 않습니다. 클라이언트 월드에서 발생한 이벤트는 자신의 클라이언트에 대한 이벤트뿐입니다.

Handshake 및 Approval 단계는 실패할 수 있으며, ClientServerTickRate.HandshakeApprovalTimeoutMS (기본값: 5000ms)의 타임아웃을 가집니다.

2⃣ NetCodeConnectionEvents on the server

주의 :

서버는 바인딩 성공이나 리스닝 시작에 대한 이벤트는 발생시키지 않습니다. 기존 API를 통해 상태를 확인해야 합니다.

Connection approval

서버에서 각 클라이언트 연결에 대해 승인을 요구하도록 설정할 수 있습니다.

연결 승인은 다음과 같은 목적으로 사용됩니다:

• 플레이어 편의성: 화이트리스트 / 블랙리스트, 비밀번호 보호된 서버 등
• 보안 검증: 매치메이킹 응답으로 받은 시크릿 토큰을 사용하여, 매치메이킹된 플레이어만 서버에 입장하도록 제한

연결 승인이 활성화되면 다음과 같은 변경이 발생 :

1. 클라이언트는 Handshake 및 Approval 단계에서만 IApprovalRpcCommand 형식의 RPC를 서버에 전송할 수 있습니다.
2. 모든 클라이언트는 Handshake 상태에서 곧바로 Connected로 넘어가는 것이 아니라 Approval 상태로 이동합니다.
3. 서버는 연결된 각 클라이언트의 엔티티에 ConnectionApproved 컴포넌트를 직접 추가해야만 승인됩니다.
4. NetworkId는 승인 성공 이후에만 할당됩니다. 승인에 실패하면 클라이언트는 연결이 끊어집니다.
5. 승인 과정에는 타임아웃이 존재합니다 (ClientServerTickRate.HandshakeApprovalTimeoutMS 참조, 기본값: 5000ms)

다시 강조하면:

• Handshake 및 Approval 단계 동안, 클라이언트는 여러 개의 RPC 메시지를 보낼 수 있습니다.
• 단, 이들 모두 IApprovalRpcCommand 타입이어야 합니다.
• 이 RPC의 payload에는 인증 토큰, 플레이어 정보 등 클라이언트의 유효성을 검증하기 위한 모든 정보를 담을 수 있습니다.
• 서버는 ConnectionApproved 컴포넌트를 클라이언트의 연결 엔티티에 추가함으로써 연결을 승인합니다. 이후 연결 흐름이 계속 진행됩니다.

NetworkStreamDriver에는 RequireConnectionApproval 필드가 있으며, 클라이언트와 서버 모두에서 true로 설정해야 연결 승인 흐름이 올바르게 작동합니다.

if (isServer)
{
    using var drvQuery = server.EntityManager.CreateEntityQuery(ComponentType.ReadWrite<NetworkStreamDriver>());
    drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.RequireConnectionApproval = true;
    drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.Listen(ep);
}
else
{
    using var drvQuery = client.EntityManager.CreateEntityQuery(ComponentType.ReadWrite<NetworkStreamDriver>());
    drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.RequireConnectionApproval = true;
    drvQuery.GetSingletonRW<NetworkStreamDriver>().ValueRW.Connect(client.EntityManager, ep);
}

연결 승인 처리도 다음과 같이 설정할 수 있습니다 :

// The approval RPC, here it contains a hypothetical payload the server will validate
public struct ApprovalFlow : IApprovalRpcCommand
{
    public FixedString512Bytes Payload;
}

// This is used to indicate we've already sent an approval RPC and don't need to do so again
public struct ApprovalStarted : IComponentData
{
}

[WorldSystemFilter(WorldSystemFilterFlags.ClientSimulation | WorldSystemFilterFlags.ThinClientSimulation)]
public partial struct ClientConnectionApprovalSystem : ISystem
{
    public void OnCreate(ref SystemState state)
    {
        state.RequireForUpdate<RpcCollection>();
    }

    public void OnUpdate(ref SystemState state)
    {
        var ecb = new EntityCommandBuffer(Allocator.Temp);
        // Check connections which have not yet fully connected and send connection approval message
        foreach (var (connection, entity) in SystemAPI.Query<RefRW<NetworkStreamConnection>>().WithNone<NetworkId>().WithNone<ApprovalStarted>().WithEntityAccess())
        {
            var sendApprovalMsg = ecb.CreateEntity();
            ecb.AddComponent(sendApprovalMsg, new ApprovalFlow { Payload = "ABC" });
            ecb.AddComponent<SendRpcCommandRequest>(sendApprovalMsg);

            ecb.AddComponent<ApprovalStarted>(entity);
        }
        ecb.Playback(state.EntityManager);
    }
}

[WorldSystemFilter(WorldSystemFilterFlags.ServerSimulation)]
public partial struct ServerConnectionApprovalSystem : ISystem
{
    public void OnUpdate(ref SystemState state)
    {
        var ecb = new EntityCommandBuffer(Allocator.Temp);
        // Check connections which have not yet fully connected and send connection approval message
        foreach (var (receiveRpc, approvalMsg, entity) in SystemAPI.Query<RefRO<ReceiveRpcCommandRequest>,RefRW<ApprovalFlow>>().WithEntityAccess())
        {
            var connectionEntity = receiveRpc.ValueRO.SourceConnection;
            if (approvalMsg.ValueRO.Payload.Equals("ABC"))
            {
                ecb.AddComponent<ConnectionApproved>(connectionEntity);

                // Destroy RPC message
                ecb.DestroyEntity(entity);
            }
            else
            {
                // Failed approval messages should be disconnected
                ecb.AddComponent<NetworkStreamRequestDisconnect>(connectionEntity);
            }
        }
        ecb.Playback(state.EntityManager);
    }
}

연결 확인 Sample 코드

https://discussions.unity.com/t/lobby-relay-and-netcode-for-entities/1538817/8

WorldManager.cs

using System.Diagnostics.CodeAnalysis;
using Unity.Entities;

namespace Managers 
{
    public static class WorldManager 
    {
        private static World _clientWorld, _serverWorld;
		
        [SuppressMessage("ReSharper", "ForeachCanBePartlyConvertedToQueryUsingAnotherGetEnumerator")]
        public static void DestroyLocalSimulationWorld() {
            foreach (var world in World.All) {
                if (world.Flags != WorldFlags.Game) continue;
                world.Dispose();
                break;
            }
        }
		
        public static void RegisterServerWorld(World world) => _serverWorld = world;
        public static void RegisterClientWorld(World world) => _clientWorld = world;

        public static World GetServerWorld() => _serverWorld;
        public static World GetClientWorld() => _clientWorld;
    }
}

RelayServerDataHelper.cs

using System;
using System.Collections.Generic;
using System.Linq;
using Unity.Networking.Transport;
using Unity.Networking.Transport.Relay;
using Unity.Services.Relay.Models;

namespace Extension 
{
    public static class RelayServerDataHelper 
    {
        private static RelayServerData GetRelayData(List<RelayServerEndpoint> endpoints, byte[] allocationIdBytes, byte[] connectionDataBytes, byte[] hostConnectionDataBytes, byte[] keyBytes) 
        {
            
            var endpoint = endpoints.FirstOrDefault(e => e.ConnectionType == "dtls") ?? throw new InvalidOperationException($"Endpoint for connectionType dtls not found");
            
            var server = NetworkEndpoint.Parse(endpoint.Host, (ushort)endpoint.Port);
    
            var allocationId = RelayAllocationId.FromByteArray(allocationIdBytes);
            var connData = RelayConnectionData.FromByteArray(connectionDataBytes);
            var hostData = RelayConnectionData.FromByteArray(hostConnectionDataBytes);
            var key = RelayHMACKey.FromByteArray(keyBytes);

            return new RelayServerData(ref server, 0, ref allocationId, ref connData, ref hostData, ref key, true); 
        }

        public static RelayServerData RelayData(JoinAllocation a) => GetRelayData(a.ServerEndpoints, a.AllocationIdBytes, a.ConnectionData, a.HostConnectionData, a.Key);

        public static RelayServerData RelayData(Allocation a) => GetRelayData(a.ServerEndpoints, a.AllocationIdBytes, a.ConnectionData, a.ConnectionData, a.Key);
    }
}

RelayInitializer.cs

using System;
using System.Collections;
using System.Threading.Tasks;
using Unity.Entities;
using Unity.NetCode;
using Unity.Networking.Transport;
using Unity.Networking.Transport.Relay;
using Unity.Services.Authentication;
using Unity.Services.Core;
using Unity.Services.Relay;
using UnityEngine;
using Extension;

namespace Managers 
{
    public class RelayInitializer : MonoBehaviour 
    {
        private static RelayServerData? _relayServerData, _relayClientData;
        private static Action OnConnectionComplete;
        public static string _joinCode;
    
        // Singleton (without duplicate destroy logic) for access to the class instance from within the static methods
        private static RelayInitializer Instance { get; set; }
        protected void Awake() => Instance = this;
        
        // HOSTING

        public static void StartHost() => Instance.StartCoroutine(InitializeHost());

        private static IEnumerator InitializeHost() 
        {
            var initializeTask = UnityServices.InitializeAsync();
            while (!initializeTask.IsCompleted)
                yield return null;
            if (ProcessTaskFail(initializeTask, nameof(initializeTask)))
                yield break;

            var signInTask = Task.CompletedTask;
            if (!AuthenticationService.Instance.IsSignedIn) {
                signInTask = AuthenticationService.Instance.SignInAnonymouslyAsync();
                while (!signInTask.IsCompleted)
                    yield return null; 
            }
            
            if (ProcessTaskFail(signInTask, nameof(signInTask)))
                yield break;

            var allocationTask = RelayService.Instance.CreateAllocationAsync(5);
            
            while (!allocationTask.IsCompleted)
                yield return null;
            
            if (ProcessTaskFail(allocationTask, nameof(allocationTask)))
                yield break;

            var joinCodeTask = RelayService.Instance.GetJoinCodeAsync(allocationTask.Result.AllocationId);
            
            while (!joinCodeTask.IsCompleted)
                yield return null;
            
            if (ProcessTaskFail(joinCodeTask, nameof(joinCodeTask)))
                yield break;

            _joinCode = joinCodeTask.Result;

            try 
            {
                Debug.Log("Hosting relay data");
                _relayServerData = RelayServerDataHelper.RelayData(allocationTask.Result);
            } catch (Exception e) {
                Debug.LogException(e);
                _relayServerData = null;
                yield break;
            }

            Debug.Log("Success, players may now connect");
            while (_relayServerData == null || (!_relayServerData?.Endpoint.IsValid ?? false))
                yield return null;
                
            yield return JoinUsingCode(_joinCode);
            yield return WaitRelayConnection();
            SetupRelayHostedServerAndConnect();
        }

        private static void SetupRelayHostedServerAndConnect() 
        {
            if (ClientServerBootstrap.RequestedPlayType != ClientServerBootstrap.PlayType.ClientAndServer) 
            {
                UnityEngine.Debug.LogError($"Creating client/server worlds is not allowed if playmode is set to {ClientServerBootstrap.RequestedPlayType}");
                return;
            }

            var relayServerData = _relayServerData.GetValueOrDefault();
            var relayClientData = _relayClientData.GetValueOrDefault();

            var oldConstructor = NetworkStreamReceiveSystem.DriverConstructor;
            NetworkStreamReceiveSystem.DriverConstructor = new RelayDriverConstructor(relayServerData, relayClientData);
            var server = ClientServerBootstrap.CreateServerWorld("ServerWorld");
            WorldManager.RegisterServerWorld(server);
            var client = ClientServerBootstrap.CreateClientWorld("ClientWorld");
            WorldManager.RegisterClientWorld(client);
            NetworkStreamReceiveSystem.DriverConstructor = oldConstructor;

            

            WorldManager.DestroyLocalSimulationWorld();
            World.DefaultGameObjectInjectionWorld ??= server;

            // Load scene here if you want to.
            
            Debug.Log(_joinCode);

            var networkStreamEntity = server.EntityManager.CreateEntity(ComponentType.ReadWrite<NetworkStreamRequestListen>());
            server.EntityManager.SetName(networkStreamEntity, "NetworkStreamRequestListen");
            server.EntityManager.SetComponentData(networkStreamEntity,
                new NetworkStreamRequestListen { Endpoint = NetworkEndpoint.AnyIpv4 });

            networkStreamEntity =
                client.EntityManager.CreateEntity(ComponentType.ReadWrite<NetworkStreamRequestConnect>());
            client.EntityManager.SetName(networkStreamEntity, "NetworkStreamRequestConnect");
            client.EntityManager.SetComponentData(networkStreamEntity,
                new NetworkStreamRequestConnect { Endpoint = relayClientData.Endpoint });
            
            ProcessConnectionComplete();
        }

        // CONNECTING
    
        public static void ConnectByCode(string joinCode) => Instance.StartCoroutine(ProcessCodeConnection(joinCode));
    
        private static IEnumerator ProcessCodeConnection(string joinCode) 
        {
            Instance.StartCoroutine(JoinExternalServer(joinCode));
            yield return WaitRelayConnection();
            ConnectToRelayServer();
        }

        private static IEnumerator WaitRelayConnection() {
            while (_relayClientData == null || (!_relayClientData?.Endpoint.IsValid ?? false))
                yield return null;
        }
        
        private static IEnumerator JoinExternalServer(string joinCode) {
            Debug.Log("Waiting for relay response");
            var setupTask = UnityServices.InitializeAsync();

            while (!setupTask.IsCompleted)
                yield return null;
            
            var signInTask = Task.CompletedTask;
            if (!AuthenticationService.Instance.IsSignedIn) {
                signInTask = AuthenticationService.Instance.SignInAnonymouslyAsync();
                while (!signInTask.IsCompleted)
                    yield return null;
            }
            if (ProcessTaskFail(signInTask, nameof(signInTask)))
                yield break;

            yield return JoinUsingCode(joinCode);
        }

        private static IEnumerator JoinUsingCode(string joinCode) 
        {
            // Send the join request to the Relay service
            var joinTask = RelayService.Instance.JoinAllocationAsync(joinCode);
            while (!joinTask.IsCompleted)
                yield return null;
            
            if (ProcessTaskFail(joinTask, nameof(joinTask)))
                yield break;
            
            // Format the server data, based on desired connectionType
            try {
                _relayClientData = RelayServerDataHelper.RelayData(joinTask.Result);
            } catch (Exception e) 
            {
                Debug.LogException(e);
                _relayClientData = null;
            }

            _joinCode = joinCode;
        }
    
        private static void ConnectToRelayServer() 
        {
            var relayClientData = _relayClientData.GetValueOrDefault();
            
            var oldConstructor = NetworkStreamReceiveSystem.DriverConstructor;
            NetworkStreamReceiveSystem.DriverConstructor = new RelayDriverConstructor(new RelayServerData(), relayClientData);
            var client = ClientServerBootstrap.CreateClientWorld("ClientWorld");
            WorldManager.RegisterClientWorld(client);
            NetworkStreamReceiveSystem.DriverConstructor = oldConstructor;

            WorldManager.DestroyLocalSimulationWorld();
            World.DefaultGameObjectInjectionWorld ??= client;
        
            var networkStreamEntity =
                client.EntityManager.CreateEntity(ComponentType.ReadWrite<NetworkStreamRequestConnect>());
            client.EntityManager.SetName(networkStreamEntity, "NetworkStreamRequestConnect");
            client.EntityManager.SetComponentData(networkStreamEntity,
                new NetworkStreamRequestConnect { Endpoint = relayClientData.Endpoint });
            ProcessConnectionComplete();
        }

        // COMMON
    
        private static bool ProcessTaskFail(Task task, string taskName) {
            if (!task.IsFaulted) return false;
            Debug.LogError($"Task {taskName} failed.");
            Debug.LogException(task.Exception);
            return true;
        }

        public static void SubscribeToConnectionComplete(Action handler) => OnConnectionComplete += handler;

        public static void ProcessConnectionComplete() {
            if (OnConnectionComplete == null)
                return;
            OnConnectionComplete?.Invoke();
            foreach (var handler in OnConnectionComplete?.GetInvocationList()!)
                OnConnectionComplete -= (Action)handler;
        }
    }

    public class RelayDriverConstructor : INetworkStreamDriverConstructor 
    {
        private RelayServerData _relayServerData, _relayClientData;
    
        public RelayDriverConstructor(RelayServerData serverData, RelayServerData clientData) {
            _relayServerData = serverData;
            _relayClientData = clientData;
        }

        public void CreateClientDriver(World world, ref NetworkDriverStore driverStore, NetDebug netDebug) {
            var settings = DefaultDriverBuilder.GetNetworkSettings();
            settings.WithRelayParameters(ref _relayClientData);
            DefaultDriverBuilder.RegisterClientDriver(world, ref driverStore, netDebug, settings);
        }

        public void CreateServerDriver(World world, ref NetworkDriverStore driverStore, NetDebug netDebug) =>
            DefaultDriverBuilder.RegisterServerDriver(world, ref driverStore, netDebug, ref _relayServerData);
    }
}

The post Unity Netcode for Entities – Connecting server and clients appeared first on 어제와 내일의 나 그 사이의 이야기.

Client / Server worlds Setting

Netcode for Entities 1.5.0v

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/manual/set-up-client-server-worlds.html

Netcode for Entities의 네트워킹 모델을 사용하여client 와 server를 설정합니다.

클라이언트 / 서버 World 네트워크 모델

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/manual/client-server-worlds.html

Netcode for Entities는 Client와 Server의 로직을 각각 Client world와 Server world로 분리하여 처리합니다.

월드(World)는 Unity의 ECS(Entity Component System) 개념으로, 엔티티와 시스템을 시스템 그룹(SystemGroup)으로 구성한 단위입니다.

기본적인 Client / Server 월드 외에도, 개발 중에 게임을 테스트할 수 있도록 씬 클라이언트(Thin Client) 기능도 지원합니다.

시스템 생성 및 업데이트 구성

기본적으로, 모든 시스템은 클라이언트/서버 월드의 SimulationSystemGroup에서 생성되고 업데이트됩니다.

하지만 특정 시스템을 클라이언트에만, 또는 서버에만 작동하게 만들고 싶을 때는 다음 두 가지 방법을 사용할 수 있습니다

1⃣ 특정 시스템 그룹에 할당하기

시스템이 속할 시스템 그룹을 지정하면, 그 시스템 그룹이 존재하지 않는 월드에서는 자동으로 필터링됩니다.

[UpdateInGroup(typeof(GhostInputSystemGroup))]
public class MyInputSystem : SystemBase
{
  ...
}

참고:

PresentationSystemGroup에 속한 시스템은 클라이언트 월드에서만 작동합니다.

Server / Thin client worlds에는 이 시스템 그룹이 생성되지 않기 때문입니다.

2⃣ WorldSystemFilter 사용

시스템이 어떤 월드에서 작동할지 더 세부적으로 설정하고 싶다면 WorldSystemFilter 속성을 사용하세요.

// WorldSystemFilterFlags 옵션 
// - LocalSimulation: 오프라인 로컬 시뮬레이션 (Netcode 시스템 없음)
// - ServerSimulation: 서버 시뮬레이션
// - ClientSimulation: 클라이언트 시뮬레이션
// - ThinClientSimulation: 씬 클라이언트
// 속성을 지정하지 않으면, 기본적으로 시스템은 상위 그룹의 필터링 규칙을 따릅니다 (WorldSystemFilterFlags.Default)

[WorldSystemFilter(WorldSystemFilterFlags.ClientSimulation)]
public class MySystem : SystemBase
{
  ...
}

Client / Server worlds with bootstrapping

Netcode for Entities를 프로젝트에 추가하면, 기본 ClientServerBootstrap 클래스가 제공됩니다.

이 클래스는 게임 시작 시 클라이언트 및 서버 월드를 자동 생성합니다

public virtual bool Initialize(string defaultWorldName)
{
    CreateDefaultClientServerWorlds();
    return true;
}

자동 부트스트래핑은 에디터에서 Play 모드 진입 시 매우 유용합니다.

하지만, 실제 게임에서는 메인 메뉴와 같은 전처리 과정이 필요하므로 월드 생성을 지연시키거나 수동 제어할 필요가 있습니다.

예를 들어

• “클라이언트-호스트 서버 실행” → 서버와 클라이언트 모두 생성
• “전용 서버에 접속” → 클라이언트만 생성

0⃣ Bootstrapping 커스터 마이징

기본 ClientServerBootstrap을 상속하여 원하는 방식으로 월드 생성을 제어할 수 있습니다

public class MyGameSpecificBootstrap : ClientServerBootstrap
{
    public override bool Initialize(string defaultWorldName)
    {
        // Netcode 없이 로컬 시뮬레이션 월드만 생성
        CreateLocalWorld(defaultWorldName);
        return true;
    }
}

버튼 클릭 등의 타이밍에 다음을 호출하여 월드 생성:

var clientWorld = ClientServerBootstrap.CreateClientWorld();
var serverWorld = ClientServerBootstrap.CreateServerWorld();

AutomaticThinClientWorldsUtility.NumThinClientsRequested = 10;
AutomaticThinClientWorldsUtility.BootstrapThinClientWorlds();

ClientServerBootstrap.CreateDefaultClientServerWorlds();

Netcode Sample https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/NetcodeSamples/README.md

Client / Server 업데이트 주기

Netcode for Entities를 사용할 때, 서버는 항상 Fixed Timestep으로 업데이트됩니다.

이는 클라이언트 예측을 위한 기본적인 결정론 수준을 보장하고(엄격한 결정론은 아니지만), 물리 시스템의 안정성과 프레임 레이트 독립성을 보장하기 위함입니다.

또한 이 패키지는 프레임당 최대 Fixed Step 반복 횟수를 제한하여 서버가 단일 프레임을 시뮬레이션하는 데 몇 초가 걸리는 상태에 빠지지 않도록 합니다.

중요한 점은 서버의 고정 업데이트가 표준 Unity 업데이트 빈도 또 Unity 물리 시스템의 Fixed Timestep를 사용하지 않는다는 것입니다.

대신 자체적인 ClientServerTickRate.SimulationTickRate 를 사용합니다. – 고정된 틱(tick) 간격

(이것은 Unity.Physics가 사용 중이라면 정수 배수여야 합니다. ClientServerTickRate.PredictedFixedStepSimulationTickRatio를 참조하세요)

그러나 클라이언트는 동적 타임스텝으로 업데이트됩니다.

예측 코드만 예외로, 이는 항상 서버와 동일한 고정 타임스텝으로 실행되어 두 시뮬레이션 간의 결정론적 관계를 유지하려고 합니다.

전체 틱과 동기화되지 않은 리프레시 레이트에 대한 예측 처리 방법을 이해하려면 부분 틱을 참조하세요.

설정 예시:

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/api/Unity.NetCode.ClientServerTickRate.html

class MyCustomClientServerBootstrap : ClientServerBootstrap
{
   override public void Initialize(string defaultWorld)
   {
       base.Initialise(defaultWorld);
       var customTickRate = new ClientServerTickRate();
       //run at 30hz
       customTickRate.simulationTickRate = 30;
       customTickRate.ResolveDefault();
       foreach(var world in World.All)
       {
           if(world.IsServer())
           {
              // 이 경우 서버에서만 생성되지만 클라이언트 세계에서도 동일한 작업을 수행할 수 있습니다
              var tickRateEntity = world.EntityManager.CreateSingleton(new ClientServerTickRate
              {
                  SimulationTickRate = 30;
              });
           }
       }
   }
}


// SimulationTickRate = 초당 몇 번의 시뮬레이션 틱을 실행할지 설정합니다. 기본값은 초당 60 틱입니다.
// NetworkTickRate = 서버가 클라이언트에게 스냅샷(snapshot)을 전송하는 빈도를 설정합니다. 기본값은 SimulationTickRate와 동일합니다.

성능 문제 방지

서버가 설정된 시뮬레이션 틱 레이트보다 느린 속도로 업데이트될 경우, 한 프레임에서 여러 개의 시뮬레이션 틱을 처리하려고 시도합니다.

예를 들어, 서버의 마지막 업데이트가 16ms가 아닌 50ms가 걸렸다면, 서버는 다음 프레임에서 이를 따라잡기 위해 약 3번의 시뮬레이션 스텝을 실행합니다 (16ms × 3 ≈ 50ms).

이러한 동작은 성능 저하를 악화시키는 악순환을 유발할 수 있습니다:

서버는 더 많은 시뮬레이션 스텝을 처리해야 하므로 점점 더 느려지고, 그 결과 틱 간격을 더 많이 놓치게 됩니다.

위와 같은 상황을 방지하기 위해 ClientServerTickRate에서는 다음과 같은 설정을 제공합니다

• MaxSimulationStepsPerFrame
  서버가 한 프레임 내에 수행할 수 있는 최대 시뮬레이션 스텝 수를 제한합니다.
• MaxSimulationStepBatchSize
  여러 틱을 하나의 배치(batch) 로 묶어 처리하도록 지시합니다.
  이때는 델타 타임(delta time)을 곱한 값으로 단일 스텝을 실행합니다.
  예: 2개의 스텝을 실행하는 대신, 1개의 스텝만 실행하되 델타 타임을 2배로 설정하여 처리합니다.

주의:
MaxSimulationStepBatchSize 에 의한 배칭 처리는 특정 조건에서만 작동하며, 자체적인 제한 사항이 있습니다.
게임 로직에서 “한 시뮬레이션 스텝 = 하나의 틱“이라고 가정하지 않도록 하며, TimeData.DeltaTime 값을 하드코딩하지 마십시오.
배칭이 발생하면 서버와 클라이언트 간의 시뮬레이션 정밀도가 달라져 예측 오류가 발생할 수 있습니다.

프레임 속도 유지 방식 설정

서버가 유휴 상태일 때 프레임 속도를 어떻게 유지할지도 설정할 수 있습니다.

TargetFrameRateMode는 서버가 틱 레이트를 유지하기 위한 유휴 시간 소비 방식을 제어합니다.

• BusyWait
  가능한 한 빠른 속도로 계속 실행 (CPU 사용량 높음)
• Sleep
Application.targetFrameRate에 맞춰 대기하여 CPU 부하를 줄임
• Auto
  헤드리스(콘솔 없는) 서버에서는 Sleep을 사용하고, 그 외에는 BusyWait을 사용

월드 마이그레이션 (World Migration)

현재 사용 중인 월드를 파괴(destroy) 하고, 연결 상태를 유지한 채로 새로운 월드로 전환하고자 할 경우, DriverMigrationSystem을 사용할 수 있습니다.

이 시스템은 네트워크 전송(transport) 관련 정보를 저장 및 불러올 수 있게 해주며, 매끄러운 월드 전환을 가능하게 합니다.

public World MigrateWorld(World sourceWorld)
{
    DriverMigrationSystem migrationSystem = default;
    foreach (var world in World.All)
    {
        if ((migrationSystem = world.GetExistingSystem<DriverMigrationSystem>()) != null)
            break;
    }

    var ticket = migrationSystem.StoreWorld(sourceWorld);
    sourceWorld.Dispose();

    var newWorld = migrationSystem.LoadWorld(ticket);

    // NOTE: LoadWorld는 반드시 새 월드에 필요한 시스템을 추가하기 전에 호출해야 합니다!
    // 이유: LoadWorld는 NetworkStreamReceiveSystem이 올바른 드라이버를 불러오기 위해 필요한 
    // `MigrationTicket` 컴포넌트를 생성하기 때문입니다.

    return ClientServerBootstrap.CreateServerWorld(DefaultWorld, newWorld.Name, newWorld);
}

이 기능은 예를 들어 로비에서 인게임으로 넘어가거나, 씬을 바꾸면서도 연결을 유지해야 하는 경우에 매우 유용합니다.

Additional resources

• Entities overview
• Thin clients
• Introduction to prediction

네트워크 프로토콜 검사

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/manual/network-protocol-checks.html

클라이언트가 서버에 연결할 때, Netcode 프로토콜 버전(NetworkProtocolVersion) 을 주고받습니다.

이 프로토콜에는 다음과 같은 정보가 포함되어 있습니다:

• Netcode 버전 (netcode version)
• 게임 버전 (game version)
• RPC 컬렉션 (RPC collection)
• 직렬화된 컴포넌트 컬렉션 (erialized component collections)

서로 호환되지 않는 게임 버전 간의 연결을 사전에 차단하여 예측할 수 없는 동작을 방지합니다.

RPC 컬렉션은 모든 로드된 어셈블리에서 컴파일된 RPC들의 타입과 멤버를 기반으로 해시를 계산합니다.

Serialized Component 컬렉션 역시 Netcode for Entities가 수집한 고스트(Ghost) 컴포넌트를 기반으로 해시를 계산합니다.

이러한 타입 정보와 멤버들을 기반으로 계산된 해시값이 프로토콜의 일부로 사용됩니다.

Netcode for Entities는 기본적으로 이 해시값이 완전히 동일해야 통신이 가능하도록 설정되어 있습니다.

이렇게 하면 중간에 예외가 발생하는 것을 방지하고, 대역폭 최적화가 가능합니다.

개발 중 발생할 수 있는 문제

개발 중에는 호환 가능한 빌드조차도 이 검사 때문에 부적합한 버전으로 잘못 판단되는 경우가 있습니다.

예를 들어:

• 독립 실행형 빌드와 Unity Editor에서 실행 중인 월드를 연결하려는 경우
• Editor는 테스트용 어셈블리를 포함하고 있는데, 빌드에는 포함되어 있지 않을 경우
• 이로 인해 해시가 일치하지 않아 연결이 끊어짐

이러한 엄격한 프로토콜 검사는 개발 중 테스트에 방해가 될 수 있으므로, 비활성화할 수 있습니다.

이 프로토콜 버전 오류가 발생하면 각 피어는 사용자 코드가 읽을 수 있는 를 통해 원격 피어와의 연결을 끊고 

NetworkStreamDisconnectReason.BadProtocolVersion, 이를 사용하여 플레이어에게 해당 빌드가 대상 원격 피어와 호환되지 않음을 알립니다.

개발 빌드에서는 패키지가 로컬 피어에 로드된 RPC 및 고스트 유형의 전체 목록과 정렬된 목록을 나타내는 오류 로그도 출력합니다.

유형 불일치 문제를 해결하려면 이러한 로그를 원격 피어에서 발생한 로그와 상호 참조하세요.

프로토콜 검사 해제

검사를 비활성화하려면, 다음과 같이 RpcCollection.DynamicAssemblyList를 true로 설정합니다:

[BurstCompile] // 선택 사항
[WorldSystemFilter(WorldSystemFilterFlags.ClientSimulation | WorldSystemFilterFlags.ServerSimulation | WorldSystemFilterFlags.ThinClientSimulation)]
[UpdateInGroup(typeof(InitializationSystemGroup))]
[CreateAfter(typeof(RpcSystem))]
public partial struct SetRpcSystemDynamicAssemblyListSystem : ISystem
{
    public void OnCreate(ref SystemState state)
    {
        SystemAPI.GetSingletonRW<RpcCollection>().ValueRW.DynamicAssemblyList = true;
        state.Enabled = false;
    }
}

주의:

이 설정은 RpcSystem.OnUpdate가 실행되기 전에 적용되어야 하며,

RpcSystem.OnCreate 이후에 설정되어야 합니다.

클라이언트와 서버 모두 이 플래그 값을 동일하게 설정해야 연결이 가능합니다. (값이 다르면 프로토콜 해석 방식이 달라지기 때문)

이 기능을 활성화하면 다음과 같은 단점이 있습니다:

• 각 RPC마다 6바이트의 오버헤드가 발생합니다 (ushort 인덱스 대신 해시값 전체를 전송)
• 게임 도중, 클라이언트가 알 수 없는 RPC나 고스트 타입을 수신하게 되면
  → 런타임 오류 발생 후 즉시 연결이 끊어짐
  → 즉, 연결 시점이 아닌 게임 중간에 강제 종료될 수 있습니다

따라서 이 설정은 개발 중 테스트 목적으로 사용하는 것이 좋으며, 출시용 빌드에서는 권장되지 않습니다.

Additional resources

• NetworkProtocolVersion API

The post Unity Netcode for Entities – Client / Server worlds appeared first on 어제와 내일의 나 그 사이의 이야기.

IInputComponentData

https://docs.unity3d.com/Packages/com.unity.netcode@1.5/api/Unity.NetCode.IInputComponentData.html

Netcode for Entities (NFE)에서 클라이언트의 입력을 서버로 전송하기 위해 특별히 설계된 인터페이스

IInputComponentData의 핵심 역할

1⃣ 입력 데이터의 네트워크 동기화

• 클라이언트 → 서버로의 입력 전송을 최적화합니다.
• NFE는 이 인터페이스가 붙은 컴포넌트를 자동으로 직렬화/역직렬화합니다.

2⃣ 예측(Prediction) 시스템 지원

• 클라이언트 측 예측과 서버 측 보정을 가능하게 합니다.
• GhostPredictionSystemGroup에서 특별 처리됩니다.

3⃣ 입력 버퍼링

• 틱(tick) 기반으로 입력을 저장해 네트워크 지연 보정에 사용됩니다.

예시 코드

using Unity.Entities;
using Unity.NetCode;

// 반드시 IInputComponentData를 상속해야 함
public struct NetcodePlayerInput : IInputComponentData
{
    // 필드에 [GhostField] 속성을 추가해 직렬화 옵션 지정
    [GhostField(Quantization = 100)] // 값 범위: -1.0 ~ 1.0 → -100 ~ 100으로 압축
    public float MoveX; // 좌우 이동 입력 (-1: 왼쪽, 1: 오른쪽)

    [GhostField]
    public float MoveY; // 전후 이동 입력

    [GhostField]
    public InputEvent Jump; // 점프 입력 (버튼 상태)

    // 현재 틱 정보 (NFE가 자동으로 주입)
    public uint Tick { get; set; }
}

[GhostField(Quantization = 100)] 양자화를 사용하는 이유

Netcode for Entities (NFE)에서 네트워크 대역폭을 최적화하기 위해 사용되는 핵심 기능

1⃣ 데이터 압축으로 대역폭 절감

• 원본 데이터: float (32비트)
• 양자화 후: short (16비트) 등 작은 타입으로 변환

[GhostField(Quantization = 100)] 
public float MoveX; // -1.0 ~ 1.0 → -100 ~ 100 정수로 압축
// 1.75f → 175 (전송) : 수신 측에서 1.75f로 복원

2⃣ 네트워크 지연 감소

작은 데이터 패킷으로 통신하여 전송 시간 단축하여 실시간 반응성 향상 (지연 시간 감소)

3⃣ 작동 원리

• 적정 범위: -1.0 ~ 1.0 (조이스틱 입력 등)
  • Quantization = 100 → -100 ~ +100 (총 201단계)
  • 필요 비트: ⌈log₂(201)⌉ = 8비트 (1바이트)
• 정밀도 vs 효율 트레이드오프:
  • 100: 0.01 단위 정밀도 (대부분의 게임 입력에 충분)
  • 1000: 0.001 단위 (고정밀 필요 시) → 대역폭 2배 소모

4⃣ 간단 적용 예시

// 캐릭터 이동
[GhostField(Quantization = 100)]
public float Horizontal; // 좌우 이동 (-1.0 ~ 1.0)

[GhostField(Quantization = 100)]
public float Vertical;   // 전후 이동

// 캐릭터 회전
[GhostField(Quantization = 32767)] // short.MaxValue
public float RotationY; // 0 ~ 360도 → -32767 ~ 32767

5⃣ 최적화 가이드

6⃣ 주의사항

• 오버플로우 방지
  Quantization 값을 너무 크게 설정하면 정수 변환 시 오버플로우 발생 가능:

// 위험 예시 (float.MaxValue → 양자화 시 오류)
[GhostField(Quantization = 1000000)] 
public float DangerValue;

• 정밀도 한계
  0.005f 같은 미세한 값은 Quantization=100에서 반올림 오차 발생:

0.005f * 100 = 0.5f → 반올림 → 1 → 복원 시 0.01f (100% 오차)

• 에디터 디버깅
  NetworkProtocol 로그에서 실제 전송 크기 확인:

// Unity 콘솔에 패킷 크기 출력
Debug.Log($"패킷 크기: {System.Runtime.InteropServices.Marshal.SizeOf(packet)}바이트");

7⃣ 성능비교

// 양자화 미적용 (32비트 float)
[GhostField] 
public float Uncompressed; // 4바이트

// 양자화 적용 (8비트 압축)
[GhostField(Quantization = 100)] 
public float Compressed; // 1바이트

절감 효과: 75% 대역폭 감소 (4배 효율)
초당 60프레임 기준:
미적용: 60fps * 4B = 240B/s
적용: 60fps * 1B = 60B/s

IInputComponentData 와 IComponentData의 차이점

특징	IInputComponentData	IComponentData
자동 직렬화	네트워크 전송 최적화	직접 구현 필요
예측 지원	PredictedGhost와 연동	별도 시스템 필요
틱 동기화	Tick 프로퍼티 자동 관리	수동 처리
버퍼링	입력 히스토리 유지	직접 구현

The post IInputComponentData [Netcode for Entities] appeared first on 어제와 내일의 나 그 사이의 이야기.

Tortoise SVN 설치 및 접속 + 간단한 용어 설명 + Unity

https://tortoisesvn.net/downloads.html

사이트에서 SVN을  다운로드 합니다.

리포지토리(Repository) 관리자가 주는 URL로 접속

리포지토리(Repository) 관리자가 설정한 개인 아이디와 비번으로 접속 후 업데이트를 해준다.

Unity 프로그램으로 협업을 할 경우 ignore 에서 항목을 추가하자

 ignore는 커밋 목록에서 제외하는 것을 의미

입력 후 저장

*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ *.rej *~ #*# .#* .*.swp .DS_Store [Tt]humbs.db obj Temp *.suo *.user *.pidb *.userprefs *.csproj *.pidb *.sln *.csproj *.unityproj Library Temp Logs UserSettings .vsconfig .vs obj *.log 

간단한 용어정리

https://fall-in-it.tistory.com/10 <- 참고

SVN (SubVersion) 

형상관리/소스관리 툴

프로젝트의 버전관리를 위해 Repository를 만들고 안에 소스를 저장하여 운용하는 소프트웨어입니다.

버전 관리 기능을 제공하여 프로젝트를 여러 사람이 함께 참여할때 프로젝트 소스코드의 공유, 
옛날 버전의 소스 코드 조회 소스 코드의 백업의 용도로 사용할수있다

– 체크아웃 : 저장소에 접근해 소스 코드와 버전관리를 위한 파일들을 받아 오는 행위

– 추가 : 말 그대로 파일을 서버에 올린다

– 커밋 : 내가 수정한 코드를 올린다

– 업데이트 : 최신 리버전된 버전의 코드를 받는다

Repository : 저장소

SVN 에서 저장소는 보통 Remote Repository(원격 저장소)를 의미한다.

즉, 서버에 올라가 있는 저장소로 소스뿐만이 아니라 소스의 변경 사항도 모두 저장되며

URL 이 있는 모든 사용자가 네트워크를 통해서 접근 할 수 있습니다. 

클라이언트, client

네트워크로 연결된 서버로부터 정보를 제공받는 컴퓨터.

Revision : 리비전

저장소에 올라가 있는 파일들의 버전이라고 표현 할 수 있다.

Revision 의 숫자는 소스 및 파일…등 을 수정하여 commit 하면 일정한 규칙에 의해 숫자가 증가합니다.

이 Revision 을 통해 롤백을 하거나 이전에 소스코드를 확인할 수 있다.

위와 같은 이유로 commit 시 어떤 변경사항들이 발생했는지 Commit Message 를 잘 작성해야 한다.

Revision 을 보고 프로젝트 진행 상황을 알 수 있습니다.

Subversion의 경우 파일별로 Revision 이 매겨지지 않고 한번 commit 한 것으로 전체 Revision 이 매겨집니다.

Trunk : 트렁크

해당 저장소의 중심이 된다는 의미이다.

아래의 그림을 참고하자.

Branch : 브랜치

브랜치는 트렁크와 마찬가지로 영어 단어의 뜻적으로 접근하면 나뭇가지를 뜻한다.

나뭇가지는 나무의 몸통에서부터 파생되어 나온다.

* 그렇다면 트렁크는 중심에서 전체적으로 에러가 없이 잘 돌아가는 소스코드이고

   브랜치는 그 트렁크에서 기능 추가, 수정을 하기 위해 가지로 뻗어 나와 있는 기둥에 영향을 안 주는 소스코드이다.

   나뭇가지를 자른다고(실제로는 그런 행동을 하면 안 됩니다!) 기둥이 죽지는 않는다.

그림으로 표현하면 위와 같다.

그래서 보통 개발할 때는 기반이 되는 Trunk 소스코드에서 기능 별로 혹은 메뉴 별로 혹은 카테고리 별로

(이건 프로젝트 내부 룰에 따라)

Branch 만들어서 개발하고 나중에 Trunk 에 합치는 식으로 개발을 진행한다.

Tag : 태그

태그는 여러 브랜치들이 모여서 만들어진 트렁크에 대해 어느 특정 지점을 기록하기 위한 꼬리표라고 생각하면 된다.

주로 상용 서비스에서는 Release 단위에 따라 태그를 붙이는 편이다.

Checkout : 체크아웃

체크아웃은 초기에 원격 저장소에서 작업을 하기 위해 소스코드를 내 PC 로 내려받는 것을 의미한다.

(Git 의 Clone 과 동일함)

Import : 임포트

임포트는 초기에 원격 저장소에 버전 관리할 소스 코드를 넣는 것을 의미한다.

Export : 익스포트

익스포트는 임포트와 반대로 원격 저장소에서 소스 코드를 가져오는 것을 의미한다.

체크아웃과 다른 점은 .svn 숨김 폴더는 제외한다는 것이다.

즉, 버전 관리 파일을 제외한 순수 소스 코드만 가져오는 것이다.

Commit : 커밋

커밋은 원격 저장소에 변경된 변경 사항들을 저장하는 것을 의미한다.

내 PC에서 아무리 열심히 해도 커밋을 안 한다면 아무 소용이 없다.

커밋을 하게 되면 저자(Author)와 커밋 메시지, 일자와 일시가 찍히고 리비전이 갱신된다.

Update : 업데이트

업데이트는 원격 저장소에서 다른 사람에 의해 변경된 소스 코드를 내 PC 에 반영하는 작업이다.

업데이트는 수시로 해주는 게 좋다. 

작업을 시작하기 전에, 커밋을 하기 전에는 필수로 해준다.

Revert : 리버트, 롤백

리버트는 내 PC 에서 수정했던 작업 내역을 되돌리는 작업이다.

파일 단위로 할 수도 있고 폴더 단위로 할 수도 있다.

Merge : 머지, 병합

머지는 내 브랜치와 다른 사람이 작업해 둔 브랜치를 합치는 작업이다.

업데이트 시에는 자동적으로 진행되는 작업이다.

Conflict : 컨플릭트, 충돌

가장 까다롭고 귀찮은 녀석이다..

일단 충돌이 나는 이유는 동일한 파일을 서로 다른 프로그래머가 개발할 경우 자주 발생한다.

충돌이 발생하면 하나하나 비교해가면서 병합을 해야 한다.. (손머지..)

사람이 하는 것이기에 휴먼에러가 발생할 가능성이 있고 그렇게 되면 개발됐던 소스 코드들을 날려버릴 수가 있다…

미연에 방지하기 위해서는 원격 저장소와 동일한 파일 상태에서 업데이틀 무조건 해주는 것이 정신건강에 이롭다..

Lock : 락

그래서 있는 것이 이 Lock(락) 이라는 것이다.

이 명령어를 파일에 걸어두면 락을 건 사용자만 해당 파일을 수정할 수 있다.

사용한 후에는 반드시 unlock 을 해주는 것을 잊지 말자.

Diff : 디프

Difference 의 약자이다.

현재 소스 코드 대비 특정 리비전의 소스 코드와 차이점을 볼 수 있다.

특정 리비전 2개의 차이점을 볼 수도 있다.

Add : 추가

원격 저장소에 커밋하기 위해 VCS 목록에 추가하는 것을 의미한다.

Ignore : 이그노어

Add 와는 반대로 커밋 목록에서 제외하는 것을 의미한다.

The post TortoiseSVN 설치 및 접속 + 간단한 용어 설명 + Unity ignore 설정 appeared first on 어제와 내일의 나 그 사이의 이야기.