Hello, Freakin world!

BDD 방식의 테스트도 의미가 없다. IO 메서드의 기능을 제대로 테스트하기 위해서는 어찌됐든 서버가 필요하다. 선택지는 두 가지다. 1. Mock 서버를 작성하고 다른 스레드에서 실행시킨다. 2. 실제 서버를 켜놓고 테스트를 진행. 1번도 번거롭고, 2번도 구리다. 1번이 번거로운 이유는 클라이언트의 기능 테스트가 점점 늘어날 수록 Mock서버도 커지게 된다는 점때문이다. 비동기 메서드와 테스트 메서드 간에 어떤 예외가 던져질지도 미지수다. 2번은 더 치명적이다. 수동으로 계속 서버를 켜줘야하며, 자동화된 테스트가 불가능하다. 결론 : 1번으로 진행하자... 내가 테스트의 비중을 너무 간과하고 간단하게만 해결하려고 한건지도 모른다. 테스트에 품을 더 들이자.

이 부분은 꽤 골치아픈 부분이었다. 우선 아래 사진을 한번 보자. 이벤트 루프 스레드를 만든 이유는 위의 그림처럼 selecter(셀렉터의 객체)의 select() 메서드를 반복 수행하기 위함이다. (참고 : select() 의 역할은 실행할 수 있는 이벤트가 최소한 하나가 있을 때까지 대기하는 일종의 blockingQueue와 비슷함.) 가장 고민됐던 부분은 selector 객체를 어디서 관리하느냐는 문제였다. 고민하기에 앞서, selector 객체는 전역적으로 사용되기 때문에 반드시 공개되어져야 한다. 두 가지 선택지가 있다. 1. 이벤트 루프 스레드 내부에서 생성하고 스레드를 시작하기 전에 selector 객체를 초기화해 외부에 공개한다. 2. 외부에서 selector 객체를 관리하고 이벤트 루프 ..

Java NIO 에서 지원하는 셀렉터를 이용하면 하나의 serverSocketChannel로 다중의 클라이언트 채널에 대응할 수 있다. 그리고 위 그림은 클라이언트의 연결 요청에 대한 처리만을 그림으로 나타낸 것이다. (채널은 기본적으로 양방향 통신이 가능한데, 나중에 차차 추가하도록 하자.) 셀렉터에는 각 채널의 register 메서드를 통해 selector에 등록할 수 있는데, 이벤트 주도 모델에서 이벤트를 등록하는 개념과 유사하다. 위 그림에서 셀렉터는 eventLoop를 처리하는 다른 스레드에서 작동한다. 만약 서버가 클라이언트에 대해서 이벤트를 던지기만 한다면 굳이 또 하나의 스레드를 추가해서 구현할 필요가 없다. 하지만 이벤트의 발원지가 서버가 아닌 클라이언트인 경우, 이 이벤트를 감지하기 위..

클라이언트 부분부터 작성해보자. 클라이언트는 main 메서드를 이용해 시작된다. 다음과 같은 코드가 있다. import java.io.IOException; import java.util.logging.Level; import java.util.logging.Logger; public class Main { static Logger logger = Logger.getLogger(Main.class.getCanonicalName()); public static void main(String[] args) throws IOException { System.out.println("채팅앱 시작"); System.out.println("서버와 연결 시도 중."); /* 서버와 연결 코드 */ System.out...

- 콘솔을 이용한 채팅앱 구현하기 - 자바 nio api 이용/ jdk12