강의중에 "websocket을 연결할때 ip가 변경되는 정책으로인해 http로 구현했다"고 말씀하신부분에 질문이 있습니다. dns를 사용한다면 서버 ip 변경이 있어도 연결이 가능하지 않을까 생각하는데요. 그렇다면 ws을 유지하는게 더 좋았을거라고 생각하시나요? 아니면 dns의 적용의 지연시간이나 기타 다른 이유들로인해 여전히 http를 선택했을지 궁금합니다

Kafka를 통한 Subscribe 마무리하고, API를 통해 확인해 볼게요.-> 이 강의에서 카프카 구동시키는 명령어 알려주실수있나요?

안녕하세요 강의 잘 들었습니다.근데 채팅방에서 메시지를 보내고 받는 부분은 카프카를 사용하지 않고 바로 db로 저장하더라구요. 근데 실제로 카프카를 사용해서 채팅 서버를 구성할때는 기본적으로 아래, FE -> BE - > kafka -> DB식으로 동작하는게 맞다고 보시나요?

대용랑 채팅 TPS에 대한 stateful 서비스 구축하기Kafka의 Pub/Sub Modeling을 활용해서, 데이터를 관리해봐요. 편에서 config.toml 파일에서 [kafka]URL 보시면 localhost:9292로 오타네요. 9092가 맞는거 아닌가요?

학습자료는 어디서 받나요?

"서버의 기본 구조 작성하기"에서 동영상 일시정지 후 다시 재생하기를 하였을때, 재생이 안되는 현상이 있습니다.새로고침 하면 문제가 해결되지만, 강의 수강중에 이런 문제가 발생하면 불편해서 보고 드립니다.참고로 다른 커리큘럼에서도 일시정지 후 일정시간 이 지나고(체감상 5분 10분정도) 재생이 안되는 현상이 있습니다.이 문제에 대해 참고해 주시면 감사하겠습니다.

강의에 음성만 있는데 영상이 없는 강의일까요? 확인해볼수 있는 방법이 없어서 문의드립니다. 감사합니다.

만약에, 채팅방에서 나눈 메시지들을 DB에 저장하고 불러온다고 하면, chan에 밀어 넣어야 하나요?

Go의 document를 살펴보면, Don't Panic 을 언급하는데, Panic - Recovery 를 사용하는 규칙이나 Best Practice가 있을까요?

defer의 사용이 자원 반환(Resource Return)의 목적으로 사용되는데, 혹시 defer 가 이뤄질 때, 현재까지 이뤄진 채팅 메시지를 저장하는 DB insert를 넣는 것은 bad practice일까요? go 명령어가 멀티 스레드를 사용할 수 있게 도와주는 키워드인데, 채팅 기능이 확장되어서 (e.g., 카카오톡) 이미지, 동영상, 이모티콘 같은 텍스트 데이터(Text Data)가 아닌 것들을 채팅서비스에서 주고받게 된다면...?

그리드 방식 소켓채팅서버를 기대하고 구매하였는데 일반적인 소켓방식이네요 ㅜㅜ혹시 그리드 방식은 어디서 배울수 있는지 알려주실수있나요. 유료라도 상관없습니다. 

안녕하세요 node js로 웹 개발을 시작하게 된 학생입니다아직 많은 정보가 없어서 node js 코드를 보면서 강의를 공부하고싶은데 리엑트 템플릿 파일 제공해준 폴더에 있는 js 코드가 node js 파일인가요??좋은 강의 감사합니다

