패드를 사용하거나 패드를 쓰지 않으려면 - 통신 프로토콜을 만듭니다.

Question

두 개의 응용 프로그램이 TCP/IP 스트림을 통해 통신하도록 프로토콜을 만들고 메시지의 헤더를 디자인하는 방법을 파악하고 있습니다. TCP 헤더를 초기 가이드로 사용하여 패딩이 필요한지 궁금합니다. 캐시를 처리 할 때 저장되는 데이터가 캐시 행에 맞는지 확인하여 검색 할 때 효율적으로 수행되도록합니다. 그러나 응용 프로그램이 바이트 스트림을 구문 분석하여 적합성을 확인하는 방법을 고려하여 헤더를 채우는 것이 타당한 지 이해할 수 없습니다.

예를 들어, 3 바이트 필드와 32 비트 정렬을위한 1 바이트 패딩 필드로 구성된 메시지 헤더를 보내려합니다. 그런 다음 메시지 데이터를 보내 드리겠습니다.

이 경우 수신기는 스트림에서 3 바이트를 가져 와서 패딩 바이트를 버립니다. 그런 다음 메시지 데이터를 읽기 시작합니다. 보시다시피, 그는 원하는대로 3 바이트와 메시지 데이터를 저장하지 않을 것입니다. 바이트 정렬의 전체 지점은 효율적인 방식으로 검색 될 수 있도록되어 있습니다. 하지만 리트리버가 패딩에 신경 쓰지 않는다면 어떻게 효율적으로 검색 할 수 있을까요?

패딩이없는 경우 검색자는 스트림에서 3 헤더 바이트를 가져 와서 데이터 바이트를 사용합니다. 리트리버는 원하는대로이 바이트를 저장하기 때문에 패딩이 수행되는지 여부가 중요합니다.

어쩌면 나는 패딩 포인트를 놓치고 있습니다.

이 게시물에서 질문을 추출하기가 약간 힘들지만, 내가 말한 것은 아마도 내 오해를 지적 할 수 있습니다.

여러분의 생각을 알려주세요.

감사합니다, 꼭 다음 메시지 본문의 단어 정렬이 어떤 소용이

Answer 1

경우 jbu, 패드 다른 뒤틀림을 방지하기 메시지. 대부분의 메시지가 적절한 강도의 기계어로 처리되면 패딩에 도움이됩니다.

메시지가 바이트 스트림 (예 : xml)이면 패딩 (padding)은 많은 장점을 제공하지 않습니다.

와이어 프로토콜을 실제로 설계하는 한 압축을 포함한 일반 텍스트 프로토콜 (머리글 포함)을 사용하는 것이 좋습니다.이 프로토콜은 수작업으로 디자인 한 바이너리 프로토콜보다 대역폭을 적게 사용합니다.

Answer 2

응용 프로그램이 바이트 스트림을 구문 분석하여 적합성을 확인하는 방법을 고려하여 헤더를 덧붙이는 것이 이해가되지 않습니다.

수신기 인 경우 프로토콜 드라이버 (예 : TCP 스택)에 버퍼 (예 : 바이트 배열)를 전달하고 "데이터가있을 때이 메시지를 나에게 알려주세요" .

I (응용 프로그램)이 가져 오는 데이터는 데이터가 들어있는 바이트 배열입니다. "캐스팅"과 같은 C 스타일의 트릭을 사용하면이 배열의 일부분을 단어 및 더블 단어 (마치 바이트가 아닌)처럼 처리 할 수 ​​있습니다. 적절한 정렬이 이루어 졌다면 (패딩이 필수).여기

는 바이트 버퍼 오프셋에서 DWORD 읽고 문장의 예 :

DWORD getDword(const byte* buffer) 
{ 
    //we want the DWORD which starts at byte-offset 8 
    buffer += 8; 
    //dereference as if it were pointing to a DWORD 
    //(this would fail on some machines if the pointer 
    //weren't pointing to a DWORD-aligned boundary) 
    return *((DWORD*)buffer); 
} 

여기서 인텔 조립체의 해당 함수의 단계; 당신은 시간이 지남에 따라 프로토콜을 확장하려는 경우 패딩을 고려

mov eax,DWORD PTR [esi+8] 

Answer 3

명인 이유이다 : 그것은 읽기, 별도의 바이트를 축적하는 것이 더 효율적인 하나의 연산 코드, 즉 데이터에 액세스 할 수있는 매우 효율적인 방법이다 있습니다. 패딩의 일부는 향후 할당을 위해 의도적으로 따로 설정할 수 있습니다.

패딩을 고려해야하는 또 다른 이유는 길이 필드에 몇 비트를 저장하는 것입니다. 나는. 항상 4의 배수 또는 8은 길이 필드에서 2 또는 3 비트를 저장합니다.

Answer 4

TCP에 패딩이있는 다른 좋은 이유 중 하나는 전용 네트워크 처리 하드웨어가 헤더에서 데이터를 쉽게 분리 할 수 ​​있도록 허용한다는 것입니다. 데이터는 항상 32 비트 경계에서 시작되므로 패킷이 라우팅 될 때 데이터에서 헤더를 분리하는 것이 더 쉽습니다.

Answer 5

3 바이트 헤더가 있고이를 4 바이트로 정렬하는 경우 사용되지 않는 바이트를 '향후 사용을 위해 예약 됨'으로 지정하고 비트가 0이어야합니다 (잘못된 형식의 메시지는 거부 함). 그것은 당신에게 약간의 확장 성을 남겨 둡니다. 또는 바이트를 버전 번호로 사용하도록 결정할 수도 있습니다. 처음에는 0으로 설정 한 다음 프로토콜에 호환되지 않는 변경 사항을 적용 할 때이 숫자를 증가시킵니다. 값을 '정의되지 않음'및 '상관 없음'으로 두지 마십시오. 그렇게 시작하면 절대 사용할 수 없게됩니다.