ㅆㅇㅆ 얘도 정말 이해 안 되긴 해.

분석을 해보자.

ㅎㅎ

다음과 같은 질문이 올라왔습니다.

질문자의 글을 보면,

"메시지 경계", "파싱"이라는 단어를 사용합니다.

메시지 경계가 뭘 의미하는지 모르겠습니다.

메시지를 왜 파싱해야 하는 지도 모르겠습니다.

아마 질문자가 관련 지식을 잘 몰라서 질문한 듯해 보이는군요.

프로토콜을 설계하는 단계 같아보여요.

"프로토콜을 만들려면 메시지 경계를 파싱해야 함"이라는 표현이 나오니까요.

글쓴이는 우선 send(), recv(), 프로토콜 설계를 간략히 알아보면 될 거 같아요.

그에 대한 지식이 부족하여 기술적으로 고민하는 듯해 보입니다.

1. send() 함수를 봅시다.

     ssize_t
     send(int s, const void *msg, size_t len, int flags);

이렇습니다. 보낼 메모리 주소 포인터 필요하고, 데이터 길이도 필요합니다.

4바이트의 데이터를 보낸다고하면 데이터 길이가 4.

2. recv() 함수를 봅시다.

     ssize_t
     read(int fd, void *buf, size_t nbytes);

이렇습니다. 버퍼 메모리 주소 포인터 필요하고, 데이터 길이도 필요합니다.

여기서 데이터 길이는 받을 데이터 길이입니다.

send에서 4바이트를 보냈는데, read에서 8바이트를 기다리면,

4바이트 받고 나머지 4바이트 받기 위해 무한정 기다립니다.

이것이 핵심입니다.

그래서 보내는 데이터 길이를 받는 측에서 알아야 합니다. 반드시.

어떻게 할까요?

글쓴이의 생각이 맞습니다.

다음에 보낼 데이터 길이를 보내주는 겁니다.

그래서

send로 다음에 보낼 데이터 길이를 미리 전송하는거죠.

recv에서 받으면 다음에 받을 데이터 길이를 알 수 있습니다.

그런데 문제가 있습니다. 바로 지금 보낸 데이터 길이를 알 수가 없지요.

ㅎㅎ

그래서 처음에 보내는 데이터에 다음에 보낼 메지지 길이를 보내주는데,

지금 보내는 데이터 길이를 8바이트로 고정합니다.

int32_t type; 4바이트

uint32_t len; 4바이트

이렇게 보내주면 되죠.

그러면 받는 측에서는 8바이트 만큼 받으면 됩니다.

앞전에서 len 길이를 전송했잖아요.

두번째 보낼 때에는 len 길이 만큼 데이터를 전송합니다.

받는 측에서 len 길이만큼 받으면 됩니다.

일반적으로,

첫번째 보내는 것을 헤더라 하고,

두번째 보내는 것을 바디라 합니다.

헤더 + 바디를 메시지라고 합니다.

1. 헤더 전송

송신측:

메모리를 통째로 보낸다고 보시면 됩니다.

메시지 헤더 고정 바이트, 예 8바이트

4바이트: 내용이 1이라고 합시다.

4바이트: 내용이 20 이라고 합니다.

수신측:

총 8바이트를 받았습니다.

첫번째 4바이트는 1

두번째 4바이트는 20입니다.

(아마도 글쓴이는 이러한 변환을 파싱이라고 표현했나봅니다.)

일반적으로 type에는 어떠한 명령(행동)을 숫자로 넣고

len는 다음에 보낼(수신자 입장에서는 받을) 데이터(바디) 크기를 의미합니다.

2. 바디 전송

송신측:

20바이트를 전송합니다. 내용은 글쎄요.. 20개의 문자라고 합시다. 문자열.

수신측:

20바이트를 수신합니다. 송신할 때 문자라고 하기로 했으니,

20바이트를 문자열로 변환하고 21바이트 부분에 '\0'을 추가해주면 됩니다.

---

위 글을 보면, 송신할 때 문자라고 하기로 했다는 표현 보이시죠?

약속, 규약 그걸 프로토콜이라고 하는 것입니다.

그러면

#define SEND_STRING 1

#define SEND_INTEGER 2

#define REPLY_STRING 11
#define REPLY_INTEGER 12

이런 식으로 type를 지정할 수 있겠죠.

이런 식으로 프로토콜을 설계하는 것입니다.

송신측에서 문자열을 전송하고,

수신측에서 그것을 받고 받았다고 REPLY_STRING을 송신측에 보내는 거죠.

이 예에서 REPLY_STRING는 헤더만 필요할 뿐 추가적인 데이터가 필요하지 않겠죠?

헤더의 len을 0으로 하면 됩니다.

REPLY_STRING를 받은 측에서는 if (len > 0)를 검사하여 참이라면 body를 len 길이만큼 받을 준비를 하고

거짓이라면 헤더를 받을 준비를 하는 거죠.

여기서 말하는 준비란 표현은 버퍼 준비 및 read(...) 함수 실행을 의미하는 것입니다.

버퍼는 과연 링버퍼가 유리할까?

아니오. 링버퍼를 쓸 필요가 전혀 없습니다.

헤더 크기가 sizeof (struct Header) 크기이고 여기서는 8바이트이므로

스택 버퍼를 사용하면 됩니다. 즉, 지역 변수 또는 전역 변수를 사용하면 된다는 말.

동적 메모리 할당 malloc가 필요없죠. 재사용 가능.

STRING은 가변이므로 스팩 버퍼 말고 힙 버퍼 즉, malloc로 버퍼를 할당하는 것이 좋습니다.

매번 malloc, free하느냐? 아니오.

malloc로 DEFAULT_SIZE로 할당해놓고,ㅇ

len > DEFAULT_SIZE 를 검사하여 참이면

DEFAULT_SIZE * 2 를 하시어 realloc로 사이즈 조정하면 됩니다.

(위키피디아 동적 배열을 알고리즘을 참고할 것.)

이것이 네트웍 통신의 일반적인 구성입니다.

---

참고로 ㅆㅇㅆ의 설명은 매우 추상적이고 틀린 설명입니다. 무지로 인하여, ㅆㅇㅆ이 잘못된 설명을 한 것이죠.

글쓴이에게 책에서 소켓 프로그래밍 편을 보시는 것을 권장합니다.

시스템 프로그래밍이나 네트워크 프로그래밍 책을 보시면 나오는 내용들입니다.

그리고 파싱할 필요가 없고, FSM을 사용할 필요도 없습니다.

struct 구조체를 통째로 보내고 받는 측에서 통째로 받아서 struct 구조체로 캐스팅하면 간편하게 해결됩니다.

다만, 아키텍처가 다를 경우 바이트 순서(byte order)에 주의해야 합니다.

다음의 함수에 대한 설명을 훑어보시길 권장.

     htonl, htons, ntohl, ntohs – convert values between host and network byte
     order

글쓴이 님께서 무슨 언어를 사용하는지는 모르겠으나,

소켓 프로그래밍은 거의 표준적이므로 언어가 달라도 방법이 비슷비슷합니다.

저는 c 기준으로 설명드린 것이고, 각 언어마다 그에 대응되는 함수 또는 방법이 있을터이니

잘 알아보시면 되겠습니다.