p2p 에서 udp를 쓰는이유??

3권에서 새로 도입된 네트웍 및 멀티플레이어 프로그로그래밍 섹션을 위한 게시판입니다.

Moderator: 류광

Locked
Testors
Posts: 557
Joined: 2003-07-26 00:34
Location: (주)nFlavor
Contact:

Post by Testors »

game state 가 패킷 하나 정도의 크기로 표현이 가능한 실시간 액션 게임의 경우 특정 시점의 정보를 수신받았다면 그 이전의 정보는 의미가 없기 때문에 게임에서의 빠른 반응을 위해서 "홀 펀칭" 같은 까다로운 기법을 구현하면서까지 UDP 를 사용합니다. 반면 TCP 의 경우는 이전에 손실된 패킷이 있다면 최근의 패킷이 이미 도착 했더라도 그것을 어플리케이션에게 전달해 주지 않고 그것을 복구하기 위해 수십에서 수백ms 를 대기하기 때문에 이런 스타일의 게임에 적합하지 않습니다. 그런데 사실 하려던 얘기는 이게 아니고,

혹시 -_-; nagle을 그고 테스트 해보신다면
얼마나 향상되는지 답글좀 부탁드립니다
ECHO 를 주고받는 프로그램을 두 머신에서 돌린다고 할때에 200ms 의 nagle 알고리즘을 켠 상태에서는 초당 5회정도의 패킷 교환이 일어나겠지만 nagle 알고리즘을 끄게 되면 네트웍이 허용하는한 최대의 횟수만큼의 패킷 교환이 일어나겠죠. (테스트 해봤었는데 수치는 1:100... 정도랄까요) 간단하게 레이턴시를 희생해서 대역폭을 좀 더 확보하는 녀석이라고 이해하시면 될겁니다. 레이턴시가 중요하다면 무조건 끄세요. 그런데 사실 하려던 얘기는 이것도 아니고,

쌀밥 wrote:앞서 제가 언급한 책에 나오는 이야기이지만,
UDP 를 사용해서 기본 UDP 기능에는 없는 많은 기능들을 추가 할 수는 있습니다.
심지어 TCP 에서만 보장된다고 생각되는 reliable 속성도 UDP 에 추가 하드 코딩을 해서 얻어 내는게 가능하기는 합니다.

[...]

제 앞글의 의도는.... 게임에서도 신뢰도는 중요하고, reliable 하게 UDP 를 수작업으로 개량시키느니 TCP 가 낳지 않은가 하는 것이었는데... 그 밖의 고려할만한 내용이 있었던 거군요.. 공부가 되었습니다..
혹시 UDP 로 reliable 한 TCP 같은것을 만들어 쓰시려거든 그냥 서버를 통해 TCP 중계를 해서 쓰시길 추천합니다. 성능이나, 안정성이나 모든 면에서 직접 구현한 reliable 프로토콜은 TCP 에 비해 뒤쳐질 것입니다.

UDP 기반으로 무언가를 만들겠다는 것은 결국 "시스템콜" 로 뭔가를 만들겠 다는 이야기인데 이는 프로토콜 성능에 있어서 절대적인 영향을 끼치는 이벤트 감지, 타이머를 모두 OS 가 제공하는것으로 쓰겠다는 얘기입니다.

200ms 의 nagle 알고리즘을 만든다고 가정합시다. 그렇다면 200ms 가 지났다는것은 어떻게 감지해야 할까요? 폴링? 아니면 Windows Timer? 어떤 것이든 커널 내에서 IP 레이어 바로 위에서 동작하고 있는 TCP 코드보다 우수할 수는 없습니다.

참고로 이전에 UDP 로 reliable 한 stream 프로토콜을 만들어본 적이 있었습니다만 그때도 issue 는 "성능" 이 아니었습니다. 굉장히 특수한 상황이었지요. 입사 이전에 게임 로비가 이미 TCP 로 구현되어 있었고 그 위에 굉장히 많은 feature 들이 완성된 상태였기에 NAT 를 뚫기 위해서는 로비를 재작성 하기 보다 UDP 로 TCP 를 에뮬레이션 하는것이 비용이 더 적게 들었습니다. 이를테면 리펙토링의 수단이랄까요..
플머/모델러/애니메이터 구해염 **현역/보충역 병특가능** / http://testors.net/
비회원

TCP와 UDP는 응용프로그램에서 송수신 루틴에서...

Post by 비회원 »

소켓통신을 작성해 보니 양파껍질 같다는 느낌이 들었습니다.

위에서 언급되어진 TCP와 UDP간의 논쟁을 본다면 라우터는 스위칭허브에서 혹은 랜카드 드라이버에서
문제가 아니라,
응용프로그램의 송수신루틴과 OS에서 처리하면서 발생하는 문제가 대부분이라는 것을 알 게 됩니다.

소켓프로그램은 복잡한 네트웍의 상황을 고려해야 합니다. 그러나 그에 비해서 송수신루틴은 단순하게 작성
되어있는 자신의 코드를 바라보면 TCP나 UDP의 논쟁보다 더 심각하다는 것을 알아야 합니다.

소켓이 OS에 따라 다르지만 전 M$사의 윈도우즈 프로그래머인데요.
winsock의 특성을 파악한다면 쓰레드와 프로세서에서 잡고 있을 때는 정상적인 소켓통신이 않된는 문제가
있습니다.
결국은 빠른시간안에 시스템으로 프로세서를 환원해야 될건데, 상당 수의 프로그래머는 프로세서의 점유와
리소스간의 동작성을 이해하지 못하고 코딩하는 것을 볼 수 있습니다.

그리고 쓰레드의 자원이 다른 쓰레드에서 사용해야 할 겨우 Attach를 해서 가져오고 Detach를 해서 환원해야
하는 것에 대한 원리를 모르고 프로그래밍하는 경우에도 자신의 코드를 탓하지 않고 시스템이나 라이브러리를
탓하는 경우도 있더군요!
네트웍및 시스템프로그램을 하신다면 멀티쓰레드와 소켓과의 상관관계에 대해서 공부해보심이 좋을 것 같습니다.
그리고 그 외의 리소스에 대해서도 쓰레드와의 상호동작성을 파악해야 됩니다.

패킷의 상당한 손실은 자신의 코드에서 비롯 된다는 것을 상기해야 합니다.

예로 UDP통신 TEST한 결과를 말씀드리면 ReceiveFrom함수로 읽을 수 있는 수신루틴보다 빠르게 계속 패킷이
유입된다면 초반엔 OS에서 버퍼링해주지만 나중에 패킷을 나려버리더군요. 이를 해결하기 위해서 수신때마다
Proxy객체를 만들어 쓰레드를 생성해서 처리 했지만 계속되는 부하에 쓰레드가 풀나는 문제가 발생해서 시스템
이 먹통이 되는 상황이 발생합니다. 곰곰히 생각하다가,
이를 보완하기 위해서 Proxy객체에 static으로 count변수를 두어 Proxy객체 수를 파악하도록해서 30개 이상이
면 잠시 sleep을 주어 해결했습니다. 여기서 sleep함수를 사용하지 않고 WaitForSingleObject함수를 사용해야
한다는 것에 윈도우 프로그래머는 주의해야 합니다.

물론 이보다 더 복잡한 과정도 있지만 이해를 돕기위해 이정도만 예를 드리는 겁니다. 이정도는 별거아니라는 분
은 어느정도 이상의 프로그래머이겠지요.

다만, 이를 보고 분발하시는 분이 있으시길 바랄 뿐 입니다.

제 ID가 secssa인데 정지 되어있다더군요...
비회원

네트웍 상태가 안좋다는 가정하에서라면..

Post by 비회원 »

안녕하세요 엄청 오래된 글들이지만 결론이 안나온거 같아서 저도 글을 적어 봅니다.

네트웍 상황이 안좋은상태에서..

tcp는 계속 보내지 못한 패킷들이 시간이 갈수록 쌓이게 될것입니다.

쉽게 얘기해서.. 격투게임에서 방향키로 계속 이동중이라는 가정하에..

최초 게임 전개시점에서는 반응이 0.1초 느렸다면.. 10초 지나고 나서는 1초가느리고..

1분지나서는 반응이 6초가 느리다는 얘기가 될수 있습니다(물론 패킷양이 작으니 실제로 그렇진 않겠지요)

