최종적에서 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 비용을 아끼고 그만큼 성능이 빨라지게 되는 건지요?

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

    강의와 다른 질문들을 참고하여 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로 논리적으로 연결 된다고 알고 있습니다.  그러면 실제 클라이언트와 서버가 물리적으로 어떻게 연결됐는지는 알 수 있나요?

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

안녕하세요 캐시와 쿠키와 관련한 차이점에 대해 질문드립니다. 두개 모두 정보를 캐시저장소와 쿠키저장소에 저장하고 이를 사용할 수 있는 공통점이 있는것 같습니다. 하지만 두 개의 사용 헤더도 다르고 사용 목적도 다르기는 한데 두개의 차이점을 찾아보니 난해한 부분이 있어 질문 드립니다. 쿠키와 캐시의 정의, 사용목적, 차이점등에 대해 부연설명 부탁드리겠습니다. 감사합니다.

- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존Introduction to Packet Tracer course 가 안나오네요. 대신 위 링크가 나옵니다. 패킷트레이서 코스로 아이디를 생성하지 못하여, 앱 다운도 못하며 이용도 못하고 있습니다.   아이디를 만들었고 앱은 다른 루트로 다운 받았지만 해당 아이디가 패킷트레이서 코스를 통해 만든 아이디가 아니여서, 패킷트레이서 와 연동이 안되서 이용을 못하고 있습니다.  

Introduction to Packet Tracer course 라는게 안나와있습니다.   이게 나와야하는데...       이게 나옵니다.   패킷트레이서 통해 아이디를 만들어야하는데, 그렇지 못해서 다운도 못하고 있고 이용이 안되고 있습니다.  

section4 ppt 자료좀 받을 수 있을까요?

jobQueue에 데이터를 넣고 뺄 때 lock을 걸어야하는 것은 이해가 되는데 action에 데이터를 넘겨받고서는 lock이 풀린상황이니 invoke하기 전에 다른 스레드가 action을 바꿔치는 경우도 가능하지 않을까 하는 생각이 들어서 질문드립니다.