서버에서 여러 유형의 연결 처리

Question

클라이언트가 하드웨어 시뮬레이션과 통신하고 기본 연결 유형을 시뮬레이션 할 수있는 서버를 개발 중입니다. 클라이언트가 처음 연결될 때 서버는 시뮬레이션 할 연결 유형을 알지 못합니다. 서버에 대한 클라이언트의 첫 번째 패킷은 특정 유형의 연결을 요청합니다.

서버는 일반적으로 다른 유형의 연결을 어떻게 처리합니까? 나는 모든 연결이 동일한 서버에서만 작업했습니다. "알 수없는 연결"클래스와 다른 연결 유형을 시뮬레이트하는 두 개의 다른 연결 클래스를 구현하기 시작했습니다. 연결 유형이 결정되면 알 수없는 연결은 해당 유형의 연결을 만들고 연결을 레지스트리에 등록한 다음 소켓 핸들을 새 연결로 전달합니다.

하나의 연결이 상태 시스템을 구현하는 것이 더 일반적이며, 각 유형은 상태로 표시되며 유형별 상태를 처리 할 다른 상태 시스템을 포함합니다. 고려할 가치가있는 대안 디자인이 있습니까?

[업데이트]
codenheim에 의해 제안을 구현하기 시작한 후, 나는 내 특정 문제에 대한보다 적게보다는 매력적인 솔루션이 할 몇 가지 디자인 요소를 깨달았다. 가장 큰 문제는 연결 유형에 관계없이 연결을 통해 수행 할 수있는 작업을 수행하기 전에 하드웨어 주소를 수신하는 연결을 기다려야한다는 것입니다. 청취 포트를 사용하여 연결 유형을 결정하면 각 연결 유형에서 하드웨어 주소를 수신하기위한 논리를 반복해야합니다. 또한 모든 연결 유형에 대해이 상태의 연결 목록을 보관해야합니다. 하드웨어 주소를 기다리는 모든 것이 본질적으로 동일합니다.

Answer 1

전통적인 방식은 고유 한 포트에서 각 프로토콜을 분리하는 것입니다. 이를 통해 각각의 포트에 바인딩하는 모듈러 프로토콜 핸들러를 작성하고 OS가이를 지원하면 프로토콜 이름 (예 : UNIX의 경우 inetd 및/etc/services)으로 포트를 등록 할 수 있습니다.

현재 디자인에서 서버는 초기 "노크"패킷을 처리해야합니다. 특정 측면이 마음에 들지 않고 (별개의 포트를 사용할 수없는 경우) knockd (포트 노킹) 방식을 사용할 수도 있습니다. knockd는 포트를 열기 전에 초기 노크 시퀀스를 처리합니다 (필터 규칙이 있지만 대신 프록시로 연결 가능). 보호받는 서비스는 그것에 대해 아무 것도 모릅니다. 하지만이 모든 일은 한 서버에서 다른 서버로 악수를 옮기는 것입니다. 고유 한 포트를 사용하면 핸드 셰이크를 없앨 수 있습니다.