메시지 프레이밍 방법의 장단점 .NET에서

Question

나는 알고있는 두 가지 다른 TCP 메시지 프레이밍 방법의 장점과 단점을보고 있습니다.

1. 구분 : TCP 스트림은 구분 기호 바이트를 사용하여 고정 길이가 아닌 메시지로 분리됩니다. 데이터를 전송할 때 루틴은 메시지 프레임의 안전한 전송을 보장하기 위해 분리 문자에 대한 메시지 데이터를 점검하고이를 제거해야합니다. 데이터를 수신 할 때 루틴은 프레임을 메시지로 분리하기 위해 분리 문자 바이트를 찾는 스트림을 읽어야합니다.

EG : 사용자 [이름] \ nPassword [비밀] \ n

1. 길이 프리픽스 다음 TCP 스트림은 소정의 크기의 메시지로 고장의 프리픽스를 사용하여 상태 4 바이트라고 메세지의 길이 데이터를 수신 할 때 루틴은 먼저 메시지 프레임의 길이를 결정하기 위해 접두어를 읽습니다. 데이터를 전송할 때 루틴은 전송하기 전에 메시지에 길이 접두어를 추가해야합니다.

는 EG : [MessageLength] 사용자 [이름] [MessageLength] 비밀번호 [비밀번호] 이러한 방법의

모두 크기가 다양 바이트의 스트림을 포함 할 수있는 메시지 프레임의 전송이 해석 될 수 있습니다. 상위 레벨 메시지 구조 또는 프로토콜은 관련이 없습니다.

---

그래서 저는 확장 성 및 성능 효율성에 중점을 둡니다. 벤치 마크 테스트를 실행해야 메시지 처리가 필요없이 가장 효율적인 처리량을 얻을 수있는 방법을 확인할 수 있습니다.

---

현재의 생각은 어떤 전문가도 아닙니다.

구분 된 메시지 프레임은 스트림의 각 바이트가 메시지 프레임 구분 기호가 있는지 확인해야하므로 수신 루틴 동안 효율성이 떨어집니다. 길이 - 접두사가 붙은 메시지 프레임은 항상 접두사 바이트를 읽고 나머지 메시지 프레임 스트림은 전체 메시지 프레임이 수신 될 때까지 처리하지 않고 곧바로 버퍼로 이동합니다.

길이 - 접두사가 붙은 메시지 프레임은 메시지 자체 앞에 전송되는 메시지 접두사로 보내기 루틴 중에 효율성이 떨어집니다. 내가 포함 할 수있다 생각할 수

---

다른 요인 : 작은 메시지 프레임의

• 많은 더 많은 패킷이 길이 - 접두사 구조 전송되는 초래할 것이다.
• 각 바이트가 구분 기호를 검사하기 위해 읽히지 않기 때문에 더 큰 메시지 프레임이 훨씬 효율적으로 길이 - 접두사 구조로 처리됩니다.

---

이 주제에 걸쳐 모든 빛이 좋지 않을까. TCP에 대한 메시지 프레임 구조의 차이점에 대해 좋은 자료를 찾는 것은 매우 어렵습니다.

Answer 1

접두사를 길이로 사용하는 것이 좋습니다. 메시지의 구문 분석 코드는 작성하기가 쉽습니다.

게다가 메시지 분리 문자를 사용하면 메시지 페이로드에 구분 문자가 포함될 수 있으므로 이스케이프 스키마를 찾아야합니다.

페이로드 불가지론자가 아닌 제 3의 계획이 나왔습니다. 이는 알려진 형식의 다른 메시지 유형을 정의하며 메시지의 다른 부분은 고정 길이 또는 가변 길이 일 수 있습니다. (간단한 유형 및 변수가 배열과 문자열 인 경우 고정됨). 이 구조는 미리 클라이언트와 서버간에 공유됩니다. 메시지를 보낼 때 메시지 유형 앞에 접두사가 붙습니다. 메시지 유형 번호에서받는 부분은 메시지 구문 분석 방법을 추론 할 수 있습니다.
예를 들어 LysKOM 메시징 시스템의 경우 protocol입니다.
이 프로토콜에는 파서 코드를 생성하는 데 사용할 수있는 공식 사양이 있습니다.