인프런 커뮤니티 질문&답변
작성한 질문수
Span<byte> 으로 유지해서 진행해본 결과..
작성
·
546
0
강사님 안녕하세요.
정말 즐겁게 학습 중인 수강생입니다.
강의 후반부에 유니티 연동하면서
Span<byte> 를 수정하는 방향으로 진행하는 와중에
제가 사용하는 유니티 버전에서 Span<byte>을 지원하게 되어 따로 수정하지 않고 이번 강의를 최종적으로 마무리 지었습니다.
다만, 더미 클라이언트를 마지막에 500으로 설정하고
유니티에서 실행하는데 강사님 코드로는 500개 더미 클라이언트가 가끔씩 500개가 연결되지 못한 상태로 연결됩니다.
제 코드 역시 간혹 500개가 연결되지 않습니다.
여기서 문제는...
강사님은 연결이 덜 된 클라이언트가 있어도 패킷을 모아보내기가 수월하게 동작하나,
span<byte>코드로 유지한 저는 500개도 아닌 200개 이상으로 설정하면 연결도 안 덜 되고... 패킷 모아보내기 조차 수행되지 않습니다.
윈머지를 통해서 코드는 전부 비교했으나, span<byte> 관련 부분 제외 전부 동일합니다.
500개가 항상 정상적으로 연결되지 못하는 이유가 있을까요?
혹은, 500개가 연결되지 않더라도 span을 사용했을 때와 사용하지 않았을 때의 모아보내기 가능 유무가 달라지는 이유가 어떤게 있을까요...?
어떤 차이로 혹은 어떤 곳을 의심해봐야 하는 지 여쭤봐도 될까요? 의심부분을 찾기 너무 어려워 질문 올립니다.
답변 2
1
네 버퍼 사이즈는 실제로 64KB 정도면 적당하고
너무 늘리더라도 어차피 무작정 좋은 것이 아닙니다.
네트워크 상의 TCP 커널 버퍼도 있어서 같이 상호작용을 하면서 송수신하기 때문이죠.
너무 패킷이 밀리면, 렉 상황이 발생하고 전송이 안 되는 문제가 발생합니다.
단일 패킷의 최대 크기를 너무 크게 할 경우,
실제 받는 쪽에서는 해당 패킷을 조립할 때까지 처리를 못하기 때문에
그 큰 덩어리의 패킷을 받을 때까지 다른 패킷이 밀리므로 불리한 입장이 됩니다.
간혹 경매장 리스트 같은 엄청 많은 정보를 보낼 때는 두번에 걸쳐서 보낸 기억이 있네요
1
강사님 디버깅 해보면서, sendbuffer가 4096 였던 게 문제였습니다.
더미 클라이언트가 약 400개가 넘어가면서 보내야하는 버퍼 누적 사이즈가 너무 작았던 것이 원인이었네요.
현재 누적 버퍼의 개수 < count 인 경우에서 span은 예외처리로 메세지 보내고 있어서 힌트를 얻을 수 있었습니다...
span 방식은 버퍼를 살짝 늘려줘야 하나보네요.
그냥 4096 에서 65535 로 늘려놨는데 보편적으로 이렇게 늘리면 어느 부분에서 문제가 생길 수 있는 지 추가적으로 여쭤봐도 될까요?