블로킹에 동기 방식일때는 보통 그냥 여러번 보내잖아?

헤더: 메시지 유형 / 바디 사이즈
바디: 보내는놈 / 받는놈 / 메시지

헤더는 다 int로 보내니까 4바이트
유저 아이디는 50바이트로 고정적으로 정함

이런 유형일때 채팅 메시지 보내면 5번 연속으로 보내잖아
메시지 유형 (4바이트)
바디 사이즈 (4바이트)
바디 보내는애 (50바이트)
바디 받는녀석 (50바이트)
바디 메시지 (메시지의 길이만큼이겠지)

처음 읽는거의 유형에 따라 뒤에건 각각 다르게 읽겠고
100바이트 빼서 남은게 메시지의 길이 바이트인거고

그래서 처음에 딱 4바이트 읽고 길이까지 4바이트 읽어
그래서 유형이 챚메시지 프로토콜이야.

그러면 다음 연속으로 3번 읽으면 킅나는거잖아.
왜냐면 저렇게 프로토콜 규약해논거니까

그래서 블로킹은 아예 read()에서 멈추니까
이런 형태로 설계를 보통 하잖아.


근데 논블럭에 비동기 방식으로 짜면 프로토콜 어떻게 짜?
아예 비동기소켓채널에 read() , write()를 걸어주잖아.
또 bytebuffer 미리 다이렉트로 만들고 그걸 쓰잖아.

그래서 jvm 쓰레드 풀에서 read가 계속 도는거고
그래서 요청이 오면 complete()나 fail() 둘중 하나를
콜백으로 쓰레드에서 실행되는거잖아.

결국 블로킹도 안되고 비동기면 위에 처럼 프로토콜 짜기 힘들지않음?

애초에 바이트 버퍼 하나 만들고 그걸 매개주면서
read()나 thread를 하는건데 말야..

이게 메시지 총 길이가 몇바이트인지도 모르고
그거 그걸 고정으로 하면 메모리 효율 구리잖아
클라별로 그러 만들어서 해주는건데..
이거 어떤식으로 관리해야하냐?

그리고 write의 경우도 여러번 보내면 읽을때 힘들거같은데 어떤식으로 설계해야함?

그냥 하나의 ByteBuffer에 모든걸 박고 하나만 보내냐?

맨앞 4바이트 빼서 int로 바꿔서 유형 체크
flip()으로 맨앞 다시 와서 4바이트 다시 빼면 길이 int
그 다음에 50바이트 빼면 보내는 애 String
그 다음 50바이트 빼서 받는 애 String
그 다음부터 끝까지 빼면 메시지 String

결굴 블로킹하곤 다르게 이렇게 하나씩만 보내야하냐?
쫌 현직 2년 이상 일한 장인없냐??

나좀 도와주라 머가리 안굴러간다 ㅠㅠ
한번도 안써본 기술 비동기라 설계 모르겠음