server framework

서버 프레임워크

크로스 플랫폼 기본 라이브러리 https://github.com/hujianzhe/util, 다운로드하여 BootServer 디렉터리에 배치

소개:
코드는 서비스 노드 시작 부트스트래핑, 작업 스케줄링 및 기본 모듈 설명만 구현하며 비즈니스 코드를 포함하지 않으며 순수 C로 구현됩니다. 일반적으로 동적 라이브러리로 컴파일되며 사용 기능 측면에서 극도로 제한됩니다. 이는 몇 가지 일반적인 공통 프로토콜 흐름을 구현하고 C++를 지원합니다. 20 스택리스 코루틴 확장은 C++가 프레임워크 계층을 오염시키고 동적 라이브러리 생성에 영향을 미치는 것을 방지하기 위해 순수 C 동적 라이브러리의 일부 코드에서 격리됩니다.
util의 코드는 타사 라이브러리 설치가 필요하지 않다는 점을 제외하고 크로스 플랫폼을 담당합니다.

운영 프로세스 소개:
비즈니스 프로세스는 코드로 컴파일된 동적 라이브러리를 호출하고 해당 인터페이스를 호출하여 사용합니다. 호출 프로세스에 대한 자세한 내용은 테스트 노드 예제를 참조하세요. (BootServer 디렉터리의 main_template은 프로세스 기반 시작 코드 템플릿 집합입니다.)
여러 스레드가 모듈 내부에서 네트워크 IO 읽기 및 쓰기를 처리합니다. 별도의 액세스 허용 스레드는 처음에 작업자 스레드를 열어 내부 메시지와 수신된 네트워크 메시지를 처리하고 이를 비즈니스 코드 로직으로 전달합니다.
작업자 스레드는 처리 예약을 위해 스택 코루틴을 사용합니다(스택리스 코루틴을 사용하지 않는 이유는 아래 참조).
작업자 스레드는 가장 높은 호환성을 유지하기 위해 기본적으로 스택 코루틴을 사용합니다. 또한 스택 코루틴과 스택 코루틴 프로세스가 공존할 수 있습니다.

모듈 소개 및 샘플 코드:
1. BootServer: 메인 코드 부분, 서비스 노드의 필수 초기화 및 운영
2. ServiceTemplate: 비즈니스 로직을 작성하는 데 사용되는 서비스 노드 코드 템플릿
3. SoTestClient, SoTestServer: 노드 테스트 및 일부 샘플 코드 작성
4. Cpp20-SoTestServer: 테스트 노드, 일부 샘플 코드 작성, main.cpp에서 C++20 스택리스 코루틴 활성화(util 라이브러리의 C++20 스택리스 코루틴 스케줄러 사용)

엮다:
Windows 직접 VS 컴파일
Linux/Mac OS X에서는 make debug / make release / make asan을 사용하세요.

시작하다:
서비스 노드 시작에 필요한 구성 파일을 편집하고(특정 형식은 첨부된 구성 파일 템플릿 참조) 각 노드에 구성 파일과 고유 ID, 로그 식별 이름, IP 및 포트 번호를 제공합니다.
Windows는 VS에서 직접 열리고 프로젝트는 시작 매개변수 <구성 파일>로 구성됩니다.
linux/mac 컴파일 후 sh run.sh <서비스 프로세스> <구성 파일>

몇 가지 설계 이유 및 통찰력:
Q: 스택리스 코루틴을 사용하지 않고 스택형 코루틴을 사용하는 이유는 무엇입니까?
A: 순수 C로 스택리스 코루틴을 구현하는 것은 쉽습니다(자세한 코드는 util 라이브러리에서 순수 C로 구현된 스택리스 코루틴 스케줄러를 참조하세요). -진입).(후자의 상황)은 매우 어렵습니다.
스택리스 코루틴을 원활하게 사용하려면 여전히 컴파일러 지원에 의존해야 합니다. 이는 C++20에서도 달성되었습니다. util 라이브러리에는 완전한 C++20 스택리스 코루틴 스케줄러 구현도 있습니다.

Q: 스택리스 코루틴이 이 확장 기능을 헤더 파일 형식으로 제공하는 이유는 무엇입니까?
A: 1. 스택리스 코루틴은 코드에 영향을 미치고 수많은 함수 서명 형식을 변경하기 때문입니다.
2. C에서 인식되지 않는 C++ 개체가 포함되어 있으며 동적 라이브러리를 성공적으로 내보낼 수 없습니다.
3. 헤더 파일 형태로 주어지며, 스택리스 코루틴의 활성화 권한을 애플리케이션 레이어에 넘겨주는 것이 순수 C 동적 라이브러리 부분을 오염 없이 처리하기 위해 현재 생각하는 방식입니다.

Q: 다른 스케줄러로 대체할 수 있나요?
A: 작업자 스레드의 스케줄러는 대체될 수 있습니다. 작업자 스레드는 스케줄러의 실행 캐리어로 설계되었습니다. 프레임워크 내 작업자 스레드와 네트워크 스레드 간의 상호 작용은 인터페이스 후크를 통한 스케줄링 동작에 해당할 수 있습니다.