다른 예로 원격제어 프로그램에서 화면을 전송하는데.. 네트웍이 너무느리다면..

시간이 지날수록 수십초 전의 화면을 볼수가 있다는 것이지요.

udp라면 네트웍 상황이 안좋다면.. 상대방 캐릭터가 워프(?) 하고 최대한 현재시점의 위치를 표시해주기때문에...

적어도 tcp에서 갈수록 오래된 화면을 봐서 게임조차 못하는 상황보다는 훨씬 낫기 때문입니다.

생방송 중계를 쏘는데 tcp를 쏘면 네트웍 상황이 안좋으면.. 20초전 화면을 보고 있지만...

udp를 쓰면.. 화면이 중간에 못보더라도 생방송(?)을 볼수 있는것이지요
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Re: 네트웍 상태가 안좋다는 가정하에서라면..

Post by myevan »

비회원 wrote:안녕하세요 엄청 오래된 글들이지만 결론이 안나온거 같아서 저도 글을 적어 봅니다.

네트웍 상황이 안좋은상태에서..

tcp는 계속 보내지 못한 패킷들이 시간이 갈수록 쌓이게 될것입니다.

쉽게 얘기해서.. 격투게임에서 방향키로 계속 이동중이라는 가정하에..

최초 게임 전개시점에서는 반응이 0.1초 느렸다면.. 10초 지나고 나서는 1초가느리고..

1분지나서는 반응이 6초가 느리다는 얘기가 될수 있습니다(물론 패킷양이 작으니 실제로 그렇진 않겠지요)

다른 예로 원격제어 프로그램에서 화면을 전송하는데.. 네트웍이 너무느리다면..

시간이 지날수록 수십초 전의 화면을 볼수가 있다는 것이지요.

udp라면 네트웍 상황이 안좋다면.. 상대방 캐릭터가 워프(?) 하고 최대한 현재시점의 위치를 표시해주기때문에...

적어도 tcp에서 갈수록 오래된 화면을 봐서 게임조차 못하는 상황보다는 훨씬 낫기 때문입니다.

생방송 중계를 쏘는데 tcp를 쏘면 네트웍 상황이 안좋으면.. 20초전 화면을 보고 있지만...

udp를 쓰면.. 화면이 중간에 못보더라도 생방송(?)을 볼수 있는것이지요
TCP 재전송에 의한 지연을 이야기하시려는 것 같습니다만;;;
예를 들어주신것처럼 지연이 점점 누적되지는 않습니다.

손실된 패킷이 있더라도 이후 도착한 패킷은 버리는게 아니라
버퍼에 쌓아놓다가 재전송에 의해 완성되면 보여주기 때문에
반응이 느린것처럼 보이는것입니다. (지연현상이 더 심할뿐이지 지연누적은 아니라는 이야기이죠)

즉, 방송을 보는데 20초 느려지는 문제는 jitter 현상 방지를 위해 버퍼링을 하기 때문으로
tcp 로 인한 현상이 아닙니다.

ps.
책에서 TCP 는 시냇물 -_-, UDP 는 택배상자-_- 라는 은유적인 표현을
정말 그렇다고 생각하고 계셨던게 아닌가 싶습니다.
빗자루네 http://www.myevan.net >_<b
비회원

Re: 네트웍 상태가 안좋다는 가정하에서라면..

Post by 비회원 »

myevan wrote:
비회원 wrote:안녕하세요 엄청 오래된 글들이지만 결론이 안나온거 같아서 저도 글을 적어 봅니다.

네트웍 상황이 안좋은상태에서..

tcp는 계속 보내지 못한 패킷들이 시간이 갈수록 쌓이게 될것입니다.

쉽게 얘기해서.. 격투게임에서 방향키로 계속 이동중이라는 가정하에..

최초 게임 전개시점에서는 반응이 0.1초 느렸다면.. 10초 지나고 나서는 1초가느리고..

1분지나서는 반응이 6초가 느리다는 얘기가 될수 있습니다(물론 패킷양이 작으니 실제로 그렇진 않겠지요)

다른 예로 원격제어 프로그램에서 화면을 전송하는데.. 네트웍이 너무느리다면..

시간이 지날수록 수십초 전의 화면을 볼수가 있다는 것이지요.

