큐에서 데이터를 꺼내는 작업 자체가 여러 스레드가 동시에 들어가도 의미가 없거나 wsasend가 스레드 안전하지 않아서 그런건가요? recv도 그렇고 send도 그렇도 하나의 세션에 대한 본질적인 작업은 사실상 하나의 스레드만 수행할 수 있다고 이해하면 되는걸까요?(사실상 여러 스레드가 접근해도 실질적인 세션의 공유자원(버퍼 등등)에 대해 순차적으로 접근할 수 있으므로 )

최종적에서 Recv가 정상적으로 처리되는것보다 -1로 리턴되는경우가 대부분입니다. 코드를 다운받아서 해봐도 어떨때는 정상적으로 되다가 다시작동하면 -1이 리턴되길 반복합니다. 무엇이 문제일까요?

에러 발생 이유를 모르겠습니다.. 해결방안을 알 수 있을까요?

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]안녕하세요. 좋은 강의 감사합니다.   url 설계시 post는 저장 수정하고 get은 조회를 한다는 기본 개념을 잘 알게되었습니다.   그런데 실제로 실무에서 비지니스 로직을 조회할 때, 단순한 조회, 저장이 일어나는 경우는 거의 없다고 생각됩니다.   예를 들면 로그인 하는 상황이라고 가정했을 때 입니다. 1. 로그인 시도를 위해 아이디 패스워드 여부를 조회한다. 2. 아이디 패스워드가 일치한다면 로그인 히스토리 등 각종 정보성 테이블에 update를 한 후 로그인 처리를 한다.   이런 경우에 클라이언트에서 get api 호출 후 리턴 값을 받아서 post api로 저장을 한 후 후속 처리를 한다면 api를 여러번 호출하는 상황이 발생하게 됩니다.   아래 두가지 시나리오 중 어떤 방식이 최적인지 궁금합니다.   1. 로그인 api 한번 호출 ( get or post로 한번 던진 후 모두 처리 ) - 아이디/패스워드 일치 여부 확인 ( 조회 ) - 타 서버에 흩어진 회원 정보 조회 및 병합 ( 조회 ) - 각종 정보 업데이트 ( 수정 ) - 토큰 처리 등등   2. 로그인 api 여러번 호출 - GET 아이디/패스워드 일치 여부 확인 - SOAP 타 서버에 흩어진 회원 정보 조회 및 병합 - POST 각종 정보 업데이트 - POST 토큰 처리 등등   설명이 부족할 경우 댓글 주시면 더 자세히 설명해 보도록 하겠습니다. 감사합니다.

 강사님이 13분 쯤에 실행 하는 부분에서 똑같이 cmd창에     10명이 입장은되는데 클라에서 보낸 메세지를 서버가 받아서 BroadCast하는 부분이 계속 호출이 안되었었습니다.   거의 3시간동안 뭐가 문제지?? 하다가 찾은 부분이   Server > PacketHandler부분에서 C_chatHandler부분이     이렇게   ClientSession clientSession = new ClientSession(); 되어 있어서  if문에 걸려서 그냥 return 을 해버린거 같은데   인자에 받은 session을 new ClientSession()으로 하게되면    새로 "빈" 갓난아기의?? ClientSession을 다시 만들어 버리기때문에   ClientSession의 Room이 항상 비어있는 상태라  retrun 으로 끝내버리게 되어서   ServerSessionManager의 Register하는 부분에서   _onRecv를 한다음   어떤 행동을 할것인가 == _handler 부분에서 매핑해놓은 C_chatHandler가 호출 되기는 하지만   new ClientSession 때문에 if에 걸려서 바로 return 을 하게 되어서 클라에 뿌려줄 수가 없었다....   그래서 new ClientSession을 하면 안되고     여기서 이어서 받이온 session을 ClientSession으로 캐스팅을 하고    (안에 정보가 있으니까)   이어서 사용을 해야한다. 라고 이해를 했는데 어느정도 맞는 흐름일까요..??

영한님 께서 TCP는 이미 모두 구축되어 있고 데이터의 크기도 크고 무겁기 때문에 UDP를 손대서 사용하시라 하셨는데 이 전송계층에서 UDP와 TCP가 공존하는건가요? 아니면 TCP를 이용해 통신을 할때가 있는거고 UDP를 이용해 통신을 할때가 있는건가요? 그리고 UDP를 손대서 사용하시라 하셨는데 UDP에 관해서 손댈 점이 무엇인가요?

영한님이 예시에서 들어주신 회원 목록 조회 /read-member-list이런 방식으로 API 설계를 하면 안되는 이유가 무엇인가요?