Q: 다른 네트워크 라이브러리로 대체할 수 있나요?
A: 1. 현재는 다른 네트워크 라이브러리로 대체할 수 없지만 이 문제는 설계 초기에 고려되었습니다. 향후에는 해당 동작이 작업자 스레드와 유사하게 됩니다. 교체를 위해 후크가 제공됩니다.
2. 타사 네트워크 라이브러리가 많지만 초점은 다릅니다. 애플리케이션 개발에 사용되는 TCP, UDP 라이브러리도 있고, 전체 유니버스를 포함하려는 라이브러리도 있고, 애플리케이션 계층에서 전체 네트워크 프로토콜 스택을 구현하는 라이브러리도 있어서 사실 이 영역은 통일되어 있지 않습니다.
3. 향후 네트워크 라이브러리 세트가 표준에 포함되면 이를 교체하겠습니다.

Q: C++를 프레임워크로 사용하면 안 되는 이유는 무엇입니까?
A: 1. 이 코드 세트가 작성되었을 때 C++20은 아직 등장하지 않았습니다. 당시 상대적으로 가장 성숙한 코루틴 솔루션은 해당 플랫폼 시스템 API를 호출하여 C를 사용하여 수행할 수 있었습니다.
2. 이런 형태의 프레임워크로 구현해야 할 기능은 단단해졌고, 프로세스를 통해 리소스의 생명주기도 고체화됐다. 순수 C로 구현하면 충분하다. (이전에 C++로 구현한 버전도 있었고, 코드가 더 복잡해졌습니다)
3. 다른 모듈에서 동적 라이브러리를 호출하는 경우에도 C에서 인터페이스를 봉인해야 합니다.
4.C++로 내보낸 클래스는 전염성이 있으며 ABI는 통합되지 않습니다.

Q: 순수 C를 사용하여 비즈니스 계층을 계속 개발할 수 있습니까?
A: 고급 언어로 작성된 모듈에서 발생하는 비동기 프로세스 및 예외 작성으로 인해 리소스 소멸 시점이 불확실해지기 때문에 현재 순수 C를 사용하여 리소스를 수동으로 제어하는 ​​것은 극히 어렵기 때문에 권장하지 않습니다. 이러한 일을 처리하려면 상위 수준 언어를 사용해야 합니다. 예를 들어 C++를 사용하여 상위 수준 비즈니스 코드를 개발할 수 있으며 해당 RAII 메커니즘은 해당 리소스의 릴리스를 보장할 수 있습니다.

Q: 이전 프로젝트의 "콜백"을 "코루틴"으로 변환하려면 스케줄러 부분을 비즈니스 코드의 해당 콜포인트로 바꾸면 되나요?
A: 그다지 간단하지 않습니다. 첫 번째는 워크로드 문제입니다. 그리고 콜백 형식이든 코루틴 형식이든 이 기간 동안 변수의 수명 주기 동안 요청을 보내고 결과를 기다리는 것이 핵심입니다. 해결해야 하고 신중하게 고려해야 할 문제입니다. Raw 포인터라면 프로젝트에서 사용한 경우 거의 변환할 수 없다고 할 수 있습니다. std::shared_ptr과 같은 수단은 변수의 수명 주기를 연장하므로 "스택 코루틴" 버전으로 변환하는 것이 덜 어려워집니다. C++20 스택리스 코루틴으로 변환하려는 경우 작업량이 엄청납니다. 이는 프로젝트를 다시 작성하는 것과 같으므로(스택리스 코루틴에는 강력한 코드 침입이 있기 때문에) 오래된 프로젝트를 변환하지 않는 것이 좋습니다.

Q: 현재 코루틴을 다른 스레드로 마이그레이션하여 실행하는 것이 허용되지 않는 이유는 무엇입니까?
A: 코루틴 마이그레이션은 쉽게 할 수 있지만 제공되지 않는 이유는
1. 코루틴 간에 실행되는 작업은 불확실하므로 동일한 예약 스레드에서 io와 계산이 혼합될 수 있습니다.
2. 마이그레이션 후 동일한 코루틴 프로세스가 다른 스레드에서 실행될 수 있습니다. 이 경우 코드가 스레드 로컬 변수에 의존하지 않는지 확인해야 하지만 타사 라이브러리가 스레드 로컬 변수를 사용하지 않는지 확인할 수는 없습니다. .

Q: 컴파일하고 실행할 때 Asan이 충돌합니까?
A: 1. 프레임워크의 기본 스택 코루틴을 사용하는 경우 코드 문제는 아닙니다. 노드 구성 파일에서 스택 코루틴 스택 크기를 조정할 수 있습니다. (ASAN이 활성화되면 상대적으로 큰 스택 공간이 소비됩니다. 스택폭발 가능성이 있습니다)
2. ASAN은 Unix 환경에서 스택형 코루틴 API(ucontext)를 완전히 지원하지 않습니다. ucontext 코루틴 API가 util 코드에서 ASAN에 맞게 조정되었지만 여전히 ASAN에서 실행되는 데 문제가 없다는 것을 100% 보장할 수는 없습니다. 환경(아직까지는 너무 좋음)
3. 일부 최신 Linux 배포판에서 ASAN이 AddressSanitizer: DEADLYSIGNAL을 무한대로 출력하는 경우 sudo sysctl vm.mmap_rnd_bits=28을 조정하여 문제를 해결합니다.

할 일:
1. 자세한 문서를 작성할 시간이 정말 없습니다.
2. 스크립팅 언어로 비즈니스 로직 작성 지원 제공