udp라면 네트웍 상황이 안좋다면.. 상대방 캐릭터가 워프(?) 하고 최대한 현재시점의 위치를 표시해주기때문에...

적어도 tcp에서 갈수록 오래된 화면을 봐서 게임조차 못하는 상황보다는 훨씬 낫기 때문입니다.

생방송 중계를 쏘는데 tcp를 쏘면 네트웍 상황이 안좋으면.. 20초전 화면을 보고 있지만...

udp를 쓰면.. 화면이 중간에 못보더라도 생방송(?)을 볼수 있는것이지요
TCP 재전송에 의한 지연을 이야기하시려는 것 같습니다만;;;
예를 들어주신것처럼 지연이 점점 누적되지는 않습니다.

손실된 패킷이 있더라도 이후 도착한 패킷은 버리는게 아니라
버퍼에 쌓아놓다가 재전송에 의해 완성되면 보여주기 때문에
반응이 느린것처럼 보이는것입니다. (지연현상이 더 심할뿐이지 지연누적은 아니라는 이야기이죠)

즉, 방송을 보는데 20초 느려지는 문제는 jitter 현상 방지를 위해 버퍼링을 하기 때문으로
tcp 로 인한 현상이 아닙니다.

ps.
책에서 TCP 는 시냇물 -_-, UDP 는 택배상자-_- 라는 은유적인 표현을
정말 그렇다고 생각하고 계셨던게 아닌가 싶습니다.
만약 네트웍 상태가 좋지 않아 트랜스포트 레이어에서 3 duplicated ack, request timeout이 수시로 발생하는 경우 (어느정도는) 지연이 누적된다고 봐야죠. 물론 window size 이상의 지연 누적은 일어나지 않겠지만 in-order delivery를 하기 위해 udp보다 더 많은 핸드셰이킹을 하는 것은 사실입니다. 게다가 fast retransmit으로 인한 congestion, bandwidth loss를 생각하면 왜 TCP를 delay sensetive한 애플리케이션에서 쓰지 않는지 알 수 있을 것 같습니다.
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Re: 네트웍 상태가 안좋다는 가정하에서라면..

Post by myevan »

비회원 wrote: 만약 네트웍 상태가 좋지 않아 트랜스포트 레이어에서 3 duplicated ack, request timeout이 수시로 발생하는 경우 (어느정도는) 지연이 누적된다고 봐야죠. 물론 window size 이상의 지연 누적은 일어나지 않겠지만 in-order delivery를 하기 위해 udp보다 더 많은 핸드셰이킹을 하는 것은 사실입니다. 게다가 fast retransmit으로 인한 congestion, bandwidth loss를 생각하면 왜 TCP를 delay sensetive한 애플리케이션에서 쓰지 않는지 알 수 있을 것 같습니다.
"누적"이란 표현은 시작부터 계속 쌓인다는 뜻입니다.
한프레임당 0.1초씩 지연이 누적되었다면 100프레임후에는 10초가 늦는다는 이야기인데
TCP 에서는 말씀하신것처럼 누적이 윈도우사이즈내에서만 발생가능하므로
네트워크 상황이 안 좋더라도 시간이 지남에 따라 점점 느려지는 현상은 발생하지 않습니다!
또한 네트워크 상황이 호전되면 지연현상이 사라지므로
"누적"된다는 표현은 적절하지 못합니다.

네트워크상태가 좋지않아 재전송이 많이 이루어지는 상황이라면
지연이 지속된다라고 표현해야겠죠 -_-);



ps.
3d 게임에서 로딩이 일어날때는
프레임이 튄다(갑자기 느려졌다 빨라졌다)라고 표현합니다.
한동안 로딩이 계속되면 매우 느리게 돌아가지만
로딩이 끝나면 다시 빨라집니다.

하지만 오브젝트가 사라지지 않는 버그가 발생해
오브젝트가 점점 늘어날 경우 프레임이 점점 느려진다(누적)라고 표현합니다.

TCP 에서 발생하는 현상은 전자에 가깝습니다.
빗자루네 http://www.myevan.net >_<b
비회원

TCP, UDP 근원적인 스토리로 들어가면..

Post by 비회원 »

