기록/TIL

2023/04/17 TIL

쥬냥냥 2023. 4. 18. 17:37
[MultiIt Backend] 

서론

우선 적으로 조금 반성부터 하고 시작해야할 것같다.. ㅎㅎ 주말이 되서 원래는 정처기 공부도 하고, 코드도 짜고 문제도 풀고 할려했는데 토욜에는 아침에 일어나서 정보처리기사는 공부를 좀 했는데 그외에 프로젝트 관련해서 원래는 퍼블리싱을 위해 받은 부트스트랩 템플릿으로 채팅부분을 만들려했는데 ㅠㅠ 나의 못난 의지력으로 만들지를 못했다ㅎㅎ 일욜에는 몸이 너무 안좋아서 하루종일 약먹고 잤더니 시간이 다 가버려 뭘 제대로 하지 못하고 주말이 지난 것이 너무 후회스러웠다. 진짜 컨디션을 잘 챙기며 원래 주말에 가장 뭔가를 여유롭게 할 수 있는 시간인데 이 주말이라는 시간을 그저 휴식만 하는 것보다 뭔가 의미있는 무언가를 해야겠다는 생각이 들었다. 오늘은 전체적으로 각자 맡은 부분에 대해 진행을 해보았다. 그 중 나는 채팅 기능을 개발하게 되었다. 채팅에 관련된 부분은 팀안에서 감이 크게 안잡혀 담당한 사람이 전적으로 해보자 했던 부분이라  크게 감도 안잡혀서 전체적으로 하루종일 관련 자료를 보며 어떤식으로 진행해야 할지 파악하는 느낌으로 학습을 했다. 내가 실제 구현해보지 못하고, 비교적 어려운 기능을 담당하다 보니 걱정도 됬지만 그만큼 나의 실력을 쌓을 수 있고 새로운 기능에 대해 학습한다 생각하니 오히려 더 의지가 생기고 어렵더라도 잘 배워봐서 실시간 통신, 소켓에 대해 어느정도 마스터할 수 있도록 노력해야겠다는 생각이 들었다. 하지만.. 실상은 많이 감을 못잡았다. ㅎ 것보다 내 MySql connecter가 이상해서 intellj에서 db 연동이 안되서 하루종일... 에러만 봐서 좀 힘들었다. 내일은 고쳐야지!

오늘 하루 진행 내용

전체적으로 오늘은 크게 무언가 진행된 결과는 없다. 서론에서 말했듯 채팅 기능을 어떤식으로 구현해야 할지 생각하고, 전체적인 프로세스가 어떻게 진행되는지에 대해 구글링하며 학습 위주로 진행했다.

그 결과 두가지 방식으로 채팅을 구현할 수 있는 법을 생각했다.

1. 쪽지의 개념으로, 회원이 메시지를 보낸다면 이를 실시간 통신에 엮지 말고 동기||비동기 둘 중 방식

   , 단순히 보낸 메시지를 저장하고 이를 보내주는 어떻게 보면 게시글, 댓글 방식으로 구현을 하는 방법과 비슷

               채팅전송 버튼 클릭 →채팅db에 저장 → 채팅을 받은 사람이 페이지 리로드시(get)

                → 저장된 채팅db에서 채팅 리스트 불러오기      

  (페이지 리로드를 해야 채팅이 왔을 때 확인 가능, 비교적 쉽지만.. 우리의 목표가 sns이다보니 부적절)

  +여기에 사용자가 특정 사람과의 채팅방을 들어가면 몇초 단위로 자동 리로드 되게 하는 방식 (비효율적일듯)

 

2. 소켓을 통한 실시간 통신으로 메시지를 주고 받고, 또한 메시지를 저장해 이를 방에 들어올떄마다 미리 불러주는 방식

              채팅 내용은 소켓을 통해 실시간 전달&불러오기 → 채팅하는 동안 메시지 보낼때 마다 db에 저장 -> 회원이

              채팅방에 들어올때 처음 한번만 채팅db에서 내용을 찾아와 순서대로 불러주기

  (우리가 생각하는 인스타 디엠이나, 카톡처럼 비슷하게 보일듯? 목표에도 적절하지만 난이도 어려움+db많이 차지)

+json으로 대화방을 나갔을 때만 저장한다면, 비교적 덜 db가 자주 저장 안되지 않을까? -> 어려울 듯..

 

