서버에서 socketChannel.read(buffer)값이 -1을 받아 클라이언트쪽에서 연결 종료 메시지를 받았을 때 key.interestOps(0); // 관심 키 제거 를 호출하여 문제 해결

발견하게 된 과정 : 자식 프로세스를 생성하지 않았음에도 생성한 것처럼 부모 프로세스가 동작을 함. -> 이상하게 여겨 자식 프로세스를 따로 런해봤더니 사용중인 포트라고 나옴 -> 자식프로세스가 고아프로세스가 되어 혼자 돌고 있는 것 발견

Active Close한 쪽이 FIN을 보내고 FIN_WAIT1상태로 대기 -> passive Close쪽이 CLOSE_WAIT으로 바꾸고 응답 ACK 전달 -> ACK 받은 ACTIVE CLOSE는 FIN_WAIT2상태로 변경 -> passive close쪽은 종료 프로세스 진행후 FIN을 클라이언트에 보내 LAST_ACK 상태로 바꿈 -> ACTIVE CLOSE쪽은 ACK를 PASSIVE CLOSE에 전송하고 TIME_WAIT으로 상태를 바꿈. TIME_WAIT에서 일정 시간이 지나면 CLOSE

지금 코드의 경우엔 정상적으로 종료를 못하고 테스트 코드가 멈추질 않아 수동으로 프로세스 종료시 발생됨.

TIME_WAIT이란? 패킷의 오동작을 막기 위함. 타임아웃은 60초로 설정되어 있음.

• 자바의 경우 Socket.SoLinger()같은 메소드로 시간을 할당할 수 있음.
• 톰캣을 이용하는 경우 shutdownPort를 설정해주지 않고 kill을 이용하여 강제로 프로세스 종료시 발생됨.

단일 스레드에서 동작하도록 설계되어 스레드에 할당될 경우 원치 않는 스레드를 추가 생성하고 동작이 이상해짐.

1차 : 논블로킹(Readable)io인 ReadableByteChannel 클래스가 있으나 결국 channel에 읽기 작업을 하면 다른 스레드가 접근하지 못하도록 블로킹함. 이러면 논블로킹을 쓰는 의미가 없다고 생각되어 사용하지 않았음. 또한, Selector와 같이 이벤트를 받아줄 수 있는 클래스가 존재하지 않음.

마지막에 인풋스트림을 한 번에 읽어오는 건 효율면에서 좋지만, 그때그때 출력을 보고 싶을 땐 안좋다고 판단하여 일단 출력 전용 스레드를 하나 더 만들어서 계속 읽기 이벤트를 리스닝 하도록 만듦.(이게 폴링 방식?)

2차: nio.Pipe클래스를 이용한 전달 클라이언트를 Selector 기반 이벤트 기반으로 변경하여 Pipe로 프로세스간 통신을 하고 각 채널 이벤트를 등록한다음, SocketChannel의 이벤트를 감지하고 처리하게끔 변경

기본적으로 논블로킹이지만 read와 write의 buffersize만큼은 버퍼가 걸리는 것 같다.

Thread.sleep()으로 실행때처럼 텀을 넣어주니 해결됨.

발생한 이유는 응답을 받고 서버는 클라이언트 소켓을 연결 종료시키는 시간이 필요한데, 바로 부모프로세스에서 자식프로세스를 강제 종료 시켜 출력이 종료되었거나 연결이 닫히는 걸 확인 못하고 그냥 나와버리는 듯

Writable과 Readable이 가능한 소켓 채널이 있는 것으로 추정, else if로 read 이벤트 타면 다시 못타게 막아놨더니 해결됨. 근데 왜 write 이벤트가 소켓채널로 들어오는진 모르겠음.

왜 행업되어 연결이 진행되다 그냥 죽어버리는가? 시간이 지나니 다 종료되고 established 된 연결 하나만 남는다.

해결 시도 : 혹시나 하나의 연결만 established가 된 게 신경 쓰여 Half-close 상태에 빠진 게 문제가 되나 싶어서 서버쪽에서도 드디어 알아낸 게 계속 sinkChannel로 read 이벤트가 발생하여 -1을 읽어온다!

최종 결론 : 설계부터 잘못되었다. Selector는 단일스레드를 타겟으로 설계된 모델이기 때문에 각각의 스레드 마다 독립적으로 open할 경우 원치 않는 동작이 수행되는 것이었다..

Selector를 활용해 비동기 논블로킹으로 동시성 테스트할 방법이 있나 테스트해볼 목적으로 작성해본 클라이언트쪽 테스트 코드이기때문에 당분간 좋은 아이디어가 떠오를때까지 킵할 생각이다.. socketChannel을 한번에 여러개 만드는 방법이 있긴한데.. 확장성이 안좋아 여러 개의 클라이언트 테스트를 못해본다. 논블로킹을 활용한 방법은 없어보이고 쓰레드나 프로세스로 독립적으로 처리해야할 듯한데, 이러면 논블로킹이 의미가 없으니 각각의 스레드나 프로세스에서 블로킹 메소드를 활용해서 테스트 해보는 방법이 맞는 것 같다.

참고 자료: https://www.baeldung.com/java-nio-selector,

https://homoefficio.github.io/2016/08/06/Java-NIO%EB%8A%94-%EC%83%9D%EA%B0%81%EB%A7%8C%ED%81%BC-non-blocking-%ED%95%98%EC%A7%80-%EC%95%8A%EB%8B%A4/,

https://tech.kakao.com/2016/04/21/closewait-timewait/,

https://linux.systemv.pe.kr/%eb%b2%88%ec%97%ad-%eb%b0%94%ec%81%9c-%eb%a6%ac%eb%88%85%ec%8a%a4-%ec%84%9c%eb%b2%84%ec%97%90%ec%84%9c-tcp-time-wait-%ec%83%81%ed%83%9c-%eb%8c%80%ec%b2%98%ed%95%98%ea%b8%b0/