항해 99 5기 TIL_61

▶ Today I Learned

 

<CS>

 

[스레드와 멀티스레드]

 

스레드(Thread)

: CPU 이용의 기본단위, 프로세스 내에서 프로그램 명령을 실행하는 기본 단위이자 흐름, 개체

스레드 ID, 프로그램 카운터, 레지스터 집합, 스택 으로 구성됨

 

프로세스에 하나의 제어 모델이 있으면 단일 스레드이며,

프로세스가 다수의 제어 스레드를 가진다면 다중 스레드 모델

 

단일 스레드

 

- 하나의 프로세스에서 하나의 스레드 실행

- 하나의 레지스터와 스택으로 표현

 

장점

1) 자원 접근에 대한 동기화(순서대로 실행하는 것)을 신경쓰지 않아도 된다.

여러 개의 스레드가 공유된 자원을 사용할 경우 각 스레드가 원하는 결과를 얻게 하려면

공용 자원에 대한 접근이 통제되어야 하지만 단일 스레드는 하나의 스레드만 이용하므로 이런 통제가 필요 없다.

 

2) 문맥 교환(context switch) 작업을 요구하지 않는다.

문맥 교환은 여러 개의 프로세스가 하나의 프로세서를 공유할 때 발생하는 작업,

많은 비용을 필요로 한다.

 

cf) 문맥 교환이란?

하나의 프로세스가 CPU를 사용 중인 상태에서 다른 프로세스가 CPU를 사용하도록 하기 위해, 이전의 프로세스의 상태(문맥)를 보관하고 새로운 프로레스의 상태를 적재하는 작업을 말한다.

 

단점

 

1) 여러 개의 CPU를 활용하지 못한다.

여러 개를 활용하려면 여러 개의 프로그램 인스턴스를 실행시키는 방법이 있다.

하지만 이 경우에는 각각의 인스턴스가 상태를 공유하는 것을 어떻게 구현해낼 것인지라는 문제가 있다.

 

멀티 스레드

 

- 프로그램을 다수의 실행 단위로 나누어 실행

- 프로세스 내에서 자원을 공유하여 자원생성과 관리의 중복을 최소화

- 서버가 많은 요청을 효율적으로 수행할 수 있는 환경을 제공

- 각각의 스레드가 고유의 레지스터와 스택으로 표현됨

 

장점

 

1) 새로운 프로세스를 생성하는 것보다 기존 프로세스에서 스레드를 생성하는 것이 빠르다.

2) 프로세스의 자원과 상태를 공유하여 효율적으로 운영이 가능하다

3) 프로세스의 문맥교환보다 스레드의 문맥교환이 더 빠르다.

 

단점

 

1) 하나의 스레드만 실행중일 때에는 실행시간이 되려 지연될 수 있다.

(싱글 스레드는 하나에만 집중하므로 하나의 스레드만 실행 중일땐 그쪽의 실행 시간이 더 빠를 수 밖에 없다.)

2) 멀티 스레딩을 위해 운영체제의 지원이 필요하다.

3) 스레드 스케쥴링을 신경써야 한다. 여러 개가 동시에 실행되기 때문이다.

 

출처:

https://beenlife.tistory.com/114

 

 

<실시간 화상 채팅>

 

simple peer와 socket.io를 이용해 실시간 화상 채팅을 구현하기 위해 아래의 유튜브와 깃헙 코드를 참고하였다.

 

[simple peer & socket.io 화상채팅 깃헙]

 

https://github.com/coding-with-chaim/group-video-final/blob/master/client/src/routes/Room.js

https://github.com/coding-with-chaim/group-video-final/blob/master/server.js

simple peer & socket.io 화상채팅 깃헙 소유자가 Mesh 방식을 설명한 부분 -> 영상 8:40 - 9:40 쯤 create Peer에 대한 설명

https://www.youtube.com/watch?v=R1sfHPwEH7A&t=246s

여기서 initiator와 trickle의 개념이 무엇인지, 어떻게 쓰이는 것인지 몰라 찾아본 결과, 아래와 같았다.

 

new Peer()를 사용할 시

initiator:

initiator가 true일 경우 peer가 접속할 때 그 방의 다른 peer들이 방에 누군가 접속했다는 것을 알게해주어

서로의 시그널링을 가능하게 함

 

출처

https://www.youtube.com/watch?v=R1sfHPwEH7A&t=246s

 

trickle:

The core difference when you change { trickle: false } to { trickle: true } is that multiple 'signal' events may be emitted from the peer object. Your responsibility is to call peer.signal() on the remote peer whenever the local peer emits a 'signal' event.

The same code can work with trickle enabled or disabled, as long as you're passing every 'signal' event to the remote peer.

⇒ 쉽게 요약하면 원격 피어에 시그널을 하나 이상만 보내주기만 하면 trickle을 true나 false, 무엇으로 선택하든 코드 작동엔 대개 이상이 없음

(trickle이 true일 경우 signal을 여러 개 보낼 수도 있다는 것)

 

출처

https://github.com/feross/simple-peer/issues/67

 

그리하여 우리는 다음과 같이 프론트 측에서 연결을 위한 peer를 생성하는 코드를 작성해보았다.

 

// 피어 생성에 쓰이는 함수
function createPeer(userToSignal, callerID, stream) {
    const peer = new Peer({
      initiator: true, // initiator가 true일 경우 peer가 접속할 때 그 방의 다른 peer들이 방에 누군가 접속했다는 것을 알게해주어 서로의 시그널링을 가능하게 함
      trickle: false, // true일 경우 signal을 여러 개 보낼 수도 있음, 원격의 peer끼리 신호를 하나 이상 보내주기만 한다면 false로 해도 문제는 없다고 함
      stream,
    });

// 피어 생성
participants.forEach((userID) => {
            const peer = createPeer(userID, socketRef.current.id, stream);
            peersRef.current.push({
              peerID: userID,
              peer,
            });
            peers.push(peer);
          });

 

▶ 느낀 점

 

실시간 화상 채팅이 우리의 핵심이지만 여전히 고려할 요소가 많았다.

게다가 화상과 채팅이 동일한 방을 이용하니 서로의 소켓 코드를 연결지어야하고 그 외 다른 페이지의 기능구현이나

세부 사항 점검도 필요하다.

 

나는 현재 채팅코드와 화상 코드를 병합하며 소켓에 관한 API를 정리중에 있다.

거의 마무리가 되어가고 그 와중에 다른 팀원분이 채팅에 관해 짜놓은 코드도 있기에 그걸 내가 짠것에 합쳐 활용해보아야겠다.

빨리 끝나는 대로 핵심 기능들을 테스트하며 이상은 없는지, 성능은 괜찮은지 등도 점검해볼 예정이다.

조금씩이지만 코드를 점점 이해하고 있고 문제를 해결해나가고 있으니 내일은, 모레는 더 가속도가 붙으리라 믿는다.

 

오늘 하루도 고생많았습니다, 팀원 여러분, 그리고 제 자신 :)

 

▶ 공부 시 참고 링크들

 

 

https://cotak.tistory.com/102

[Node.js] JWT: Access Token & Refresh Token 인증 구현

 

https://gh402.tistory.com/47

[WebRTC] WebRTC를 공부하며 스트리밍 과정 익히기