Hello, Freakin world!

여러 수정을 하다보니 초기의 설계와는 완전히 달라졌네요. 우선 그림으로 살펴보도록 하겠습니다. 서버는 크게 ChatRoomServer 와 ChatServer. 두 가지가 있습니다. 채팅룸 서버(ChatRoomServer) : 채팅방의 정보(방이름, 현재 인원수, 최대 인원수, id)를 관리하는 서버입니다. 채팅메세지 서버(ChatServer) : 읽은 채팅 메세지를 같은 방의 모든 인원에게 다시 보내주는 역할의 서버입니다. 채팅은 이 서버를 통해 이루어집니다. 이렇게 서버를 두 가지로 분리시켰던 이유는 솔직히 말하자면 이벤트방식으로 모든 요청을 처리하기가 난감했기 때문이었습니다. 채팅룸 서버는 동기방식의 논블로킹 방식(자바 서블릿이 웹 요청을 처리하는 방식)이고, 채팅 메세지 서버는 이벤트 방식의 논블로..

소감 정말 네트워크 실습 겸해서 간단하게 시작한 토이 프로젝트였는데, 주워들은 것들을 실험하다보니 엄청나게 시간이 걸려버렸습니다. 하지만 이로인해 배운 것들이 정말정말정말 많네요. 앞으로 몇 일동안은 배운 것들을 정리하며 이 프로젝트를 마무리하려 합니다. 예외 처리를 최대한 한다고 했지만, 코드를 작성하면서도 미숙함이 많이 느껴졌습니다. 특히 삭제 관련 요청에 대해서도 트랜잭션을 지원해야 할 필요성을 느꼈지만, 너무 프로젝트가 복잡해질까 제외시켰습니다. 허접하지만 처음으로 뭔가 난이도있는 앱이라고 부를만한 것을 만들어낸 것 같네요. 정말 개운하면서도 아쉬움이 남네요. 정말 수고가 많았고 수고했다고 자신에게 위로의 말을 전하면서~ 소감은 여기에서 마무리하겠습니다 https://github.com/johnn..

프로젝트 막바지에 중요한 결함을 발견하고, 결국 코드를 리셋하기로 마음먹었습니다ㅠㅠ (남는게 시간인 백수라 쌉가능) (빨리 완성하고 스프링 프로젝트를 시작하고 싶었지만...) 결함은 허술한 아키텍쳐 설계가 원인이었습니다. 하지만 이 당시엔 이벤트 방식의 논블로킹 서버에 대한 지식이 전무했기 때문에 어떻게보면 이와 같은 결정이 필연적인 수순 같기도 하네요. 문제점을 간단하게 설명하자면, 처음 설계된 구조는 서버에서 하나의 EventLoop(전달 받은 이벤트를 처리하는 스레드)를 이용해 모든 이벤트를 처리하려고 했습니다. 이렇게 할 경우, 이벤트를 read 하는건 상관없지만 write 해야되는 경우에 난감해집니다. 채팅방에 있는 사람들에게만 write하려면 채널들을 선별하는 과정이 필요합니다. 고민해본 결과..

사용자는 콘솔을 통해 - 채팅방 생성 - 채팅방 리스트 조회 - 채팅방 나가기 - 채팅방 참가 의 기능을 이용할 수 있다. https://github.com/johnna-endure/chatting-project-entire johnna-endure/chatting-project-entire Contribute to johnna-endure/chatting-project-entire development by creating an account on GitHub. github.com 전체 코드이다. 완벽하진 않지만 그래도 끝이 보인다!!!

