You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Q: vector를 써서 알아서 할당하고 바이너리 파일 및 size()까지 알아서 할 수 있는 걸로 구현?
A: 바이너리 파일의 경우 1,0만 들어오는 bool 자료형 (bit) 라서 char로 할당을 하고 size()를 측정했을때 크기에 오차가 발생할 수 있습니다.
A: 위험성이 있을것으로 보임. entity로 오는 데이터가 바이너리형인지 아닌지를 구분할 수 있는 수단이 있다면 문제가 없을것 같습니다.
Q: 헤더 컨트롤로 처리할 수 있지 않을까?
A: 지금 구조에선 헤더 컨트롤로 완벽하진 않을것 같습니다. recv, send를 한번 호출하는 방식으로 하면 이벤트 처리 방식으로 데이터 무결성을 가진 처리가 안됩니다.
"application/octet-stream", "image/jpeg", "image/png" 등의 요청인 경우,
post에서 multipart/form-data가 Content-Type의 값
등등 이런 경우에서 내부적으로 바이너리 데이터라고 판단하고 처리한다고 합니다.
이때를 제외하고 바이너리로 들어온다면 "당신의 헤더가 잘못한거다" 라는 식으로 정책을 짜는것도 방안이지 않을까.
read/recv write/send 를 써서 데이터를 받는것 부터가 문제가 있는 방식이기도 하다(…) 는 결론을 발견함(!)
엄밀히 말하면 이벤트 기반의 경우, 처리하는 쪽과 받는 쪽 사이의 무결성을 보장해주지 않는다고 합니다.
한마디로 읽든 쓰든, 완전히 들어왔다고 판단이 설 때까지 계속 읽고 계속 보내야 확실하게 될 수 있습니다.
그래서 robust 방식의 입출력 함수로 구현이 되는게 필요합니다.
Q: chunked msg 말고도 한 번에 보내는 경우만 있는게 아니란 소리인가요?
정확히는 한번에 보내는 걸텐데 입출력 다중화로 인해서
"어라 다 안받아지네?" 혹은 "어라 다 못보냈네?"같은 상태가 됩니다.
이유: non-block 처리가 안하기 때문입니다.
커널에서 일처리를 하는 데 그 찰나에 순간에 여러 요소로 인해
원하는 만큼 아직 못읽었다거나
네트워크 속도로 인해 잘리거나
와 같이 문제가 생길 수 있고, 반대로 보내는 과정에서도 그런 문제가 생길 수 있습니다.
핵심은 둘중 뭘쓰든 둘을 반복적으로 돌려서 제대로 데이터를 수신 다할 때까지 생각을 해봐야 하며
chunked는 더 나아가서 그 밖에서 받은 데이터를 처리해보고 끝까지 안 왔으면 다시 확인해야 한다는 것입니다. => 다 못읽으면 다시 보내서 읽어드리는 로직이 필요하다.
원시적인 방식은 한번에 읽는 것도 chunked와 유사하게 작동하는 것 같습니다.
( 리턴값으로 계속 읽기를 시도하고 0나오면 전체 버퍼 합쳐서 전달해주는 방식)
chunked는 여기에 entity의 끝 부분인지를 확인하는 절차가 들어갑니다.
chunked에 대한 설명, 아이디어
"청크드도 확인해야하는거 바이너리도 같이 헤더 컨트롤로 빼버리시죠" << 이게 무슨뜻인가
content-type 값에 오는 친구들로 바이너리인지 아닌지를 구분해서 처리한다는 거 말한겁니다.
chunked를 구분하는게 content_length 나 chunked-encoding같은 헤더 오는것 처럼
"application/octet-stream", "image/jpeg", "image/png" " multipart/form-data "
이런 데이터가 만일 해당 헤더가 아니었는데
바이너리 파일이 와서 깨졌다? 혹은 서버에 문제가 생긴다? 그러면 try catch로 잘못된 헤더를 반환한다던지 하는식으로...
(읽기 쓰기 함수가 완벽하다는 전제 하에)
(WIP: 작성 중입니다. 수정할 내용, 추가 내용 있으면 직접 이 comment를 수정하시거나 comment 달아주세요)
Description
request, response entity 저장에 char * (캐릭터 포인터) 대신에 std::vector를 사용해서 구현하는 방향에 대한 논의 내용입니다.
The text was updated successfully, but these errors were encountered: