p2p 에서 udp를 쓰는이유??

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

Moderator: 류광

Locked
비회원

p2p 에서 udp를 쓰는이유??

Post by 비회원 »

p2p를 공부하고있습니다..


궁금한점이 생겨서 질문하나합니다.

대부분 p2p라하면 대부분 udp를 사용하는데

udp사용시 peer끼리의 연결이 매끄럽지못한 부분이 발생하는데

이런부분을 중계서버를 두어서 처리하더군요.

(공부한바로는..^^; )

여기서 궁금한점.

peer들끼리의 연결을 tcp로 하면 그런 연결부분이라던가 골치안픈부분을 생각안해도 될것같은데요

udp가 tcp보다 약간 빠르다는점을 제외하고는

신뢰도나 패킷손실이런부분에서는 tcp가 더 나아보이는데

왜 tcp는 이용하지않고

udp를 사용하는지 궁금합니다.. :o
쌀밥
Posts: 1058
Joined: 2003-02-02 20:23
Location: THQ Inc.
Contact:

Post by 쌀밥 »

저도 궁금한 부분입니다.....

(고인이 되신) 스티븐스 아저씨의 유명한 Unix Network programming 이라는 시리즈 책을 보면 udp 와 tcp 의 특징에 대해 잘 나오는데요...

이 책을 읽어보면 udp 를 도대체 쓸 이유를 못찾겠더군요...

udp는... 신뢰도가 너무 꽝이라서.. 심지어는 local 로 udp 패킷을 보내더라도 패킷 손실이 발생하지요...

일반적으로 udp 가 빠르다는 생각 때문에 udp에 기대를 거는 것 같습니다만

저라면 p2p라도 tcp 를 사용하겠습니다..
I want to live in korea, making programs, but...
http://wrice.egloos.com
비회원

Post by 비회원 »

저는 게임 프로그래밍과는 거리가 먼 학생입니다. 그래서 게임쪽으로는 특히 더 많이 틀릴 수 있습니다. :)


p2p 스타일의 게임에서 udp를 쓰는 건 전송 지연 때문인 걸로 알고 있습니다. TCP의 경우 중간에 패킷이 드랍되거나 reorder가 필요한 경우 어느 정도의 지연이 생기게 됩니다. 이 지연은 APP 레벨에서 처리할 수 없고 KERNEL이나 중간의 망단에서 처리되기 때문에 게임 프로그램에서는 손 쓸 수 없는 것이지요. 또 일반적으로 p2p를 기반으로 하는 게임의 경우는 중간에 순서가 뒤 바뀌거나 한 두 패킷이 손실되더라고 그 다음 패킷을 받아 어느정도 복구를 할 수 있다고 들었습니다. 1 2 3을 가는 게 1 3 2로 왔으면 3을 받았다면 2를 무시해도 어느정도 보정이 가능하다고 들었습니다.

그 외에 TCP에서 혼잡이 가중되어 라우터나 스위치가 버거워 하는 경우 TCP는 알아서 혼잡 회피 메커니즘을 사용하기 때문에 전송 지연 시간이 점점 길어지게 됩니다. 이 점 역시 어느정도 p2p에서 문제로 적용하지 않을까 하는 생각이 듭니다.
cocas
Posts: 34
Joined: 2005-09-27 02:58

위에 글은 제가 썼습니다.

Post by cocas »

로그인 했다고 생각했는데 비회원이네요. 어떻게 수정도 안되는 거 같고요. ㅜㅜ

제가 쓴 글입니다.
비회원

Post by 비회원 »

UDP를 쓰는 P2P게임을 거의 5년정도 서비스 중입니다.

UDP의 고질적인 문제점이 몇몇있긴합니다만..그래도 UDP를 안쓸수가 없습니다.
우선 UDP의 손실이 그리 자주 발생하지는 않습니다.
( 예를들어 두개보내면 하나는 소실된다던지 할 정도는 아닙니다. )

현재 차기작을 위해서 프로토타입을 제작중인데 서버없이 클라이언트끼리 UDP로만 전송하고 있는데..
로컬의 경우 90%이상 제대로 갑니다..

위에서 말씀하신것처럼 TCP를 안쓰는(못쓰는?) 이유는 전송지연때문입니다.

예전에 2001년쯤에 하도 방화벽과 NAT때문에 고생해서 풀 TCP로 교체해본적이 있습니다.
그당시에 제가 회사 입사하기 전이라 자세히는 모릅니다만....결과는 다시 UDP로의 회귀였습니다.

물론 모든것을 UDP로 처리하지는 않고, 게임의 흐름에 영향을 주는 이벤트의 경우(캐릭터가 죽었다던지, 중요한 물체가 파괴되었다던지 )는 서버를 경유하는 TCP를 쓰고,
그외 일반 플레이(주로 캐릭터조작)에 대한 것은 UDP로 처리하고 있습니다.
honestee
Posts: 9
Joined: 2005-01-23 21:17

Post by honestee »

위에 것들 플러스 +

tcp hole punching은 구현하기가 어려워서 그런거가 아닐까요...
꽃집총각
Posts: 55
Joined: 2003-03-29 10:26
Location: K사.
Contact:

Post by 꽃집총각 »

이거 전에 제가 viewtopic.php?t=5694 에서 로그인 안하고 썼던 글인데... 참고하세요 ^^; 저도 가슴에 썩 와닿지는 않아서 속시원한 답변은 못 드립니다만... 하하;;
3 TCP vs UDP
The diference between TCP and UDP regarding NAT gateways is bigger than one would innocently
expect. It comes from the fact that TCP does have connections and connection buildup and shutdown
sequences while UDP has not. The NAT gateway must therefore insert an entry into the translation table
when it sees a single UDP packet coming from the inside and it must use a timeout scheme to remove
these entries.
Due to this diference, the technique may work with UDP but not with TCP. We explain it for UDP and
discuss later the conditions under which TCP may also work.

3. TCP vs UDP
NAT gateway가 바라보는 TCP와 UDP의 차이점은 단순히 예상할 수 있는 것보다 더 크다. 그 차이점은 TCP는 커넥션을 가지고, connection buildup 과정과 shutdown 과정을 가지지만 UDP는 그렇지 않다는 데에서 생긴다. 따라서 NAT gateway는 사설망 내부에서 한 UDP 패킷이 온 것을 감지 했을 때 translation table에 엔트리를 삽입해야 하고, 이 엔트리를 지우기 위해서 타임아웃 체제(scheme)를 사용해야 한다.
이러한 차이점으로 인해, 이 테크닉(6-way-handshake)은 UDP에서 동작하지만, TCP에서 동작하지 않는다. 우리는 UDP를 고려한 방식을 설명 한 뒤, 이후에 TCP에서도 동작하기 위한 조건들에 대해 논의한다.
Unfortunately, this trick is even more fragile and timing-sensitive
than the UDP port number prediction trick described above. First,
all the same things can go wrong with each side's attempt to predict
the public port numbers the NATs will assign to the new sessions. In
addition, if either client's SYN arrives at the opposite NAT too
quickly, then the NAT will reject the SYN with a RST packet, causing
the local NAT in turn to close the new session. Finally, even though
support for simultaneous open is technically a mandatory part of the
TCP specification [TCP], it is not implemented correctly or at all in
many common operating systems. For this reason, this trick is
likewise mentioned here only for historical interest; it is NOT
recommended for use by applications. Applications that require
efficient, direct peer-to-peer communication should use UDP.

이 방법은 위에서 언급한 UDP 포트 번호 예측법 보다도 더욱 빈약하고(fragile) 시간에 민감하다. 우선 위에서 말한 것과 똑같이, NAT가 새로운 세션에게 부여할 공개 포트 번호를 예견하려는 시도는 실패할 수 있다. 게다가 만약 한쪽 클라이언트의 SYN이 상대편의 NAT에 너무 일찍 도착했다면, NAT는 RST 패킷을 이용해 이를 거절할 것이고, 로컬 NAT는 (SYN을 보낸 쪽의 NAT) 새로운 세션을 닫아버릴 것이다. 마지막으로 동시 오픈을 위한 지원(support)이 기술적으로 TCP 명세서에 강제된(mandatory part) 내용이라고 하더라도, 일반적으로 쓰이는 많은 OS에서 제대로 구현되어있지 않거나 아예 구현되지 않았다. 이런 이유들로 인해, 이 기법은 역사적인(historical) 흥미만을 위해 언급되었다; 응용 프로그램에서의 사용을 강력하게 비추한다. 효율성을 추구하는 응용 프로그램이라면 직접적인 p2p 통신을 위해 UDP를 사용해야 한다.
UDP Hall Punching에 대해서 다루고 있는 인터넷 상의 문서들을 보면 알고리즘에 대해서 설명하고 항상 TCP의 확장 가능성에 대해서 이야기하고 있습니다. 인용한 글들은 제가 읽어본 문서들 - 정확한 출처를 모르겠습니다. 죄송.. - 의 일부인데 (6-way-handshake 테크닉도 결국은 홀펀칭 이야기더군요.), 저도 기초지식이 부족해 가슴으로까지 이해하지는 못하겠지만 TCP를 사용하기 힘든 이유들을 설명하고 있습니다. 다만 네트웍 기초지식이 있으신 분들은 위의 글이 참고가 되실 것 같아 답변 해봅니다.

무책임하게 영어 몇 자 죽 긁어서 올려두면 괜히 답변 안하는 것만 못할 것 같아서 번역의 지존 류광님에 계신 이곳에 상당히 주제넘은 짓이오나 나름대로 번역해본 내용도 같이 올립니다. 잘못된 부분이 있으면 류광님이 수정해주실 것입니....쿨럭;;
비회원

Re: p2p 에서 udp를 쓰는이유??

Post by 비회원 »

비회원 wrote:
신뢰도나 패킷손실이런부분에서는 tcp가 더 나아보이는데

왜 tcp는 이용하지않고

udp를 사용하는지 궁금합니다.. :o
->

1. TCP 홀 펀칭이 UDP 홀 펀칭보다 훨씬 어렵습니다(TCP는 접속지향 프로토콜이기 때문에 NAT-NAT간 peer의 접속이 조금 어렵죠.. 물론 마스터 구글에게 여쭤보면 몇가지 기법들이 나와있습니다. 가장 간단한 예는 서버를 통해 해당 peer의 익스터널 IP:Port를 알아내서 그쪽으로 UDP 패킷을 쏘면서 connect()를 하면 된다는데, 이런 시간의존적 방법은 그리 좋은 방법이라 할 수 없겠죠. 그리고 NAT내부의 NAT는 역시 뚫기 힘듭니다.)

2. TCP는 기본적으로 SYN-ACK 핸드셰이킹을 통해 패킷의 유실을 방지합니다. 네트웍환경이 좋다면 이런 방법은 효과적입니다만, 네트웍 환경이 좋지않은 동남아나 중국등에서는 ping이 1초이상 나오는 곳도 있으므로, 오히려 레이턴시에 큰 영향을 줄 수 있겠죠. Nagle 알고리즘을 사용할경우 레이턴시는 더욱 길어지겠죠.

해보시면, 왜 UDP를 쓰는지 아실겁니다. 레이싱 게임같은 경우 거의 15프레임정도 이상은 동기화를 해야하는데, 1초에 TCP패킷 15번 이상 보내보십시오 :) 차가 부르스춥니다
류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

꽃집총각 wrote: 무책임하게 영어 몇 자 죽 긁어서 올려두면 괜히 답변 안하는 것만 못할 것 같아서 번역의 지존 류광님에 계신 이곳에 상당히 주제넘은 짓이오나 나름대로 번역해본 내용도 같이 올립니다. 잘못된 부분이 있으면 류광님이 수정해주실 것입니....쿨럭;;
저도 쿨럭... 그런데 원문 출처를 표기해주시면 다른 분들께 더욱 도움이 될 것입니다...
비회원

Post by 비회원 »

짧고 명확한 답변을 드리지요.

이유는 쌍방향 리얼타임 프로세싱을 지원하기 위해서랍니다.

리얼타임 프로세싱이 없다면 TCP가 훨씬 유리답니다. - NAT장비(공유기) 문제는 논의대상에 제외 시킨다는 전제하에 -

쌍방향 리얼타임을 요구하는 서비스로는 VOIP, 화상 회의 등의 멀티미디어 서비스가 있습니다. 그러면 게임은??? ^^
쌀밥
Posts: 1058
Joined: 2003-02-02 20:23
Location: THQ Inc.
Contact:

Post by 쌀밥 »

앞서 제가 언급한 책에 나오는 이야기이지만,
UDP 를 사용해서 기본 UDP 기능에는 없는 많은 기능들을 추가 할 수는 있습니다.

심지어 TCP 에서만 보장된다고 생각되는 reliable 속성도 UDP 에 추가 하드 코딩을 해서 얻어 내는게 가능하기는 합니다.
하지만, 그렇게 되면 이미 UDP 냐 TCP 냐의 논의가 아닌게 될것 같다고 생각됩니다.

tcp hole punching 은 처음 들은 것인데, 잘 이해가 안되는 군요...
오히려 (NAT 내부에서) port mapping table 을 관리한다는 측면에서는 connection-less 한 UDP 보다 TCP 가 더 좋은거 아닌가? 하는 생각이 들었는데....
글을 좀 더 읽어보려고 해도... 시간이 꽤 걸릴것 같아서.. ㅎㅎ;; (어디 좀 그림도 있고 쉬운 문서가 없을까요? ;;;; ) 못읽었습니다;;;

그리고 '쌍방향 리얼타임' 이라고 앞에분이 말씀 하셨는데, 너무 낭만적인 표현인것 같습니다.
리얼타임 네트웍이 되려면..... UDP냐 TCP 냐 하는 전송레이어 차원에서 구현될 수 있는게 아니라고 생각합니다.
그리고 '쌍방향' 이라는 표현은 어떤 의미로 쓰신건지 잘 모르겠는데, 설명을 좀 해주시면 공부가 될것 같습니다...

제 앞글의 의도는.... 게임에서도 신뢰도는 중요하고, reliable 하게 UDP 를 수작업으로 개량시키느니 TCP 가 낳지 않은가 하는 것이었는데...
그 밖의 고려할만한 내용이 있었던 거군요.. 공부가 되었습니다..
I want to live in korea, making programs, but...
http://wrice.egloos.com
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

쌀밥 wrote:제 앞글의 의도는.... 게임에서도 신뢰도는 중요하고, reliable 하게 UDP 를 수작업으로 개량시키느니 TCP 가 낳지 않은가 하는 것이었는데...
쌀밥님 글을 읽어보면... UDP를 가지고 TCP 만큼 신뢰할만한 데이터를 얻으려는 것 같습니다.
그렇다면 쌀밥님 말씀이 맞는것 같습니다...
하지만 제가 알기로는 UDP로 통신하는것은 대강 맞으면 되는 것들로 구성 되어있는걸로 알고 있습니다.
비회원 wrote:물론 모든것을 UDP로 처리하지는 않고, 게임의 흐름에 영향을 주는 이벤트의 경우(캐릭터가 죽었다던지, 중요한 물체가 파괴되었다던지 )는 서버를 경유하는 TCP를 쓰고,
그외 일반 플레이(주로 캐릭터조작)에 대한 것은 UDP로 처리하고 있습니다.
비회원님이 말씀 하신것 처럼... 움직임이 대한건 정확히 맞추는걸 포기한것 이겠죠.
(하지만 게임하긴 불편함이 없을겁니다. 네트워크 상태가 안좋다면 TCP는 더 느릴것 입니다.)
이처럼 아예 정확하지 않은 데이터라 생각하고 프로그램을 짠다면 UDP가 더 좋을것 같다는 생각이듭니다.
체크한다 해도 counter를 추가해서 이미 받았거나 이전 데이터는 무시하면 충분하지 않을까요?
단, 정확도를 포기하는 대신 중간에 패킷이 사라져도 문제없게 만들어야겠죠...
seeper0 (a) gmail.com [email주소 무단수집거부]
mesya
Posts: 268
Joined: 2005-02-28 20:08

Post by mesya »

카트를 보면 카트 움직임등은 UDP 로.
아이템 먹고, 결승선에 골인하고 하는 중요 내용은 TCP로 이뤄져있지요

제가 만드는 격투겜에서도 일반 격투내용은 UDP 로 처리하구요.
물론 가끔 손실되는 패킷이 있긴 하지만.
오히려 강제적으로 무조건 동기화를 맞추는거보다,
손실된거 무시하고 다음거 빨리 받아서 처리하는게
게임흐름상 더 낫더군용..

TCP 로 구성하면 느려서 게임 못해먹슴다.
이지노리, 김현중
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

쌍방향 리얼타임이라는 말을 저도 이해하기가 힘드네요

TCP 자체가 쌍방향 리얼타임으로 패킷 전송이 가능한 프로토콜인데 ,
UDP만 쌍방향으로 동시에 패킷을 전송할수 있다는듯한 의미로 글을 쓰신것인지 정확한 의미를 좀 알려주셨으면 좋겠고요

mesya wrote:카트를 보면 카트 움직임등은 UDP 로.
아이템 먹고, 결승선에 골인하고 하는 중요 내용은 TCP로 이뤄?逞熾?

┛?만드는 격투겜에서도 일반 격투내용은 UDP 로 처리하구요.
물론 가끔 손실되는 패킷이 있긴 하지만.
오히려 강제적으로 무조건 동기화를 맞추는거보다,
손실된거 무시하고 다음거 빨리 받아서 처리하는게
게임흐름상 더 낫더군용..

TCP 로 구성하면 느려서 게임 못해먹슴다.
격투게임에서 UDP로 처리하는 이유가 동기화를 맞추는것보다 손실된거 무시하고 다음거 받아서
처리하는게 낫다고 하셨는데

내가 상대에게 주먹을 휘둘렀는데 그것을 처리하지 않고 그냥 무시시킨다면 말이 좀 안될거 같다는
생각이 드는데....

움직임이나 처리에 약간의 지연이 있더라도, 반드시 모든 처리가 상대방과 똑같이
동기화 되어야 하는게 네트워크 게임이라 생각되는데 약간 의외라고 생각되네요

지연이 생긴건 보여지는 그림에 관한 프레임을 스킵하던가 하더라도
상대와 동기화 시키는 패킷은 빠짐 없이 받아서 제대로 처리해야 하지 않을런지요...?

동기화 처리 되지 않은 네트워크 대전 게임을 즐긴다니 상상이 가지 않습니다...




결국 TCP가 모두 처리해주는 일을 , UDP로 어플리케이션 차원에서 예외처리를 해줘야 한다는 의미 밖에
안되는거 같습니다


지연 문제는 UDP도 마찬가지로 일어나는 일이 아닌가요? 패킷 자체가 아예 안오거나 할수도 있고
순서가 뒤바귀어 올수도 있다고 기억하는데 [ TCP/IP 책을 오래전에 읽어서 ]
순서가 뒤바뀌어 처리해도 상관없는 그런 게임들이 존재하는가가 궁금합니다

"그리고 느려서 못해먹겠다" 라는 의미가
TCP가 느리다고 느끼신거 같은데 , Effective TCP/IP 책에서 보면 조건에 따라 많이 다른걸로 알고 있습니다
드문 드문 자료를 보내는 형태라면 UDP가 빠를지 모르나 지속적인 자료를 보내는 조건이라면 TCP가
더 많은 양을 보내고 처리할수 있다고 본거 같네요

한마디로 TCP가 3번 악수방법( -_-; ) 과 흐름제어를 해준다고해서 UDP보다 느릴거라고 생각하는건 오판이라고
잘 나옵니다
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

mastercho wrote:내가 상대에게 주먹을 휘둘렀는데 그것을 처리하지 않고 그냥 무시시킨다면 말이 좀 안될거 같다는
생각이 드는데....
그런데... 일반적인 유저는 그렇지 않습니다.
심하게 말하자면 결과만 맞추면됩니다.
결과가 다르면 게임이 구리다고 욕하겠지만요...
느리거나 끊기는 느낌이 있으면 상대가 똥컴이라고 욕합니다. -_-;;;;

네트워크 게임은 얼마나 정확하게 맞냐가 포인트가 아니라..
얼마나 유저들이 다른 네트워크와 똑같다고 느끼게 하는가가 포인트라고 생각합니다.
(유저를 속이는게 주목적이라고 생각됩니다.)

중간에 좀 문제 생겨서 끊기더라도... 그렇게 잦은 문제 발생은 아니라고 봅니다.
좀 문제가 발생하더라도 결과가 다르게만 안나오면 된다고 생각합니다.

카드게임이라면 완전 TCP가 좋겠죠..
격투게임도 에너지 다는것은 TCP가 좋을것 같습니다. (이건 정말 정확해야하는 부분이니까..)
하지만 움직이는 행동은 UDP로 해도 될것 같다는 생각이듭니다.
좀 다르게 되도... 유저는 자기가 보는 화면만 보기 때문에 그 안에서 어떻게던 맞추면 문제없으리라 생각됩니다.
물론 스킵되는거에 대해서는 처리를 해야할겁니다.
그리고 카운터를 만들어서 새로운 패킷이 아니면 무시하는 정도면 충분할것 같습니다.

실제 구현해보신 mesya님이 좀더 정확한 답변 해주시면 감사하겠습니다...
(저는 지금은 어찌 어찌 해서 TCP로 구현중인데.... 요즘은 UDP에 대해서 관심히 생기는군요...)
seeper0 (a) gmail.com [email주소 무단수집거부]
비회원

Post by 비회원 »

tcp는 '전송을 보장'하고 udp는 '대역을 보장'한다고 표현하지요.

회선 상태가 나빠서 초당 50kB밖에 못 보내는 상황에서 게임 상태를 전부 보내주려면 초당 100kB의 대역폭이 필요하다면, 클라이언트가 보고 있는 게임 상태는 서버와 계속해서 격차가 벌어지게 됩니다. 빠른 반응성이 필요한 게임에서 이런 상황은 재앙에 가깝죠.

그러므로 예컨대 캐릭터의 이동과 같은 지속적으로 데이터를 발생시키는 정보를 udp로 보내주되 매 패킷마다 해당 캐릭터의 절대 좌표를 넣어 보내준다면, 서버에서 보낸 100kB중에 30kB밖에 못 받았더라도 서버와 클라이언트의 상태 격차는 회선 상태가 좋을 때와 비교해서 덜 자주 갱신된다는 것만 빼면 그리 커지지 않게 됩니다. 가장 최근에 도착한 패킷의 상태로 클라이언트가 업데이트되었을테니까요.

회선 상태가 좋아서 필요한 데이터를 리얼타임으로 마구 전송할 수 있다면야 tcp가 무적이지요. 패킷 로스가 많이 발생하면 tcp는 점점 느려집니다.

그러므로 정보가 본질적으로 문맥에 관계없고 상태에 구애받지 않는다면(stateless), 즉 패킷이 소실되더라도 최종적으로 도착한 패킷으로 제대로 된 정보를 구성할 수 있다면 udp를 쓰는 편이 회선 상태가 나쁠때에도 게임을 그럭저럭 할 수 있게 하는 역할을 할 것 같습니다.

회선 상태가 좋더라도, 본질적으로 tcp쪽이 udp쪽보다 반응이 느릴 수밖에 없기 때문에 빠른 반응성을 구현하기 위해서 udp를 사용할 수도 있을 것 같네요. 그렇지만 빠른 반응성이 정교한 동작을 수반하지 않는다면 게임성에 긍정적인 영향을 미칠지는 잘 모르겠습니다. udp로 인한 패킷 로스는 정교한 동작을 구현할 수 없게 만들 것 같은데요.
mastercho wrote:쌍방향 리얼타임이라는 말을 저도 이해하기가 힘드네요

TCP 자체가 쌍방향 리얼타임으로 패킷 전송이 가능한 프로토콜인데 ,
UDP만 쌍방향으로 동시에 패킷을 전송할수 있다는듯한 의미로 글을 쓰신것인지 정확한 의미를 좀 알려주셨으면 좋겠고요

mesya wrote:카트를 보면 카트 움직임등은 UDP 로.
아이템 먹고, 결승선에 골인하고 하는 중요 내용은 TCP로 이뤄?逞熾?

┛?만드는 격투겜에서도 일반 격투내용은 UDP 로 처리하구요.
물론 가끔 손실되는 패킷이 있긴 하지만.
오히려 강제적으로 무조건 동기화를 맞추는거보다,
손실된거 무시하고 다음거 빨리 받아서 처리하는게
게임흐름상 더 낫더군용..

TCP 로 구성하면 느려서 게임 못해먹슴다.
격투게임에서 UDP로 처리하는 이유가 동기화를 맞추는것보다 손실된거 무시하고 다음거 받아서
처리하는게 낫다고 하셨는데

내가 상대에게 주먹을 휘둘렀는데 그것을 처리하지 않고 그냥 무시시킨다면 말이 좀 안될거 같다는
생각이 드는데....

움직임이나 처리에 약간의 지연이 있더라도, 반드시 모든 처리가 상대방과 똑같이
동기화 되어야 하는게 네트워크 게임이라 생각되는데 약간 의외라고 생각되네요

지연이 생긴건 보여지는 그림에 관한 프레임을 스킵하던가 하더라도
상대와 동기화 시키는 패킷은 빠짐 없이 받아서 제대로 처리해야 하지 않을런지요...?

동기화 처리 되지 않은 네트워크 대전 게임을 즐긴다니 상상이 가지 않습니다...




결국 TCP가 모두 처리해주는 일을 , UDP로 어플리케이션 차원에서 예외처리를 해줘야 한다는 의미 밖에
안되는거 같습니다


지연 문제는 UDP도 마찬가지로 일어나는 일이 아닌가요? 패킷 자체가 아예 안오거나 할수도 있고
순서가 뒤바귀어 올수도 있다고 기억하는데 [ TCP/IP 책을 오래전에 읽어서 ]
순서가 뒤바뀌어 처리해도 상관없는 그런 게임들이 존재하는가가 궁금합니다

"그리고 느려서 못해먹겠다" 라는 의미가
TCP가 느리다고 느끼신거 같은데 , Effective TCP/IP 책에서 보면 조건에 따라 많이 다른걸로 알고 있습니다
드문 드문 자료를 보내는 형태라면 UDP가 빠를지 모르나 지속적인 자료를 보내는 조건이라면 TCP가
더 많은 양을 보내고 처리할수 있다고 본거 같네요

한마디로 TCP가 3번 악수방법( -_-; ) 과 흐름제어를 해준다고해서 UDP보다 느릴거라고 생각하는건 오판이라고
잘 나옵니다
mesya
Posts: 268
Joined: 2005-02-28 20:08

Post by mesya »

글쎄요, 이론상으로 어떤게 맞을지는 모르겠습니다만.
제가 격투겜(허접하지만)을 하니까, 격투겜 기준으로 얘기하자면..

유저들에게 있어서 가장 중요한건 자신이 입력한 동작을
최대한 빨리 반응해줘야 한다는 부분인거 같거든요.
동기를 맞추려다보면, 아무래도 느려지거나,
중간중간 이상한 렉이 발생할 수밖에 없죠.
그순간엔 제가 입력한대로 동작안한다던지 하는..

완벽한 동기화를 원하는건 개발자의 입장이구요.
유저의 입장에선 사소한 동기화는 무시해버리는게 나은 방법 같단
결론이었습니다. 개인적으로요.

패킷몇개 보내고 받고만 테스트 해보셔도.
반응속도가 UDP 가 우수한걸 느낄 수 있으실거에요.

물론 가끔 패킷손실되곤 하지만.
자주 손실되는게 아니랍니다..

그래서 정확하지 않아도 큰 문제없는 정보는 UDP 를 통해
부드럽고 빠른 동작이 되도록 해주는게 좋죠.

UDP 의 경우, 주먹을 휘둘렀는데, 패킷이 안가서
상대방에겐 내가 주먹을 안휘두른게 될 수도 있지요.
게임 한판 하는데 한두번정도 이런 현상이 있을 수 있습니다.

그래도, 완벽한 동기화를 위해 중간중간 게임이 멈춘다던지,
혹은, 반응이 내가 입력한 한참후에 이뤄지는것보단 낫지 않을까요.

이론적인건 잘 모르구요, 어디까지나 제 개인적인 주장입니다 ㅎㅎ
이지노리, 김현중
비회원

Post by 비회원 »

비회원 wrote:tcp는 '전송을 보장'하고 udp는 '대역을 보장'한다고 표현하지요.

회선 상태가 나빠서 초당 50kB밖에 못 보내는 상황에서 게임 상태를 전부 보내주려면 초당 100kB의 대역폭이 필요하다면, 클라이언트가 보고 있는 게임 상태는 서버와 계속해서 격차가 벌어지게 됩니다. 빠른 반응성이 필요한 게임에서 이런 상황은 재앙에 가깝죠.

그러므로 예컨대 캐릭터의 이동과 같은 지속적으로 데이터를 발생시키는 정보를 udp로 보내주되 매 패킷마다 해당 캐릭터의 절대 좌표를 넣어 보내준다면, 서버에서 보낸 100kB중에 30kB밖에 못 받았더라도 서버와 클라이언트의 상태 격차는 회선 상태가 좋을 때와 비교해서 덜 자주 갱신된다는 것만 빼면 그리 커지지 않게 됩니다. 가장 최근에 도착한 패킷의 상태로 클라이언트가 업데이트되었을테니까요.

회선 상태가 좋아서 필요한 데이터를 리얼타임으로 마구 전송할 수 있다면야 tcp가 무적이지요. 패킷 로스가 많이 발생하면 tcp는 점점 느려집니다.

그러므로 정보가 본질적으로 문맥에 관계없고 상태에 구애받지 않는다면(stateless), 즉 패킷이 소실되더라도 최종적으로 도착한 패킷으로 제대로 된 정보를 구성할 수 있다면 udp를 쓰는 편이 회선 상태가 나쁠때에도 게임을 그럭저럭 할 수 있게 하는 역할을 할 것 같습니다.

회선 상태가 좋더라도, 본질적으로 tcp쪽이 udp쪽보다 반응이 느릴 수밖에 없기 때문에 빠른 반응성을 구현하기 위해서 udp를 사용할 수도 있을 것 같네요. 그렇지만 빠른 반응성이 정교한 동작을 수반하지 않는다면 게임성에 긍정적인 영향을 미칠지는 잘 모르겠습니다. udp로 인한 패킷 로스는 정교한 동작을 구현할 수 없게 만들 것 같은데요.
대역폭 문제는 UDP가 더 문제가 되는게 아닌지 궁금하네요

TCP는 대역폭이 작아도 잘개 쪼개 보내질수 있지만 , 대역폭이 작을 경우 UDP는 쪼개서 보내질수 없기때문에
더 큰 문제가 되는게 아닌지 궁금하네요


TCP/IP책은 대학교 시절에 봤던지라 , 회사에 책이 없어서 확인은 못하겠지만

대역폭이 안될정도의 큰 패킷을 보낼때는 TCP 경우 쪼개서 보내고 나중에 그걸 합칠수도 있지만
UDP는 패킷 크기의 대역폭이 있지 않으면 전송이 불가능한걸로 알고 있는데 제가 잘못 기억하고 있는것일까요?
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

비회원 wrote:TCP는 대역폭이 작아도 잘개 쪼개 보내질수 있지만 , 대역폭이 작을 경우 UDP는 쪼개서 보내질수 없기때문에
더 큰 문제가 되는게 아닌지 궁금하네요
만약 다른 어플리케이션이라면 모르겠지만...
게임이라는 특수한 상황이라면.... 애초에 작은 패킷이니 상관없는것 아닌가요?
seeper0 (a) gmail.com [email주소 무단수집거부]
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

mesya wrote:글쎄요, 이론상으로 어떤게 맞을지는 모르겠습니다만.
제가 격투겜(허접하지만)을 하니까, 격투겜 기준으로 얘기하자면..

유저들에게 있어서 가장 중요한건 자신이 입력한 동작을
최대한 빨리 반응해줘야 한다는 부분인거 같거든요.
동기를 맞추려다보면, 아무래도 느려지거나,
중간중간 이상한 렉이 발생할 수밖에 없죠.
그순간엔 제가 입력한대로 동작안한다던지 하는..

완벽한 동기화를 원하는건 개발자의 입장이구요.
유저의 입장에선 사소한 동기화는 무시해버리는게 나은 방법 같단
결론이었습니다. 개인적으로요.

패킷몇개 보내고 받고만 테스트 해보셔도.
반응속도가 UDP 가 우수한걸 느낄 수 있으실거에요.

물론 가끔 패킷손실되곤 하지만.
자주 손실되는게 아니랍니다..

그래서 정확하지 않아도 큰 문제없는 정보는 UDP 를 통해
부드럽고 빠른 동작이 되도록 해주는게 좋죠.

UDP 의 경우, 주먹을 휘둘렀는데, 패킷이 안가서
상대방에겐 내가 주먹을 안휘두른게 될 수도 있지요.
게임 한판 하는데 한두번정도 이런 현상이 있을 수 있습니다.

그래도, 완벽한 동기화를 위해 중간중간 게임이 멈춘다던지,
혹은, 반응이 내가 입력한 한참후에 이뤄지는것보단 낫지 않을까요.

이론적인건 잘 모르구요, 어디까지나 제 개인적인 주장입니다 ㅎㅎ
mastercho wrote:대역폭 문제는 UDP가 더 문제가 되는게 아닌지 궁금하네요

TCP는 대역폭이 작아도 잘개 쪼개 보내질수 있지만 , 대역폭이 작을 경우 UDP는 쪼개서 보내질수 없기때문에
더 큰 문제가 되는게 아닌지 궁금하네요


TCP/IP책은 대학교 시절에 봤던지라 , 회사에 책이 없어서 확인은 못하겠지만

대역폭이 안될정도의 큰 패킷을 보낼때는 TCP 경우 쪼개서 보내고 나중에 그걸 합칠수도 있지만
UDP는 패킷 크기의 대역폭이 있지 않으면 전송이 불가능한걸로 알고 있는데 제가 잘못 기억하고 있는것일까요?
윗글은 제가 로그인 안하고 남긴글이고요

mesya님에게 궁금한것은 TCP를 반드시 써야 하는부분이 있다면 TCP로 그냥 모두 처리하게 어떨지 궁금해서 그런거거든요

말씀하신데로 패킷 손실이 거의 없다면 TCP 또한 패킷 손실로 지연되는 경우가 거의 없다고 봐야 하는데
TCP , UDP 소켓 둘다 열어서 까지 통신을 해야한다는것은 좀 힘들지 않을가 싶어서입니다

어째건 다른 방식의 소켓을 여러개 열어서 쓰는게 어플리케이션 유지보수 차원에서 힘들지 않는가도 궁금하네요


학교 다닐때 연습용으로 서버 프로그래밍만 해봐서... 하여튼 이런 의문이 생기네요
Last edited by mastercho on 2005-09-28 20:56, edited 1 time in total.
Locked