이 방법 중 우선 2번의 방법으로 소켓을 통한 실시간 통신으로 구현을 해볼 예정이다, 한 수목까지 하다가 어렵다면 우선 쪽지형식으로 예방책으로 구현할 예정으로 스스로 계획을 짜봤다.

그 후 채팅db에 대해 구상해 채팅 entity를 작성하였다. 그 후 mysql 연결을 해 jpa를 통해 jpaRepository가

생성이 되는지 확인을 할려했는데 같은 오류가 계속떠 여기에 시간을 쏳다가 해결하지는 못했다.

내일 도움을 요청해 해결하고 진행할 예정

정규 시간이 끝난 후 이번주 일요일이 정보처리기사 실기날이라 정처기 실기 공부에 집중해

10장까지 문제를 다 풀어보고, 앞 부분을 다시 한번 복습하는 과정을 거쳤다.

 

<진행 사항>

채팅 프로세스 학습, 1. chating 테이블 생각과 entity 작성, 정보처리기사 학습

chating entity 작성

느낀점

새로운 기술을 시도하는 것은 어려우며, 배울것이 아직도 정말 많고 노력해야겠다는 의지가 생겼다. 전체적으로 소켓을 통한 채팅 자체가 프로젝트내에서 한번도 진행해 본적이 없고, 비교적 어려운것으로 알고 있었다. 그리고 처음에는 실시간 통신을 기준으로 생각하다, '실시간 통신, 소켓을 통한  채팅은  채팅방을 나가면 내용이 사라진다'에 순간 생각이 잡혀버려 좀 삽집을 오래했다. 그래서 기본적으로 테이블을 먼저 구상하고 어떤 프로세스로 채팅 기능을 구현해야 할지 생각해보니, 생각보다 어려워서 제대로 알아보고 많은 참고를 통해 꼭 구현에 성공해야겠다 생각했다. 그렇게 생각하고 엔티티까지 다 구상 후 jpa가 제대로 repository 생성 되나 확인할려고 서버를 구동시켜보니까.. 다른 것도 아닌 db가 아예 연결이 안되서 되게 멘붕이 많이 왔다. 에러를 봐도 모르겠고, intellj 내부에서도 MySql이 연결이 안되서 에러를 아무리 찾아도 뭐가 안나와서 정말 끈덕지게 찾았지만 해결을 못해서 내 부족함이 정말 크게 와닿았다. 우선적으로 프로젝트 개발이 중요하다보니 진짜 한두시간 찾다가 안되서 기본적인 채팅 알고리즘 및 어떤방식으로 하는지 찾아보는데 시간을 허비하긴했지만 내일 강사님께 도움을 요청해 이 에러를 꼭해결해야겠다 느꼈다. 그와 동시에 전체적으로 그동안의 나의 개발, 공부 방식이 많은 참조와 구글링을 통해 이루어지다보니, 에러를 보고도 감을 많이 못잡고 어디서 오류가 나는지 구조를 보며 찾아가지 못하는게 전체적인 스프링과, jpa 구조를 알지 못해서라는 생각이 들었다. 프로젝트를 우선적으로 마친 후 이런 에러를 잡아가는 과정과 기본적인 각 프레임워크, 메서드등의 api를 통한 학습을 통해 활용법이 아닌 그 자체의 개념과 사용법을 알아야 에러든 실제 활용에서든 더 적절하고 효율적으로 사용할 수 있을 거라 느껴져 좀 더 기본개념에 대한 공부의 필요성을 느낄 수 있었다. 

배운점

 크게는 기본적인 api docs를 통해  그 자체의 개념과 사용법을 학습해야하는, 기초적인 학습과 구조에 대한 중요성을 배울 수 있었다.(내가 에러를 잘 잡지 못하는게, 이런걸 잘 몰라서 어디서 에러가 생겼는지 빠르게 감을 잡지 못하는 듯 ㅠ) 또한 채팅 시스템이 어떤식으로 이루어져야하는지와 동기, 비동기 실시간 통신에 대한 개념을 잡고 소켓에 대해서도 배울 수 있었다. 마지막으로 jpa 에서 외래키를 위한 join 부분에 대해 자세히 알 수 있었다. 

+ 개념 & 용어 

 ! 실제 채팅 서비스를 구현 시 view에서 채팅이 올 경우 바로바로 보여주는 방법에 대해 알아보다가 학습

