주특기 플러스 톺아보기 - 1주차
이번에 쓸 패킷 구조는 조금 달라요 - totalLenth와 handlerId
공룡점프때 쓰던 패킷 구조는 이렇게 생겼었는데,
이번 tcp_echo에서 쓸 패킷 구조는 이렇게 생겼다.
사실 핸들러 ID나 그런거 보면 크게 다르진 않은데, 이번 패킷 구조는 크게 '헤더' 부분과 '메세지' 부분으로 나눠진다. totalLength + handlerId를 한번에 묶어 헤더로 보는 셈.
명세서에서 길이 4바이트, 핸들러ID 2바이트로 고정해줬으니 헤더도 6바이트로 고정된 셈.
그러면 패킷 용량이 아무리 커져도 앞에서 6바이트(헤더) 만큼만 뜯어내고 나면 나머지는 다 메시지가 된다는 얘기.
subarray()에서 startNumber를 입력하니 콘솔로그에 문자열이 나오지 않는다
이렇게 적어줬더니 콘솔로그가 아래처럼 나왔다.
메시지가 비어있네?!
이렇게 적어주니 아래처럼 잘 나왔다.
메시지 출력 확인.
Error: 라고 쓴건 왜 안 나오고, length와 handlerID는 왜 이상할까?
분명히 서버단에서는 코드를 이렇게 작성해 주었는데,
클라단에서 이렇게 나온다. 왜일까?
-> 우리 원래 서버든 클라든 줄때 버퍼로 감싸고, 헤더 만들고, 헤더랑 버퍼 합쳐 패킷으로 조립한 다음에 socket.write() 로 보냈었다.
그런데 이건 최대 메시지 길이 초과할 경우 그냥 콘솔로그처럼 메시지를 직접 갖다 꽂고 있기 때문에 문제? 라면 문제인 것.
-> 서버단에서는 헤더고 패킷이고 하는 작업 없이 그냥 스트링을 주고 있는데, 클라에서는 써있는 로직대로 똑같이 패킷 쪼개는 것 마냥 헤더니 메시지니 분리해서 그렇다.
그렇게 6바이트만클 썰려나간게 저 Error: 부분이라서 저기가 날아간 것.
handler(message) 라고 썼는데 어떻게 되는거지? 🤔
핸들러가 이렇게 선언되어 있고,
responseMessage는 이렇게 선언되어 있는데 구조가 잘 이해되지 않았다.🤔 이건 핸들러 맵핑 내용이라 handlers의 index.js를 보고 이해를 시도해 보았다.
-> handlers[10] 이면 handler10 이라는 메서드를 호출해주는 것이고,
트러블 슈팅
왜 자꾸 메인브랜치가 master로 잡혀? - git config를 바꿔주자
이전에는 그런 적 없었는데 최근 git의 로컬브랜치 이름이 자꾸 master로 되어 있어서 git checkout -b main 후 push하고 git branch -d master 하느라 여간 번거로운 게 아니었다.
참고 블로그 를 통해 해결했다.
git config --global init.defaultBranch main을 입력한다.~/.gitconfig를 입력해서 config 상태를 확인한다.
아마 init 시의 설정 브랜치가 master로 되어 있었나보다. 현재는 main으로 잘 수정된 상황.