TCP 프로토콜은 통신환경이 좋지 못할 경우 사용하는게 적합합니다. 태생부터가 그렇구요..

윗글중에서 네트워크 환경이 좋다면 TCP 를 쓰는것이 효과적이라고 말씀하셨는데..

제생각에는 정반대입니다. 대역폭이 충분히 확보되고, 전송지연 및 손실이 거의 발생하지 않는다면..TCP를

쓸 필요가 없죠.

P2P 게임에서 UDP 통신 하는 것은 ..reliability 측면( 전송 지연포함)에서 .. 어느정도 확보(인프라적인 측면이던, 소프우웨어 측면이든) 됐다는 전제하에 쓴다고 봅니다.

만일 신뢰성이 충분히 확보하기 어렵다고 생각될때는 TCP를 쓰는게 정답이겠죠..
비회원

Re: TCP, UDP 근원적인 스토리로 들어가면..

Post by 비회원 »

비회원 wrote:TCP 프로토콜은 통신환경이 좋지 못할 경우 사용하는게 적합합니다. 태생부터가 그렇구요..

윗글중에서 네트워크 환경이 좋다면 TCP 를 쓰는것이 효과적이라고 말씀하셨는데..

제생각에는 정반대입니다. 대역폭이 충분히 확보되고, 전송지연 및 손실이 거의 발생하지 않는다면..TCP를

쓸 필요가 없죠.

P2P 게임에서 UDP 통신 하는 것은 ..reliability 측면( 전송 지연포함)에서 .. 어느정도 확보(인프라적인 측면이던, 소프우웨어 측면이든) 됐다는 전제하에 쓴다고 봅니다.

만일 신뢰성이 충분히 확보하기 어렵다고 생각될때는 TCP를 쓰는게 정답이겠죠..

비회원님 말씀은 네트웍 환경이 좋으면 UDP를 쓰고, 안좋으면 TCP를 쓰는게 낫다는 말씀인가요?

네트웍 환경이 안좋을 때 TCP를 써서 발생되는 높은 지연은 어쩌죠? -_-;;;


유저들의 네트웍 환경을 생각해 보시길..
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Re: TCP, UDP 근원적인 스토리로 들어가면..

Post by myevan »

비회원 wrote:
비회원 wrote:TCP 프로토콜은 통신환경이 좋지 못할 경우 사용하는게 적합합니다. 태생부터가 그렇구요..

윗글중에서 네트워크 환경이 좋다면 TCP 를 쓰는것이 효과적이라고 말씀하셨는데..

제생각에는 정반대입니다. 대역폭이 충분히 확보되고, 전송지연 및 손실이 거의 발생하지 않는다면..TCP를

쓸 필요가 없죠.

P2P 게임에서 UDP 통신 하는 것은 ..reliability 측면( 전송 지연포함)에서 .. 어느정도 확보(인프라적인 측면이던, 소프우웨어 측면이든) 됐다는 전제하에 쓴다고 봅니다.

만일 신뢰성이 충분히 확보하기 어렵다고 생각될때는 TCP를 쓰는게 정답이겠죠..

비회원님 말씀은 네트웍 환경이 좋으면 UDP를 쓰고, 안좋으면 TCP를 쓰는게 낫다는 말씀인가요?

네트웍 환경이 안좋을 때 TCP를 써서 발생되는 높은 지연은 어쩌죠? -_-;;;


유저들의 네트웍 환경을 생각해 보시길..
위 비회원님이 이야기하신 네트워크 환경은
속도(latency)쪽이 아니라 신뢰성(reliability)쪽 이야기입니다.

신뢰도 높은 네트워크라면 UDP 를 사용하고
신뢰도 낮은(패킷 로스가 많거나 모두 로스되는 경우)네트워크에서는 TCP 를 통해서
낮은 반응성을 감수해서라도 게임이라도 하게 만들어주어야 한다는 것이죠;
빗자루네 http://www.myevan.net >_<b
trackback:

트랙백

Post by trackback: »

oooooxo's me2day: 시스의 생각 p2p 에서 udp를 쓰는이유?? 카트를 보면 카트 움직임등은 UDP 로. 아이템 먹고, 결승선에 골인하고 하는 중요 내용은 TCP로 이뤄져있지요
Locked