안녕하세요. 제가 이해한게 맞는지 확신이 서지 않아 질문 남깁니다.   인프런 강의 동영상을 예로 들었을 때, - 사용자가 인프런에 로그인 후, 동영상을 시청하다가 02분24초에 동영상을 종료 > 다시 재생 시 > stateful : - 사용자가 종료한 시점이 서버에 저장되어 있고, 다시 동영상을 재생시켰을 때 서버에서 동영상 정보 및 종료 시점 등을 받아와 종료한 시점부터 재생- 서버 증설 시 : #A 서버에 사용자 종료한 시점이 저장되어 있을 경우, #B서버에서는 종료한 시점을 보내줄 수가 없다. > stateless : - 다시 동영상을 재생시켰을 때, 동영상 정보 및 동영상 종료 시점 등의 정보를 같이 서버에 보내서 종료한 시점부터 재생3) 서버 증설 시 : 요청 시 정보를 보내므로, 서버 증설 시 문제가 되지 않는다.간단하게 이렇게 정리를 했는데 맞는건지 모르겠네요^^;; 잘못 이해한 부분이 있다면 답변 부탁드리겠습니다 :)   감사합니다.

현재 2022 버젼인데   프로젝트 파일은 이경로 있구요 PacketGenerator를   들어가보면     현재 이런 상태입니다    그런데 속성에 들어가서   이런식으로 출력 경로를 바꾸어 주어도 강사님이 하신것처럼    bin 산하에 생성이 안됩니다 .. 메모장으로 Append이거도 똑같이 했는데두요 오히려 이런     이상한 파일이 더 생겨 버렸습니다 ㅠ

jobQueue 를 두는 이유가 기존에 thread 가 많아서 context-switching 비용이 더 비싸기 때문인가요?   thread 숫자가 줄어서 결국 context-switching 비용을 아끼고 그만큼 성능이 빨라지게 되는 건지요?

패킷 리시브 할 때 WSARecv의 작동에 의문이 생겨 질문을 남겨봅니다.   [Size][ID][Hello World] 라는 패킷을 수신하다고 가정해봤을 때 Session::ProcessRecv 가 호출된 시점에서    [Size][ID][Hello] 까지의 데이터를 받았다고 가정하면 PacketSession::OnRecv에서 dataSize가 header.size보다 작기 때문에 0바이트를 Return 해 버리고 끝납니다.   이러면 RecvBuffer의  _writePos,  _readPos에는 아무 변화 없이 다시 RegisterRecv를 걸어버리는데요   다음 RegisterRecv (WSARecv) 를 걸 때 , 읽다만 데이터의 시작 지점 부터 다시 읽어버리는게 아닌가 싶어서 여쭤봅니다   첫 번째 ProcessRecv를 받았을 때 RecvBuffer이 다음과 같다면   두 번째 ProcessRecv에서는 남은 "World" 데이터가 RecvBuffer 뒤쪽에 쌓이게 되는지,  아니면 변하지 않은 _writepos 위치 때문에 앞에서 부터 다시 작성되게 되는지 의문이 생겨 여쭤봅니다.   제 생각 중 만약 전체 바이트가 아닌 일부 바이트만 수신되는 위와 같은 과정에서 WSARecv는 2번 따로 따로 호출된다고 이해한게 맞으며, RecvBuffer에 문제없이 데이터가 이어서 들어가게 되나요?      

안녕하세요 다름이 아니라 제가  main.py 내용애서 db이름을 수정 안해주고 docker-compose up을 시킨뒤 원인을 알고 db 부분을 수정 해줬습니다. 그런 다음 실행을 시켜줬지만 "davedb"가 계속 없다고 뜨는 오류를 확인을 하였는데요 그래서 인위적으로 davedb를 만들어 주고 실행을 하니 success가 뜨는 것을 확인을 했습니다. 혹시 수정을 해도 똑같은 오류가 뜨는 원인이 뭘까싶어 질문 남깁니다.