안녕하세요 강사님 프론트 서버를 실행시켜 로컬에서 채팅을 입력하는 것은 아주 잘 동작하고 있습니다.다만 강의 제목 처럼 대용량에 대한 테스트를 하고 싶어서 부하 테스트를 구상중입니다.부하 테스트 구상 중에 포스트맨으로 소켓 연결을 할 때 궁금한 점이 생겨 질문드립니다. 우선 포스트맨으로 채팅 서버의 url (ws://localhost:1010/room-chat) 을 찔러보려 했습니다.웹소켓 연결은 잘 맺어졌는데, 테스트 메시지(test chatting send) 를 Send 하면 아래처럼 response 탭에 3개의 응답이 동시에 나옵니다.채팅서버로 텍스트를 보낸것 까진 잘 된 것 같은데 응답 받을 때는 항상 disconnected 문구가 나오네요,,제 추론으로는 포스트맨에서 테스트할 때 Room 에 대한 정보를 넣어주지 않아서 그런것 같습니다.프론트 코드 소스에서는  입장시 웹소켓이 연결되면서 방의 정보가 연동(?) 되는 것 같은데,,,그럼 포스트맨에서는 채팅방 정보를 어떻게 넣어줘야 테스트 할 수 있는지 알 수 있을까요? 

안녕하세요 강사님복습을 하다가 궁금한 점이 3가지 정도 생겨 질문드립니다.1) 채팅 유저가 최초 접속을 하면컨트롤 서버에 접속가용 가능한 채팅 서버의 주소를 응답받음해당 채팅 서버와 소켓 연결이런 흐름으로 이해했는데 맞을까요?프론트 단 코드에서는 채팅 서버와 직접 소켓 연결하는 코드만 있어서 질문드립니다. 2) 사용자가 채팅 시, 채팅 서버가 도중에 다운되면 사용자는 컨트롤 서버에 재연결 시도하여 가용가능한 채팅 서버를 재할당 받는 것인가요?3) 컨트롤 서버에 api 주소 중 /server-list 라는 api 가 있던데 해당 API 는 누가 호출하는 것인가요? 가용가능한 서버 리스트를 내려주는 API 로 이해했는데, 그럼 채팅 사용자가 해당 API 를 직접 찌르는 걸까요?

안녕하세요 강사님,지금 막 따라가고 있는 수강생들 중 한명입니다. 저는 1편은 듣지 않고 2편 부터 따라가고 있습니다. 혹시 실례가 안된다면 "처음 뵙는 분들! 이전 강의에 대한 소스코드를 간단하게 알려드릴게요"에서 나오는 코드를 파일 형태로 공유 해주실수 있을까요? 아무래도 다음에 존재하는 강의를 보다 더 수월하게 이해하고 실습하기 위해 필요할 듯 싶습니다. 감사합니다

안녕하세요 강사님 아키텍처에 궁금한 점이 생겨 질문드립니다.카프카를 사용한 이유가 채팅 서버의 상태를 비동기로 전송하기 위함이라 이해했습니다.채팅 서버가 실행/종료될 때카프카에 이벤트 발행컨트롤 서버가 이벤트 컨슈밍하며 채팅서버 상태 확인제가 제대로 이해한게 맞다면 대략 위와 같은 흐름이라 이해했습니다. 즉 채팅 서버의 상태를 컨트롤 서버에 알리기 위해 카프카라는 메시지 브로커를 둔것 같은데, 카프카를 사용하지 않고 채팅서버에서 컨트롤 서버로 직접 상태를 전송하는 방식은 불가능할까요.? 이 상황에서 카프카가 굳이 필요한건지 라는 의문이 들어 질문하게 됐습니다ㅇㅅㅇ.

[이 강의에서 다룰 zero-downtime-deploy를 위한 아키텍처 구조도를 알려드릴게요] 강의를 들으면서 컨트롤 서버의 필요성에 대해 설명해주셨습니다. 채팅 서버 1,2,3 이 다운될 때를 고려해서 로드 밸런싱 용으로 컨트롤 서버를 따로 둔다고 이해했는데, 컨트롤 서버가 배포되거나 다운되는 경우는 없을까요? 컨트롤 서버도 이중화로 구성을 해야하는 것인지, 다른 방법은 무엇이 있는지 궁금합니당 

안녕하세요.강의 잘 들었습니다.마지막에 메시지를 저장 하는 얘기를 하셨는데.. 보통 메신저 서비스에서는 어떤 방식의 DB를 사용하는지궁금합니다. 흔히 Oracle이나 MariaDB 같은 방식의 관계형 DB를 사용하는게 흔한지 아니면 Mongo같은 비관계형 방식의 DB를 많이 사용하는지 혹시 답변이 가능하시다면 답변 부탁 드립니다. 그리고 그걸 선택한 이유가 무엇인지. 감사합니다.

