서버의 대기열에 등록되는 순간 객체가 생성된다. 안되면 reject뜸
보내는 거랑 받는 거랑 합이 맞아야함
accept는 승인 즉 fifo 자료구조
try with resources 하면 close 따로 할 필요 없음
write 는 블로킹 소용없음 근데 서버에서 데이터를 읽을 때 read할 때는 블로킹 된다.
byte stream은 flush 안해도됨 근데 char stream은 꼭 해줘야함
write read 로 끝나면 character stream 임 얘네는 꼭 flush 해줘야함
버퍼 쓸 때는 flush 꼭 해줘야함 배열이 가득찼을 때만 내보내기 때문에(client 에서만 flush해주면 된다)
걍 버퍼쓰면 sever랑 client 랑 둘다 그냥 flush 해줘라
그냥 flush 랑 close랑 그냥 다 해줘라
stateful 방식
// => 서버와 연결한 후,
// 클라이언트에서 연결을 끊을 때까지(또는 서버에서 연결을 끊을 때까지)
// 계속해서 연결을 유지하며 클라이언트 요청을 처리한다.
// => 단점:
// - 한 번 연결하면 클라이언트가 연결을 끊을 때까지 계속 유지한다.
// - 클라이언트가 작업을 요청하지 않더라도 계속
// 서버에 연결정보를 계속 유지하기 때문에
// 서버 메모리를 많이 차지하고
// 동시에 많은 클라이언트의 요청을 처리하기 힘들다.
// - 만약 서버가 순차적으로 클라이언트와 연결을 수행한다면
// 이전에 연결했던 클라이언트가 연결을 끊기 전까지는
// 다음 클라이언트와 연결되지 못하는 문제가 있다.
// => 장점:
// - 한 번 서버에 연결되면 클라이언트가 연결을 끊을 때까지 유지되기 때문에
// 요청할 때 마다 매번 연결 작업을 수행할 필요가 없다.
// - 따라서 요청에 대한 응답이 빠르다.
// - 또한 연결된 상태에서 수행한 작업 정보를 서버에 유지할 수 있어
// 영속성이 필요한 작업을 처리하는데 유리하다.
// => 작업 시간:
// - = 데이터 전송 시간 + 작업 처리 시간 + 데이터 수신 시간
// - 즉 작업을 요청할 때마다 연결할 필요가 없기 때문에 연결하는데 시간이 걸리지 않는다.
//
// => 대표적인 예:
// - 게임 서버 연결: 서버에 한 번 연결되면 게임을 마칠 때까지 데이터를 주고 받는다.
// - 화상 통신: 한 번 연결하면 연결을 끊을 때까지 데이터를 주고 받는다.
// - 채팅 서버: 전용 클라이언트를 이용한 채팅. 예) 유튜브 라이브 방송 채팅
// - 텔렛: 원격 제어 프로그램
// - FTP: 파일 전송 프로그램
// - 오프라인 예: 건강보험문의, 상담 등
//
// => 통신
// 클라이언트 서버
// |------------------>| 연결
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |--------X--------->| 끊기
// - 즉 한 번 연결하면 연결을 끊을 때까지 계속 데이터를 주고 받는다.
// stateless
// => 서버에 작업을 요청할 때 연결하고, 서버로부터 응답을 받으면 연결을 끊는다.
// => 즉 요청/응답을 한 번만 수행한다.
// => 단점:
// - 요청할 때마다 매번 서버에 연결해야 하기 때문에 실행 시간이 많이 걸린다.
// - 실행시간 = 연결하는데 걸린 시간 + 데이터 전송 시간 + 작업 처리 시간 + 데이터 수신 시간
// - 서버와 연결할 때,
// 사용자 인증(authentication; 아이디, 암호 유효 여부 검사)이나
// 사용권한 확인(authorization; 사용자에게 허락된 작업 범위를 확인) 같은
// 작업을 반드시 수행하는 경우 연결하는데 더더욱 많은 시간이 걸린다.
// => 장점:
// - 서버에 계속 연결된 상태가 아니기 때문에 서버 입장에서는 메모리를 많이 사용하지 않는다.
// - 왜?
// 클라이언트와 연결을 계속 유지하지 않기 때문에
// 작업을 처리하는 동안만 연결정보를 유지한다.
// 그래서 같은 메모리라도 stateful 방식 보다는
// 더 많은 클라이언트의 요청을 처리할 수 있다.
// => 대표적인 예:
// - HTTP 통신: 웹브라우저가 서버에 연결한 후 요청을 하고 서버가 응답한 후 연결을 끊는다.
// - 메신저: 메신저 서버에 연결하고 메시지 전송 후 연결 끊는다.
// - 메일 전송: 메일서버에 데이터 전송 후 연결 끊는다.
// - 오프라인 예: 114 안내, 배달 등
//
// => 통신
// 클라이언트 서버
// |------------------>| 연결
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |--------X--------->| 끊기
// |------------------>| 연결
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |--------X--------->| 끊기
// |------------------>| 연결
// |------------------>| 데이터 수신
// |<------------------| 데이터 전송
// |--------X--------->| 끊기
// - 서버에 요청할 때 마다 연결하고 응답을 받으면 즉시 연결을 끊는다.
// - 따라서 비영속적인 단일 작업을 처리할 때 적합한 통신 방식이다.
edX -cs50 검색
try(여기에 넣으면 자동으로 close해줌 auto closeable 구현한 객체만 가능 try with resources)
윈도우 - 라운드 로빈 모든 애들에게 거의 공평하게 cpu를 분배해줌
리눅스 - 우선순위가 높은 애를 더 많ㅇ ㅣcpu를 분배해줌 프라이올러티 방식?!
즉 thread 를 os 를 맞춰서 짜면안됨 그러면 os 마다 프로그램이 다르게 돌아갈 수 있음
