서버에서 allocate로 지정한 바이트만큼 BYteBuffer 만들어서 read()하는거
이거 몇바이트로 넣어야함?
보내는곳에서 메시지 크기에 따라 크기가 재각각인데
만약 40바이트를 write()했는데
받는곳에서는 얼마로 올지 모르니 일단 크게 잡잖아
뭐 400만큼으로 근데 이거 넘는 크기 오면 죳대는거 아님??
안넘는거 오면 공간 남아서 효율 개쓰레기ㅣ인데..
물론 받으면 나중에 사라지는거긴 하지만
딱 정해진거 오는게 아니니까 똥 닦다만 느킴임
메시지 크기도 맥스량을 정해놓냐?
카톡은 메시지 존나 길게해도 쫘라리락 다 받던데
얘내는 애초에 그럼 크기 존나 크게 해둔거임?
메모리 손해를 본다고 해도??
아니면 얼마나 올지알고 대기를 까두나?
블로킹 방식써서 다음에 올 길이 아니까 걍 read걸어두나?
이거 몇바이트로 넣어야함?
보내는곳에서 메시지 크기에 따라 크기가 재각각인데
만약 40바이트를 write()했는데
받는곳에서는 얼마로 올지 모르니 일단 크게 잡잖아
뭐 400만큼으로 근데 이거 넘는 크기 오면 죳대는거 아님??
안넘는거 오면 공간 남아서 효율 개쓰레기ㅣ인데..
물론 받으면 나중에 사라지는거긴 하지만
딱 정해진거 오는게 아니니까 똥 닦다만 느킴임
메시지 크기도 맥스량을 정해놓냐?
카톡은 메시지 존나 길게해도 쫘라리락 다 받던데
얘내는 애초에 그럼 크기 존나 크게 해둔거임?
메모리 손해를 본다고 해도??
아니면 얼마나 올지알고 대기를 까두나?
블로킹 방식써서 다음에 올 길이 아니까 걍 read걸어두나?
한번에 받는것처럼 보이게 하는거지 나눠서 받아 - dc App
너 1G 보낸다고 받는쪽에서 한번만에 1G 받는다는더 아니잖아 - dc App
ㄴ 그럼 블로킹 방식이겠네 논블럭 비동기로는 절대 구현 불가능이니까
패킷 교환방식의 근본 이론부터 송수신자가 작은데이터를 나눠받는다는 건데 - dc App
하나의 프로토콜이 있을때 헤더,헤더,바디,바디 등이 있을때 이걸 각각 byte[]로 해서 write()를 4번해서 보내고 받는쪽에서는 그거 따다다닥 읽어서 다 모히면 합체하는지.. 이러면 저게 가능이지 어느 크기가 올지 아니까 근대 반대로 비동기 방식이염 바로 리턴되서 언제 뭐가 더 빨리갓지도 모르고 어느 크기인지도 구별이 힘들지
아니면 헤더헤더 바디바디가 있을때 이걸 하나의 byte[]에 몰아서 보낸다고 하면 어차피 맨앞 헤더는 int니까 4바이트 4바이트 읽으면되고 그 뒤로 몇개읽을지는 알아서 판단되니까 보낼때 저 byte[]로 한번만 write() 하는 밯법도 있고
여기서 블로킹이 왜나오는지 모르겠는데 패킷 송수신용 스레드 하나 더만들고 다이나믹 사이즈를 가질수있는 큐에 넣어서 작업처리하는 스래드는 공용큐에서 그때그때 빼오면 되지 - dc App
순서가 엉키는건 맞아. 그래서 순서 보장해줄려고 릴라이어블한 네트워크 프로토콜이 존재하는거고 - dc App
TCP UDP 검색해서 공부해봐 - dc App
ㄴ 그럼 너는 [헤더 4바이트] [헤더 4바이트] [바디 ?바이트] 있고 이 3가지가 하나의 프로토콜 완셍 형태인데 이때 너는 구현을 패킷이 3개로 나뉘니 write() , write() , write()해서 3번 쓰겠다는 소리야?
아니면 하나의 byte[]에 모든거 몰아두고 write() 한번만 하겠다는거야?
헤더에 바디 몇바이튼지 안적어줘? - dc App
두번째가 바디의 길이 첫범째는 메시지 유형
앞에 헤더 두개는 4바이트 + 4바히트 인거지 int니까 두번째 헤더가 바디 길이를 알고 바디가 여러개일때도 두범째로 파악함
??? 지금 통신 뭘로 하는데? 몇레벨 레이어 말하는거야? - dc App
OSI 7 계층 모델 알아? - dc App
tcp통신이고 NIO AsynchronousSocketChannelz 쓴다. 즉 논블럭 비동기 방식씀. 즉시 리턴되서 패킷 나눠서 보내는거로 설계하려면 헤더 맨앞에 패킷 순서까지 추가되야함. 받는쪽에서 무조건 순서 엉켜서 근데 한방에 보내면 끊어서 바이트 읽으니 좋긴함. 블로킹은 read() 함걸면 무조건 순서오니 패킷 나눠받는 한번만 받는 다 되는데
닌블럭 비동기로 하셔니까 쫌 빡세다
ㅇㅇ 근데 tcp는 4계층만 쓰는뎁쇼
tcp에서 이미 구현한 기능을 어퍼에서 다시 구현할 필요는 없다고 보는데. 바로바로 보내야할만큼 레이턴시가 중요한거야? - dc App
tcpip계층 이랑 osi랑 다른거야 osi가 tcp ip를 포함하는 개념이야 - dc App
내가 글내용을 제대로 안읽었었는데 400바이트를 미리 할당한다고 효율에 문제되지 않는다고 봐 요즘 iot기기도 메모리 1기가씩 달고나오는데 - dc App
ㄴ 자꾸 무슨 소리를 하는거임? 예를들어 보내는게 ChatMessage일수도 있고, AddUserMessage일수도 있는거잖아. 내가 만든 메시지의 하위 클래스들임 받은거 첫번쌔 헤더 유형이 어떤 메시지 형태인지 확인하고 두번째 길이는 바디가 몇개인지, 얼마만큼 읽을지 파악 가능한거임
챗 메시지는 [헤더][헤더][보내는애 아이디][받는애 아이디][메싲지] 이렇게 되는거고 뭐 다른 유형은 바디 하나만 줄수도 받는거일수도 이걸 패킷으로 구분하는거고 그걸 한방에 주냐 나눠서 주냐 write() read() 앱구현을 말하는건데 넌 뭐 계층 얘기를 해. 이미 tcp쓰고 있는데 4계층만 되고 자바에서 제공되는 소켓까지 쓰는데 ㅡ,.ㅡ
tcp가 연결되는 동안 송수신되는 패킷의 모든 순서가 보장되는건 알고있지? - dc App
넌 뭔 얘기 하는거야
ㄴ 비동기는 순서 엉킨다
write() 다섯번 때렸을때 뭐가 먼저 콜백되서 complete() 될지 모름. 받을땐 write()에서 먼저 콜백된 패킷 받게돼. 그래서 나눠서 보냇거면 패킷 맨앞에 순서가 필요하단거임
그러면 시퀀스정보도 헤더에 포함시켜.. - dc App
헤더1 , 바디, 바디 , 헤더2 이딴식으로 간단 소리임. 비동기가 무적의 자유도가 주어진 대신헤 설계가 빡세다?
그래서 헤더에 그 시퀀스 정보 포함시켜서까지 나눠서 보내는게 효율이 더 좋은거야?
ㅏ아니면 하나의 바이트에 몰아보매고 받는곳에서 정해진 바이트 길이 쪼개는게 좋은거야? 그게 궁금함거
그냥 동기전송하고 추상개념 위에서 완료 이벤트를 비동기로 받는게 제일좋지... - dc App
내가 블로킹 비동기 하는 이유가 안해본 방식이라서 해보는건데 설계할때가 블로킹할때보다 믾이 어려워서 내가 생각한 방법징에 머가 더 좋은 설계인지 모르겠음. 블로킹 동기 , 논블럭 동기 셀렉터 쓰는거 다 해봤음. 이번에 비동기 쓰는거라서 비동기의 설계는 이벤트 반응형이라 쫌 빡센거같음
아니면 한패킷에 다 들어갈 크기는 그냥 한방에 다보내고. 좀 큰거는 전용 채널 열어서 처음에 크기 헤더 보내고 나중에 오는 패킷은 시퀀스 헤더만 붙여도 되고 - dc App
그래 일단 만드는게 우선이니 그렇게 짜야겠다 슈발.. 지금 초고수급 고수도 아닌데 완벽히 짜봐야 뭐하겠냐 일단 만들어보고 더 좋은 방법 계속 추구하는거일 뿐이지
이런 비동기 설계문제를 해결할려고 만든 오픈소스 많으니까 참고해봐도 좋고 - dc App
ㄴ 일단 자바 제공해주는거 많이 써보고 익숙해지면 좆픈소스 활용해서 해야지 그럼 설계가 더 좋아질듯
알아보니 tcp로 400바이트 넘으면 좋은 상황 없다더라 400바이트 제한되서 한방으로 쏘는거까지는 괜찮은듯
allocation(400)으로 해서 read() 해두면 될거같다