안녕하세요! 지난 1탄 강의 잘 들었습니다.다름이 아니라 1탄과 2탄에서 go로 작성된 코드가 조금 다른거 같은데 혹시 누락된 강의가 있는걸까요 ?1탄에선 network 디렉토리에 network.go와 socket.go만 작성했었는데 2탄에선 server.go와 util.go가 생기면서 코드가 조금 변경된거 같습니다.누락된 강의가 없다면, 변경된 부분이 어떤 것들인지 알고싶어서 질문드립니다.

안녕하세요 go 서버 구축 이후 프론트 연결하여 채팅을 전송하면 같은 메시지가 두 번씩 전송되는 현상이 발생합니다.강의를 여러 번 체크하면서 봤는데 소스 코드가 다른 점은 찾지 못했습니다. 제가 작성한 socket.go 코드인데 어떤 부분이 문제가 있을까요package network import ( "chat_server_golang/types" "log" "net/http" "time" "github.com/gin-gonic/gin" "github.com/gorilla/websocket" ) var upgrader = &websocket.Upgrader{ReadBufferSize: types.SocketBufferSize, WriteBufferSize: types.MessageBufferSize, CheckOrigin: func(r *http.Request) bool {return true}, } // http 요청을 websocket 통신으로 업그레이드 해준다. type message struct { Name string Message string Time int64 } type Room struct { Forward chan *message Join chan *client Leave chan *client Clients map[*client]bool } type client struct { Send chan *message Room *Room Name string Socket *websocket.Conn } func NewRoom() *Room { return &Room { Forward: make(chan *message), Join: make(chan *client), Leave: make(chan *client), Clients: make(map[*client]bool), } } func (c *client) Read() { // 클라이언트가 들어오는 멧세지를 읽는 작업 defer c.Socket.Close() for { var msg message err := c.Socket.ReadJSON(&msg) if err != nil { if websocket.IsUnexpectedCloseError(err, websocket.CloseGoingAway) { break } panic(err) } else { log.Println("READ : ", msg, "client", c.Name) log.Println() msg.Time = time.Now().Unix() msg.Name = c.Name c.Room.Forward <- &msg } msg.Name = c.Name c.Room.Forward <- &msg } } func (c *client) Write() { // 클라이언트가 나가는 메시지를 전송하는 작업 defer c.Socket.Close() for msg := range c.Send { log.Println("WRITE : ", msg, "client", c.Name) log.Println() err := c.Socket.WriteJSON(msg) if err != nil { panic(err) } } } func (r *Room) RunInit() { // room 에 있는 모든 채널 값을 받는 작업 // join leave 등의 메시지 큐를 처리, 무한반복문을 돌면서 처리 for { log.Println(r.Clients) log.Println(r.Forward) select { case client := <-r.Join: r.Clients[client] = true case client := <-r.Leave: r.Clients[client] = false close(client.Send) delete(r.Clients, client) case msg := <-r.Forward: for client := range r.Clients { client.Send <- msg } } } } func (r *Room) SocketServe(c *gin.Context) { socket, err := upgrader.Upgrade(c.Writer, c.Request, nil) if err != nil { panic(err) } userCookie, err := c.Request.Cookie("auth") if err != nil { panic(err) } log.Println("userCookie", userCookie) client := &client{ Socket: socket, Send: make(chan *message, types.MessageBufferSize), Room: r, Name: userCookie.Value, } r.Join <- client // 채팅방에 클라이언트가 들어왔다고 알림 defer func() { r.Leave <- client }() // 클라이언트가 나갔다고 알림, 클라이언트가 나가면서 defer 함수가 실행된다. go client.Write() client.Read() }2024/05/20 01:39:17 userCookie auth=one 2024/05/20 01:39:17 map[0x14000512600:true] 2024/05/20 01:39:17 0x14000192600 2024/05/20 01:39:21 READ : { hi 0} client one 2024/05/20 01:39:21 2024/05/20 01:39:21 map[0x14000512600:true] 2024/05/20 01:39:21 0x14000192600 2024/05/20 01:39:21 map[0x14000512600:true] 2024/05/20 01:39:21 0x14000192600 2024/05/20 01:39:21 WRITE : &{one hi 1716136761} client one 2024/05/20 01:39:21 2024/05/20 01:39:21 WRITE : &{one hi 1716136761} client one 2024/05/20 01:39:21