일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- spring security
- 서버개발캠프
- 개발
- 안드로이드
- 서버
- Pessimistic Lock
- JPA 동시성
- 스프링 log
- JPA 낙관적락
- Inno DB
- JPA Lock
- JPA 비관적락
- 암호화
- 스마일게이트
- Optimistic Lock
- 캠프
- JPA
- 디자인 패턴
- annotation
- bean
- Android
- 낙관적락 비관적락 차이
- 스프링
- 스프링 로그
- spring security 인증
- spring
- Transaction isolation level
- component
- Redis
- flask
- Today
- Total
모르는게 많은 개발자
[스마일게이트 서버 개발 캠프 4기]#5 몬스터 HP 동기화(TCP 소켓 통신중 의도치 않은 패킷 받을 때) 본문
프로젝트가 어느 정도 틀을 가추면서 몬스터의 HP를 동기화 작업을 실시했다.
간단히 프로세스를 말하면 다음과 같다.
1. 서버에서 클라이언트로 몬스터 생성 패킷을 Send한다. 그리고 서버에서는 각 몬스터 HP를 관리할 dic을 생성한다.
2. 클라이언트에서 몬스터를 공격시 HIT패킷을 서버로 전송.
3. 서버에서 HIT패킷을 받고 공격받은 몬스터의 HP를 깎고 HP정보를 다시 클라이언트로 전달.
문제점 : TCP로 테스트를 하던 도중 의도치 않은 패킷이 전달되는 것을 확인.
처음에는 한번에 많은 패킷이 전달되어 데이터가 변형됐나라는 생각을 했지만 TCP특성상 그건 아니라고 생각.
그래서 원인을 보기 위해 여러 테스팅을 하던 중 같은 TCP로 구현되어있는 채팅서버에 loop로 채팅을 Send해봤다.
테스트 도중 메시지가 겹쳐서 출력되는 현상을 발견했다. 여기서 TCP를 공부하며 원인을 발견했다.
원인 :
TCP는 분할 전송으로 인해 한번의 Send에 하나의 패킷을 Receive하지 않을 수 있다. 즉, 서버에서 100byte의 데이터를 Send해도 클라이언트에서는 한번의 Receive로 못 받을 수도 있다는 것이다.
즉, 위 채팅같은 경우 여러번의 Send데이터를 한번의 Receive로 받은 것으로 인해 발생긴 버그이다.
해결책 :
처음에 팀원들과 한 생각은 모든 패킷의 사이즈와 버퍼 사이즈를 같은 값으로 고정하고 receive를 받을 때 사이즈만큼만 받고 또 사이즈보다 적게 받으면 receive를 계속하는 방식을 생각했다.
하지만 멘토링을 통해 받은 해결책은 패킷에 size를 저장하고 끝단점을 넣어 패킷을 전달하는 것이다.
TCP 공부를 통해 새로 알게 된것 :
TCP의 전송은 먼저 전송한 데이터가 나중에 전달될 수 있음.
하지만 TCP에서 순서가 바뀐 패킷을 원래대로 조합해서 보내주므로 프로그래머는 순서를 신경쓸 필요 없다.
이번 버그를 해결하며 TCP에 대해 많이 공부할 수 있는 계기가 되었다.
'스마일게이트서버캠프4기' 카테고리의 다른 글
[스마일게이트 서버 개발 캠프 4기]#6 후기 (0) | 2020.03.08 |
---|---|
[스마일게이트 서버 개발 캠프 4기]#4 리눅스 ssh를 꺼도 프로세스 유지방법 (nohup) (0) | 2020.02.24 |
[스마일게이트 서버 개발 캠프 4기]#3 두번째 개인과제 리뷰(로그인 인증 서버개발) (0) | 2020.02.10 |
[스마일게이트 서버 개발 캠프 4기]#2 게임 채팅 서버 구현(로그인, 채팅) (0) | 2020.01.25 |
[스마일게이트 서버 개발 캠프 4기]#1 첫번째 개인과제 리뷰(Shortening URL) (0) | 2020.01.18 |