특히 DTO들의 중복이 아주 심하다. 지금 서버 간에 JSON 포맷의 데이터로 통신을 하고 있다. 그래서 그 데이터를 사용하기 위해 다시 DTO 객체에 바인딩한다. 그래서 서버, 클라이언트 모두 같은 DTO 클래스를 가지고 있어야 하는데, 프로젝트가 어느 정도 복잡해지니, 유지보수하기가 여간 귀찮은게 아니다. 그리고 유틸용으로 작성해놓은 메서드도 다른 모듈에서 사용하려면 코드를 복사해서 사용해야한다. 상황을 몸소 느껴보니, 자바9에서 모듈 시스템을 왜 도입했는지 알겠다. 대충 찾아보니 gradle에서 plugin을 이용하면 모듈 프로그래밍이 가능한 것처럼 보인다. 일단 킵해두고 반드시 학습해보자. 여기저기 수정하기 귀찮아죽겠다 ㄹㅇ로

ChatRoomServer의 단위테스트 및 통합테스트 추가(v1.1) 이제 채팅룸 서버는 에러가 없는 이상 완성됐다고 간주하고, 다음 작업으로 넘어가자. https://github.com/johnna-endure/chatroom-serverjohnna-endure/chatroom-serverContribute to johnna-endure/chatroom-server development by creating an account on GitHub.github.com 진행 상황 이제 다시 Selector를 이용한 논블로킹 방식의 서버부분과 이 두 가지 서버에게 요청을 보내는 콘솔 앱 부분 작성에 들어가면 된다. 참고로 이벤트 방식의 논블로킹과 동기 방식의 논블로킹은 서로 완전히 통신하는 방식이 다르다.이에..

간단하게 시작해서 여기까지 오게 되다니 ... 코드를 조금씩 생성하면서 그에 관한 글도 꾸준히 올리려했지만 워낙에 코드를 뒤집어 엎고대규모 수정하는 경우가 빈번해 글 사이 시간 간격이 상당히 길어졌다. 결국 CompletableFuture 를 이용한 논블로킹 동기 방식의 서버를 1차 완성했다.아직 단위테스트와 통합 테스트 몇 부분을 더 추가해야 되긴하지만. 내 기준에 정말 의미있는 성과다. 아직 다듬을 코드가 많긴 하지만, 그래도 나름 코드 품질을 어느 정도는 유지하려 애썼다. 아래는 전체코드다.(혹시 실행시켜보시려는 분은 .gradle, .idea, build, out 폴더는 삭제하고, 프로젝트는 gradle로 빌드하시면 됩니다. ) 이 프로젝트에 대해서도 할말이 많긴 한데,자세한 설명은 따로 프로젝트..

POST /room | 채팅방 생성 요청 응답 : 성공 또는 실패여부 GET /room/{ id } | 채팅방 조회 요청 응답 포맷 상태코드 설명 ChatRoom Json객체 GET /rooms | 채팅방 리스트 요청 응답 : List POST /room/{roomId} | 채팅방 참가 요청 응답 : 참가 가능시 id에 해당하는 ChatRoom 객체를 body에 Json 형태로 보낸다. 참가 불가능시 body는 null이다. DELETE /room/{roomId} | 채팅방 삭제 요청 응답 : 성공 또는 실패 여부 Request 메세지 형식 | method url | | [data] 응답 메세지 형식 | 상태코드 [상태 설명] | | [data]

아마 내가 자바 nio에서 제공하는 selector를 이용한 논블로킹 방식에 꽂혀있었는지도 모르겠다. 이 방식으로 모든 네트워크 통신을 처리하려고 했으나 한계가 있다는걸 깨달았다. 이전에 ConnectionLoop를 구현할 때 깨달았던 부분과도 관련이 있다. 지금이 selector를 이용한 논블로킹 방식(이벤트 방식)은 데이터를 보내고 그에 대한 응답을 받아야하는 식의 대화형 애플리케이션은 만들 수가 없다. 그 이유는 이벤트를 보내고나서 그 특정 응답을 선별할 수 없기 때문이다. 이를 구현하려면 동기방식을 쓸 수 밖에 없다. (기존의 웹처럼) 동기방식을 쓰더라도 그 작업을 다른 스레드에 위임하면 논블로킹을 구현할 수 있는데, 아마도 Future와 CompletableFuture를 사용하면 될 듯하다. 자..