쿠키의 생명 주기 설명에서 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시까지만 유지된다고 하셨는데,   웹서버 입장에서는 웹 브라우저가 종료되었다는 사실을 모를텐데 그럼 서버는 세션을 언제까지 보관하고 있나요?

    강의와 다른 질문들을 참고하여 HTTP 메시지 전송 과정의 순서에 대해 제가 이해한 내용은 아래와 같습니다.   1. 웹 브라우저에서 HTTP 메시지를 생성한다. 2. 애플리케이션은 소켓 라이브러리를 사용하여 TCP/IP와의 연결을 지시한다. 3. TCP/IP 와 연결된 후 TCP 계층에서 3 way handshake를 진행하여 서버와 연결한다. 4. 서버와의 연결이 확인되면 TCP/IP 프로토콜로 데이터(HTTP 메시지)가 전달된다. 5. TCP/IP는 전달받은 HTTP 메시지에 TCP관련 정보와 IP관련 정보를 추가하여 TCP/IP 패킷을 생성한다. 6. 웹 브라우저는 요청 패킷을 인터넷 망에 던진다.   질문입니다! Q1. 제가 이해한 전체 과정이 맞나요?   Q2. 3 way handshake를 진행하는 계층과 시점이 헷갈리는데요. 3 way handshake는 TCP/IP 연결 후에 TCP 계층에서 진행되는 것이 맞나요? (애플리케이션 계층에서 일어나는 게 아닌 거죠?)   Q3. 3 way handshaking을 하는 이유는 요청 패킷을 서버로 던지기 위해서 서버와의 연결을 확인하기 위한 게 맞나요?   Q4. 강사님께서 3 way handshake 진행 전 찾았다고 언급하신 IP와 PORT는 HTTP 요청 메시지 생성 전 URL을 통해 찾은 PORT와 DNS 서버를 통해 찾은 IP인 게 맞나요?   Q5. TCP/IP 패킷 생성 시 담아지는 IP와 PORT도 HTTP 메시지 생성 전에 URL과 DNS 서버 조회를 통해 찾아낸 IP와 PORT인 건가요?    

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.   클라에서 서버로 액션 요청 하고 로직 처리 후 클라로 응답 받는 시간이 어느정도되어야지, 지연 없이 받았다고 생각하면 될까요??      

oreilly 사의   1. HTTP 완벽가이드 2. 리얼월드 HTTP 두 권중 하나를 생각중이긴한데 더 좋은 책이 있을까요?

안녕하세요. 해당 강의를 수강중인 김승수라고 합니다. 항상 좋은 강의를 제공해주심에 감사드립니다.   이번 강좌에서 Cache-Control: no-cache 부분을 들으며 이것을 사용하는 실제 사례가 궁금해서 문의드립니다.   Cache-Control: no-cache는 데이터를 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용해야한다고 설명들었습니다. 내용 자체는 이해가 가능하나 이 방식이 사용되는 실제 사례가 궁금합니다.   만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높으나, 데이터 자체의 크기가 커서 변경이 일어나지 않은 경우에는 데이터를 다시 가져오는 부하를 줄이기 위해 사용하는 것일까요? 만료 시간 전에 캐시한 데이터가 서버에서 변경될 가능성이 높다면, 캐시 유효 시간을 짧게 설정하면 될 것인데... no-cache를 왜 만들었을까요? 캐시로 관리하는 데이터가 원 서버의 실제 데이터와 동일한지 매번 검증한다면 이 작업 자체도 오버헤드라고 볼 수 있지 않을까요? 아니면 드물게 사용하는 매우 큰 데이터를 캐시에 두고 캐시 유효 시간을 길게 가져가기 위해 사용하는 것일까요? 캐시 자체는 빈번하게 조회할 데이터를 빠르게 가져오기 위해 조회 데이터를 가까이 두는 기술로 알고 있는데요. 드물게 사용할 데이터를 캐시에 보관하는 것도 이상하다고 생각됩니다.   강사님의 답변 기다리겠습니다. 감사합니다.   김승수 드림

클라이언트와 서버가 TCP 3 way handshake로 논리적으로 연결 된다고 알고 있습니다.  그러면 실제 클라이언트와 서버가 물리적으로 어떻게 연결됐는지는 알 수 있나요?

항상 좋은 강의 감사드립니다. 1. if (Conversion<const FromType*, const ToType*>::exist)  이 부분에서왜 포인터를 사용했는지 궁금합니다. 2. TypeConversion은 결국 많은 템플릿을 생성하게 되는데 그럴 경우 메모리에 문제가 없는지 궁금합니다. 3.Conversion 의 경우 컴파일러가 비슷하다고 판단 할경우 From을 To로 변환을 하고 결국 그걸 이용해 변경 여부를 판단하게 되는데 컴파일러 입장에서 비슷할 경우 변환을 시키지 않는 것이 이득일텐데 굳이 변환을 하는 원리가 궁금합니다. 4. 마지막으로 struct로 만드실 때와 class로 만들 실 때의 기준이 있으신가요? template 흑마법 정말 잘 배웠습니다 핵? 편법같은 느낌이 있어 관심이 많이 가게 되었습니다.  추후 강의 기대하겠습니다!

안녕하세요. 다른 질문댓글에서 DNS 는 3way handshake 가 발생하지 않는다고 하셔서 3way handshake 는 HTTP 단계가아니라 TCP / IP 단계에서 맺어주는 요청이지 않나요??  DNS와의 연결방식이 혹시 기존 TCP IP 와 다르게 동작하는것인가요??