= 동기, 비동기, 실시간(소켓)

 

javascript의 ajax, JAVA 외부 API 등 호출 시 데이터를 주고받을 때 동기 or 비동기 방식으로 할지 정한다.

동기 (synchronous) : 요청과 결과가 동시에 일어남, 요청을 했으면 응답이 주어질 때까지 대기

- 요청과 응답이 동시에 일어난다.

- 응답을 기다린다.

- 프로세스가 순차적으로 진행된다.

 

비동기 (Asynchronous) : 요청과 결과가 동시에 일어나지 않음, 요청한 자리에서 결과를 기다리지 않아서 각 작업 프로세스가 순차적으로 진행 X

- 요청과 응답이 동시에 일어나지 않는다.

- 응답을 기다리지 않고 다음 노드 (요청)를 진행한다.

- 순서를 보장하지 않는다.

소켓(SOCKET)

: 프로세스가 네트워크에서 데이터를 주고 받기 위한 실직적인 창구 역할
= 프로세스가 데이터를 송수신을 위해선 반드시 소켓을 통해 주고 받아야한다.

소켓의 정의 = 프로토콜 + IP + Port

 
- 프로토콜 : 통신에서 어떤 시스템이 다른 시스템과 통신을 원활하게  해주는 통신 규약, 약속
 
-  IP : 전 세계 컴퓨터에 부여된 고유의 식별 주소
 
- 포트(Port) :  네트워크 상에서 통신하기 위해서 호스트 내부적으로 프로세스가 할당받는 고유한 숫자
= 한 호스트 내에서 네트워크 통신을 하고 있는 프로세스를 식별하기 위해 사용되는 값이니, 같은 호스트 내에서 서로 다른 프로세스가 같은 포트 넘버를 가질 수 없음. 즉, 같은 컴퓨터 내에서 프로그램을 식별하는 번호이다.

즉 소켓은 떨어져 있는 두 호스트를 연결해주는 도구로 인터페이스의 역할을 하는데 데이터를 주고 받을 수 있는 구조체로 소켓을 통해 데이터 통로가 만들어 짐. 

 

소켓통신   흐름

서버 (Server) 소켓
: 클라이언트 소켓의 연결 요청을 대기하고, 연결 요청이 오면 클라이언트 소켓을 생성하여 통신이 가능하게 함
1) socket() 함수를 이용하여 소켓을 생성
2) bind() 함수로 ip와 port 번호를 설정
3) listen() 함수로 클라이언트의 접근 요청에 수신 대기열을 만들어 몇 개의 클라이언트를 대기 시킬지 결정
4) accept() 함수를 사용하여 클라이언트와의 연결을 기다림
 
클라이언트 (Client) 소켓
: 실제로 데이터 송수신이 일어나는 것은 클라이언트 소켓
1) socket() 함수로 가장먼저 소켓을 연후.
2) connect() 함수를 이용하여 통신 할 서버의 설정된 ip와 port 번호에 통신을 시도
3) 통신을 시도 시, 서버가 accept() 함수를 이용하여 클라이언트의 socket descriptor를 반환
4) 이를 통해 클라이언트와 서버가 서로 read(), write() 를 하며 통신 (이 과정이 반복)
 

HTTP 통신과 SOCKET 통신 비교

 

HTTP 통신

- Client의 요청(Request)이 있을 때만 서버가 응답(Response)하여 해당 정보를 전송하고 곧바로 연결을 종료하는 방식

SOCKET 통신
- Server와 Client가 특정 Port를 통해 실시간으로 양방향 통신을 하는 방식
HTTP 통신 SOCKET 통신
 Client가 요청을 보내는 경우에만 Server가 응답하는 단방향 통신 Server와 Client가 계속 연결을 유지하는 양방향 통신
Server로부터 응답을 받은 후에는 연결이 바로 종료 Server가 종료되거나, Client에서 연결을 끊어야 종료
실시간 연결이 아니고, 필요한 경우에만 Server로 요청을 보내는 상황에 유용 Server와 Client가 실시간으로 데이터를 주고받는 상황이 필요한 경우에 사용
요청을 보내 Server의 응답을 기다리는 어플리케이션의 개발에 주로 사용 실시간 동영상 Streaming이나 온라인 게임 등과 같은 경우에 자주 사용