p2p 에서 udp를 쓰는이유??

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

Moderator: 류광

Locked
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

seeper wrote:
비회원 wrote:TCP는 대역폭이 작아도 잘개 쪼개 보내질수 있지만 , 대역폭이 작을 경우 UDP는 쪼개서 보내질수 없기때문에
더 큰 문제가 되는게 아닌지 궁금하네요
만약 다른 어플리케이션이라면 모르겠지만...
게임이라는 특수한 상황이라면.... 애초에 작은 패킷이니 상관없는것 아닌가요?
애초에 작은 패킷이라면 위에 비회원분이 말씀 하신 대역폭에 관한 내용은 의미가 없다는거로 인식해도 될런지요?
아제나
Posts: 155
Joined: 2005-08-01 11:07
Location: 프로그래머
Contact:

UDP를 쓰는 가장 큰 이유는...

Post by 아제나 »

윗분도 언급하셨듯이 홀 펀칭 기술 때문이죠.

서버를 통하지 않고 사설 대 사설에서 1:1 통신을 하려면 홀 펀칭 기술이 필요한데

TCP로 이걸 구현하려면 로 소켓을 만져야 하므로 매우매우 복잡하기 때문일 겁니다.

FPS나 액션 게임의 경우 중간에 리얼 ip를 소유하고 있는 서버가 데이터를 중계해주면

무지 느리겠죠. 물론 이것도 고스트 알고리즘 등으로 잘 포장하면 모르겠지만

요즘 같이 공유기가 보편화된 세상에서 UDP 홀펀칭 기술을 안쓰면 네트워크 게임을

만들기에 에로사항이 꽃피겠죠.

홀 펀칭을 안쓸려면 P2P 방식으로 안하고 중앙 서버를 둬서 다 처리하던지요. (돈이 엄청 들겠죠)

이것이 신뢰성이나 다른 것을 포기하고라도 UDP를 쓰는 이유가 아닐까 합니다.
Programmer's Life 아제나
seeper
Posts: 1483
Joined: 2003-06-06 23:19
Contact:

Post by seeper »

mastercho wrote:
seeper wrote:
비회원 wrote:TCP는 대역폭이 작아도 잘개 쪼개 보내질수 있지만 , 대역폭이 작을 경우 UDP는 쪼개서 보내질수 없기때문에
더 큰 문제가 되는게 아닌지 궁금하네요
만약 다른 어플리케이션이라면 모르겠지만...
게임이라는 특수한 상황이라면.... 애초에 작은 패킷이니 상관없는것 아닌가요?
애초에 작은 패킷이라면 위에 비회원분이 말씀 하신 대역폭에 관한 내용은 의미가 없다는거로 인식해도 될런지요?
처음에 비회원님의 어떤 의도로 이야기한지는 사실 잘 모르겠습니다.. ^^;;
하지만 게임 UDP 패킷이 작아야한다는 전제가 빠진것 같아서 올린것 입니다.

전체적인 내용은 UDP가 게임에서 작은 패킷으로 만들고..
생각보다 유실되는 부분이 많지 않기 때문에 부분적으로는 유용하다는 거니까요...
물론 복잡도가 증가할거긴 합니다만... 그 만큼 매리트가 있다고 생각됩니다.
실제로도 요즘 많은 게임들이 UDP 지원하잖아요?
물론 P2P에도 꽤 좋죠...
seeper0 (a) gmail.com [email주소 무단수집거부]
쌀밥
Posts: 1058
Joined: 2003-02-02 20:23
Location: THQ Inc.
Contact:

Post by 쌀밥 »

비회원 wrote:대역폭이 안될정도의 큰 패킷을 보낼때는 TCP 경우 쪼개서 보내고 나중에 그걸 합칠수도 있지만
UDP는 패킷 크기의 대역폭이 있지 않으면 전송이 불가능한걸로 알고 있는데 제가 잘못 기억하고 있는것일까요?
이거 사실 여부 좀 확인 해주셨으면 좋겠습니다.

제가 아는 지식으로는.. (사실 네퉉 쪽 만진지가 3년가까이 되어서;; )
Datagram 도 쪼개 질 수 있습니다.
Fragment offset 과 Identification 값으로 복구 할때 필요한 정보를 담는 거죠..
제가 틀렸다면 알려주세요.. 워낙 오래되서;;;


그리고 누가 hole 펀칭에 대해서 설명좀 해주세요.
아니면 설명된 페이지 링크라도 좀 알려주세요..
잘 이해가 안되고 있습니다...

제가 아는 상식에서는 UDP 는 connection 이 유지 되지 않기 때문에
받는 측이 NAT 안에 있다면 데이터 전송이 안될것 같은데요...
그러니 UDP 로 하게 되면 둘중에 한 쪽이라도 NAT 를 사용하면 데이터 전송이 안되는거 아닌가요??;;;
I want to live in korea, making programs, but...
http://wrice.egloos.com
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

Datagram 도 "하부단계에서는 쪼개져서 전달된다" 라는게
viewtopic.php?t=6131&highlight=udp
요기에서 논의된적이 있습니다만;; 상세한 하부구조는 장비제작하시는분들에게 필요한 내용일듯하고;
어플만드는 분들입장에서는 안전한 UDP 패킷 사이즈와 쪼개지더라도 하부단계에서 합쳐지므로
소켓인터페이스상으로는 보낸 패킷 통째로 받을 수 있다라는 사실에만 주목하면 될것 같습니다.
(자칫 오해의 소지가 있을 수 있기때문에;; )

홀펀칭이라는게 제가 생각하는게 맞는지는 모르겠습니다만;
NAT라 할지라도 내부에서 UDP로 send하면, 외부에서 수신할 수있고,
바로 응답을 하면 NAT내부에서 수신이 가능합니다.

이것은 UDP패킷을 보낼때, 라우팅되는 경로 장비에 포트가 동적으로 할당되기때문인데,
장비마다 다르지만 잠시동안 이 포트가 유지되며, 이 구멍을 통해 제 3자도 NAT내부에 UDP패킷을 보낼수 있습니다.
... 하지만; 방화벽으로 막으면 좌절orz 인데;; 불행히도 제가 작업할 당시 최근 공유기들은 방화벽 디폴트로 계속 나오면서
... ;; 그러면서 uPnP 니 하는 개념도 같이 나오곤 했는데; 이후로는 udp작업을 안해봐서 잘 모르겠습니다 -_-);;


ps.
아 - - 숙제해야하는데; 큰일;; 날새야하나...
빗자루네 http://www.myevan.net >_<b
비회원

Post by 비회원 »

쌀밥 wrote:그리고 누가 hole 펀칭에 대해서 설명좀 해주세요.
아니면 설명된 페이지 링크라도 좀 알려주세요..
잘 이해가 안되고 있습니다...

제가 아는 상식에서는 UDP 는 connection 이 유지 되지 않기 때문에
받는 측이 NAT 안에 있다면 데이터 전송이 안될것 같은데요...
그러니 UDP 로 하게 되면 둘중에 한 쪽이라도 NAT 를 사용하면 데이터 전송이 안되는거 아닌가요??;;;
안녕하세요 NAT문제때문에 여전히 고민중인 해키스트입니다.

1. http://gpgstudy.com/forum/viewtopic.php?t=6351 참고해보시구요,

마스터 구글에게 "Peer-to-Peer Communication Across Network Address Translators"라는 문서를 찾아주시옵소서~ 라고 부탁하시면 마스터 구글이 친절이 찾아주실겁니다. 이 문서에 TCP 홀 펀칭이나 UDP 홀 펀칭 기법에 대해 자세히 나와있습니다.

2. TCP 커넥션과 UDP 커넥션을 같이 쓰는게 네떡 라입이 잘 만들어져 있다면 그리 어려운것도 아닙니다.

3. udp 패킷을 쪼개는건 소켓 API상에서는 불가능할거 같구요 그냥 보낸 사이즈만큼 받는다라고 생각하는게 편할듯합니다. 못받을수도 있구요 ㅋ

4. uPnP에 대해서 연구해 보았습니다. 일단 윈도 2000이하 유저는 uPnP의 혜택을 받지 못하고, NAT장비가 uPnP를 지원해야 합니다. 가장 중요한건, uPnP는 관련 자료 구하기가 힘이듭니다-_-;; 요즘은 게임보단 유비쿼터스 환경에서 더 고려하는거 같더군요. 랜만꼽으면 네트웍에 연결된다는 발상은 PnP이후 매우 혁신적이니까요. 혹시 uPnP를 이용한 구현경험이나 관련자료 있으신 분은 공유 부탁드립니다. 저도 드릴 수 있는 자료 드릴게요.

p.s 요즘은 로긴이 귀찮군요. 위에 홀펀칭 어쩌고도 제가썼습니다. 다른 NAT 타입의 홀 펀칭은 완료되었으나 SNAT라는 강적을 만나 결국 중계서버를 제작중에 있죠. 근데 중계서버도 처리해야 할 돌연한 case들이 많아 악전고투중입니다.
쌀밥
Posts: 1058
Joined: 2003-02-02 20:23
Location: THQ Inc.
Contact:

홀 펀칭에 대해..

Post by 쌀밥 »

myevan wrote:홀펀칭이라는게 제가 생각하는게 맞는지는 모르겠습니다만;
NAT라 할지라도 내부에서 UDP로 send하면, 외부에서 수신할 수있고,
바로 응답을 하면 NAT내부에서 수신이 가능합니다.
설명해주셔서 감사합니다.
그런데, 저도 구글님께서 알려주신 내용을 읽고 그렇게 해석 했었는데,
(처음 읽었을때 상당히 놀랐음)
그러면 이야기가 앞뒤가 안 맞는 느낌입니다..;

TCP 로 하면 NAT 내부에서 외부로 connection 이 성립되면 데이터를 받는 것은 당연히 되지요..
UDP 가 홀 펀칭이 되기 때문에 TCP 보다 좋다는 말은 성립이 안되는데요...;
제가 어딘가에서 잘 못 이해한건가요???

*PS: 이해 했습니다. 아.. 신기하네요...
Last edited by 쌀밥 on 2005-09-29 00:31, edited 1 time in total.
I want to live in korea, making programs, but...
http://wrice.egloos.com
myevan
Posts: 1314
Joined: 2003-03-04 10:21
Contact:

Post by myevan »

"A-B 두 당사자가 아닌; 제 3의 C나 D가 B가 열어놓은 구멍을 통해; 넣을 수있다! -_-)o"

포인트를 강조하자면 이렇습니다.

TCP의 경우 서로 연결된 스트림에 다른 스트림이 끼어들 방법은 좀 많이 애매하죠 ~(-_-)~;;

UDP의 경우는
A: 야-_- 패킷 보냈다
B: 어라 50번 포트로 보냈네? 자 -_-)/ 이제부터 다들 A에게 보내려면 xxx.xxx.xxx.xxx의 50번 포트로 쏴라!
C: 오케바리 -_-)~ 나도 A에게 슥 ~(-_-)~
A: C가 보낸 패킷 수신확인 -_-)/
D: 나도 보내도 돼나 = =)? ~(-_-)~ 슥
A: D가 보낸 패킷도 확인 -_-)/
B: 하지만 문이 언제 닫힐지 모르니 나와의 A와의 관계는 계속 유지하도록 하지 -_-)~
이런 스토리를 가볍게 전개할 수 있습니다. (sendto 는 수신포트를 세팅할수 있죠; )
빗자루네 http://www.myevan.net >_<b
쌀밥
Posts: 1058
Joined: 2003-02-02 20:23
Location: THQ Inc.
Contact:

Post by 쌀밥 »

udp hole punching ...
새로운거 배웠습니다!!!!
생각할 수록 신기하네요...

네퉉 공부 한참 한게 2000년도인데
그때는 공유기 보급도 별로 안되고 그래서 이런게 없었는데...

아무튼 udp 가 갑자기 예뻐 보이네요...;;;
I want to live in korea, making programs, but...
http://wrice.egloos.com
cronan
Posts: 18
Joined: 2003-05-14 03:17

myevan님 말씀대로..

Post by cronan »

UDP로 하더라도 TCP에 비해 신뢰할 수 없는 패킷을 받을 수 있기 때문에
언젠가는 TCP에서 구현한 것들의 어느정도는 UDP에서 구현해야 할 필요가
있습니다. 원래 이런 것들이 TCP에 포함되어 있으니까요.. (이 패킷을 보내는
자가 진짜 내가 받아야 할 자인가? 라든지..)

커넥션을 만들고 하는데는 TCP가 확실히 오래 걸리고 상황이 아주 안좋은
상황, 간단히 한국 내의 상황이 아닌 경우에는 TCP를 쓰든 UDP를 쓰든
굉장히 암울하게 될 수 밖에 없습니다... 실제로 bandwidth와 latancy는
아주 다른 개념이니까요.. 다시 생각하면 생각보다 TCP 패킷이 바보처럼
만들어지지 않았기 때문에 많은 사람들이 사용하게 되었다 라고 현시대적?
으로 생각할 수 있습니다..

핸드쉐이크 과정이 매 패킷마다 있는 것이 아니라 잘못됐을 때에만 많이
일어나기 때문에 어느정도 안정적인 회선에서는 TCP나 UDP나 거기서
거기의 성능을 낸다고 보여 집니다..

간단한 예로, 지구 반대편 미국에서 자료를 받아도 패킷 로스만 없으면
굉장히 빠르게 받을 수 있으니까요. ^^ 불과 5년 전까지만 해도 이정도
대역폭도 해외와 맺어두지 않았었었으니까요...
Hanju Kim
비회원

Post by 비회원 »

대역을 보장한다는 말을 사용했던 사람입니다.

지금 대역폭이라는 말이 같은 의미로 사용되고 있는지 궁금하네요. 대역폭은 말 그대로 '단위시간당 얼마의 데이터를 전송하는가'라는 의미입니다. 한번에 보낼 수 있는 패킷의 크기가 *아닙니다*.

tcp는 전송을 보장해야 하기 때문에 중간에 패킷 로스가 발생하면 다 보낼때까지 계속해서 재시도를 합니다. 반면 udp는 정보를 보내면 패킷 로스가 되건말건 계속 보내지요.

빠른 반응성이 필요한 게임은, 패킷 로스가 되어 과거의 데이터를 시간 안에 보내지 못했을 경우, 이미 과거의 데이터는 '만료'된 데이터로 간주하고 최신의 데이터를 바로바로 보내는 편이 나은 경우가 많다는 것입니다. tcp의 경우 이미 과거의 데이터라고 해도 한번 보내기를 시도한 데이터는 프로토콜단에서 끝까지 보내려고 시도하지요.

NAT홀 펀칭과 같은 편법은 부차적인 문제입니다. tcp와 udp의 궁극적인 차이, 두 프로토콜을 따로 둔 궁극적인 목표는 여기 있습니다.

온라인 게임은 인터넷 생중계와 비슷한 면이 있습니다. 서버에 있는 가상 월드의 상태를 클라이언트에 생중계하는 것이죠. 생중계하는데 회선 상태 이상으로 최근 5초간의 정보를 받지 못했을 경우 그 5초간의 월드의 변경을 하나하나 다 받는것보단 현재의 상태만을 받는 것이 훨씬 이득입니다. TV생방송의 경우 5초정도의 딜레이는 무시할만 할지 모르지만 인터랙티브한 온라인게임에서는 1초의 딜레이도 큰 타격이 됩니다.

tcp는 월드의 상태를 계속 중계하면 5초건 10초건 그동안 보내려고 시도했던 것을 다 보내려고 시도하는 것이고, udp는 5초간 보낸게 안 갔다면 지금 보낸것부터라도 잘 받으라고 하는 것이지요. tcp의 경우 회선 상태가 안 좋으면 당연히 이 딜레이는 점점 더 커집니다. 곧 버퍼 오버플로우로 연결이 끊기겠지요. udp는 5초에 한번씩 클라이언트가 갱신되는 한이 있어도 지속적으로 정보를 받을 수 있습니다.

물론 udp로 월드를 중계한다면 패킷 설계를 잘 해야 합니다. 그 5초간의 정보가 없으면 최신의 패킷을 받아도 월드를 구성할 방법이 없다면 말짱 꽝이겠지요. 패킷 하나하나가 이전에 갔던 패킷과 독립적이도록 설계하여 패킷 로스를 신경쓰지 않고 날아오는 패킷만 처리하면 되도록 해야겠지요. 이게 불가능한 정보는 tcp를 통하도록 하면 되고요.

그래서 많은 게임들이 일상적인 이동과 같은 정보는 udp로 전송하고 잃어버려서는 안되는 중요한 정보들은 tcp로 전송하는 것이겠지요.
비회원 wrote:
비회원 wrote:tcp는 '전송을 보장'하고 udp는 '대역을 보장'한다고 표현하지요.

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

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

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

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

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

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


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

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

Post by 쌀밥 »

다른 질문을 추가하는게 되겠습니다만..


UDP 프로그래밍과 관련해서 기능을 쉽게 추가하거나 빼거나 할 수 있는 라이브러리가 있습니까???
제 생각에는 Loki 처럼 Policy 단위 전략으로 기능을 빼거나 추가하는 형태의 라이브러리 제작이 가능하지 않을까 생각되는데요...
아시면 좀 추천해주세요...

UDP 의 단점은 역시 개발 비용에 TCP 보다 많이 든다는 점이라고 생각합니다.
만약 편리하고 안정적인 UDP 관련 라이브러리가 있다면 알려주세요..
I want to live in korea, making programs, but...
http://wrice.egloos.com
비회원

Post by 비회원 »

UDP에 무슨 기능을 추가하고 싶으신데요? -_-;;
UDP가 왜 TCP에 비해 개발 비용이 많이 드나요?
쌀밥 wrote:다른 질문을 추가하는게 되겠습니다만..


UDP 프로그래밍과 관련해서 기능을 쉽게 추가하거나 빼거나 할 수 있는 라이브러리가 있습니까???
제 생각에는 Loki 처럼 Policy 단위 전략으로 기능을 빼거나 추가하는 형태의 라이브러리 제작이 가능하지 않을까 생각되는데요...
아시면 좀 추천해주세요...

UDP 의 단점은 역시 개발 비용에 TCP 보다 많이 든다는 점이라고 생각합니다.
만약 편리하고 안정적인 UDP 관련 라이브러리가 있다면 알려주세요..
아제나
Posts: 155
Joined: 2005-08-01 11:07
Location: 프로그래머
Contact:

Post by 아제나 »

myevan wrote:"A-B 두 당사자가 아닌; 제 3의 C나 D가 B가 열어놓은 구멍을 통해; 넣을 수있다! -_-)o"

포인트를 강조하자면 이렇습니다.

TCP의 경우 서로 연결된 스트림에 다른 스트림이 끼어들 방법은 좀 많이 애매하죠 ~(-_-)~;;

UDP의 경우는
A: 야-_- 패킷 보냈다
B: 어라 50번 포트로 보냈네? 자 -_-)/ 이제부터 다들 A에게 보내려면 xxx.xxx.xxx.xxx의 50번 포트로 쏴라!
C: 오케바리 -_-)~ 나도 A에게 슥 ~(-_-)~
A: C가 보낸 패킷 수신확인 -_-)/
D: 나도 보내도 돼나 = =)? ~(-_-)~ 슥
A: D가 보낸 패킷도 확인 -_-)/
B: 하지만 문이 언제 닫힐지 모르니 나와의 A와의 관계는 계속 유지하도록 하지 -_-)~
이런 스토리를 가볍게 전개할 수 있습니다. (sendto 는 수신포트를 세팅할수 있죠; )
아주 알기 쉬운 글 입니다. 전 왜 이렇게 쉽게 설명하기 힘들까요ㅎㅎㅎ

특히 '구멍'이란 표현이 예술 입니다.

구멍;;;;;
Programmer's Life 아제나
비회원

자자.. UDP가 패킷 로스를 한다면..

Post by 비회원 »

비회원 wrote:대역을 보장한다는 말을 사용했던 사람입니다.

지금 대역폭이라는 말이 같은 의미로 사용되고 있는지 궁금하네요. 대역폭은 말 그대로 '단위시간당 얼마의 데이터를 전송하는가'라는 의미입니다. 한번에 보낼 수 있는 패킷의 크기가 *아닙니다*.

tcp는 전송을 보장해야 하기 때문에 중간에 패킷 로스가 발생하면 다 보낼때까지 계속해서 재시도를 합니다. 반면 udp는 정보를 보내면 패킷 로스가 되건말건 계속 보내지요.

빠른 반응성이 필요한 게임은, 패킷 로스가 되어 과거의 데이터를 시간 안에 보내지 못했을 경우, 이미 과거의 데이터는 '만료'된 데이터로 간주하고 최신의 데이터를 바로바로 보내는 편이 나은 경우가 많다는 것입니다. tcp의 경우 이미 과거의 데이터라고 해도 한번 보내기를 시도한 데이터는 프로토콜단에서 끝까지 보내려고 시도하지요.

NAT홀 펀칭과 같은 편법은 부차적인 문제입니다. tcp와 udp의 궁극적인 차이, 두 프로토콜을 따로 둔 궁극적인 목표는 여기 있습니다.

온라인 게임은 인터넷 생중계와 비슷한 면이 있습니다. 서버에 있는 가상 월드의 상태를 클라이언트에 생중계하는 것이죠. 생중계하는데 회선 상태 이상으로 최근 5초간의 정보를 받지 못했을 경우 그 5초간의 월드의 변경을 하나하나 다 받는것보단 현재의 상태만을 받는 것이 훨씬 이득입니다. TV생방송의 경우 5초정도의 딜레이는 무시할만 할지 모르지만 인터랙티브한 온라인게임에서는 1초의 딜레이도 큰 타격이 됩니다.

tcp는 월드의 상태를 계속 중계하면 5초건 10초건 그동안 보내려고 시도했던 것을 다 보내려고 시도하는 것이고, udp는 5초간 보낸게 안 갔다면 지금 보낸것부터라도 잘 받으라고 하는 것이지요. tcp의 경우 회선 상태가 안 좋으면 당연히 이 딜레이는 점점 더 커집니다. 곧 버퍼 오버플로우로 연결이 끊기겠지요. udp는 5초에 한번씩 클라이언트가 갱신되는 한이 있어도 지속적으로 정보를 받을 수 있습니다.

물론 udp로 월드를 중계한다면 패킷 설계를 잘 해야 합니다. 그 5초간의 정보가 없으면 최신의 패킷을 받아도 월드를 구성할 방법이 없다면 말짱 꽝이겠지요. 패킷 하나하나가 이전에 갔던 패킷과 독립적이도록 설계하여 패킷 로스를 신경쓰지 않고 날아오는 패킷만 처리하면 되도록 해야겠지요. 이게 불가능한 정보는 tcp를 통하도록 하면 되고요.

그래서 많은 게임들이 일상적인 이동과 같은 정보는 udp로 전송하고 잃어버려서는 안되는 중요한 정보들은 tcp로 전송하는 것이겠지요.
-> 옳소~! 이분 의견에 한표. 엄밀히 말하면 패킷 전송빈도가 높은(broadcast스타일)패킷은 하나를 잃어도 어차피 좀 있다가 다른 하나가 올 걸 알기 때문에 버려져도 상관이 없죠. 그럼 그 버려진 패킷 이전 패킷과 그 뒤에 받은 패킷과의 동기화는 어떻게 해주는가! 이게 궁금해지죠.

정답은 "동기화되는거처럼 보이게 한다" 입니다.
데드 레커닝(Dead Reckoning) 기법이 이때 사용되죠.

우리가 우리는 이미 미립자의 세계가 아닌 현실세계에선 물리법칙이 통한다는걸 알고, 어떠한 운동의 예측결과를 계산할 수 있습니다. 신호가 없는 그 텀에도 움직임을 추정하는게 데드 레커닝 기법의 핵심이라 할 수 있죠.

http://www.g-matrix.pe.kr/feature/multi ... koning.htm

마스터 구글께서 전설의 용사 kaswan님의 주옥같은 글을 찾아 주셨으니 읽어보시길 :)
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

myevan wrote:Datagram 도 "하부단계에서는 쪼개져서 전달된다" 라는게
viewtopic.php?t=6131&highlight=udp
요기에서 논의된적이 있습니다만;; 상세한 하부구조는 장비제작하시는분들에게 필요한 내용일듯하고;
어플만드는 분들입장에서는 안전한 UDP 패킷 사이즈와 쪼개지더라도 하부단계에서 합쳐지므로
소켓인터페이스상으로는 보낸 패킷 통째로 받을 수 있다라는 사실에만 주목하면 될것 같습니다.
(자칫 오해의 소지가 있을 수 있기때문에;; )

홀펀칭이라는게 제가 생각하는게 맞는지는 모르겠습니다만;
NAT라 할지라도 내부에서 UDP로 send하면, 외부에서 수신할 수있고,
바로 응답을 하면 NAT내부에서 수신이 가능합니다.

이것은 UDP패킷을 보낼때, 라우팅되는 경로 장비에 포트가 동적으로 할당되기때문인데,
장비마다 다르지만 잠시동안 이 포트가 유지되며, 이 구멍을 통해 제 3자도 NAT내부에 UDP패킷을 보낼수 있습니다.
... 하지만; 방화벽으로 막으면 좌절orz 인데;; 불행히도 제가 작업할 당시 최근 공유기들은 방화벽 디폴트로 계속 나오면서
... ;; 그러면서 uPnP 니 하는 개념도 같이 나오곤 했는데; 이후로는 udp작업을 안해봐서 잘 모르겠습니다 -_-);;


ps.
아 - - 숙제해야하는데; 큰일;; 날새야하나...




생각해보니까... UDP가 스트림 전송 방식이 아니라는 것때문에

이런 착각을 한거 같습니다


어째튼 UDP는 쪼개지는거와는 상관없고 쪼개지는건 그 밑에 층인 IP계층에서의 일인거 같네요
비회원

딱 한번 해본 제 경험으로는...

Post by 비회원 »

서버 하나와 클라이언트 하나와의 관계만 생각했을때, TCP는 필연적으로 Ack가 필요한대

이 Ack라는게 패킷을 주고 받는 행위라는게 지속적으로 일어난다면 별 문제 없이 TCP도 짧은

주기로 자주 패킷을 전송할수 있습니다. 예를 들면 일초에 열번정도 .. 하지만 어떤 하나의 클라이

언트가 자신의 위치를 서버에 보내고 그 서버가 그 정보를 다른 클라이언트에 브로드 캐스팅 할시

에 문제가 일어나는것 같습니다. 다른 클라이언트 입장에서는 서버와의 관계가 패킷을 주고 받고

있는 관계가 아니라 일방적으로 패킷을 받게 되는 관계가 된다는 것입니다. NT의 경우 ACK를 보낼때

디폴트로 200ms를 그 클라언트로 가는 데이터가 있는지 기다리게 됩니다.( 물론 변경도 가능하지만

괜히 200ms로 해놓은것은 아니겠죠) 만약에 일방적으로 짧은 주기의 데이터를 그냥 받기만 한다고

가정했을 때 절대로 200ms 이하의 주기로 데이터를 보내지 못하는 현상이 생기더군요. 예를 들어

TCP로 연결한다음 일방적으로 한쪽에서 다른쪽으로만 패킷을 쏘개 하면 절대로 200ms이하의 속도

로 보낼수가 없는 현상이 발생합니다. 소규모 인원이 모여서 하는 레이싱 게임 같은경우 패킷의 크기

보다 얼마나 자주 보낼수 있나가 싱크에 품질을 좌우하니까 아무래도 Ack과정이 생략되는 UDP같은

경우 싸주고 싶을때 맘대로 싸줄수 있으니까 어느정도 가장 빈번하고 소실되도 상관없는 위치데이터의

경우 UDP가 훨씬 더 좋은 품질에 싱크를 제공할수 있는것같습니다.
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Re: 딱 한번 해본 제 경험으로는...

Post by mastercho »

비회원 wrote:서버 하나와 클라이언트 하나와의 관계만 생각했을때, TCP는 필연적으로 Ack가 필요한대

이 Ack라는게 패킷을 주고 받는 행위라는게 지속적으로 일어난다면 별 문제 없이 TCP도 짧은

주기로 자주 패킷을 전송할수 있습니다. 예를 들면 일초에 열번정도 .. 하지만 어떤 하나의 클라이

언트가 자신의 위치를 서버에 보내고 그 서버가 그 정보를 다른 클라이언트에 브로드 캐스팅 할시

에 문제가 일어나는것 같습니다. 다른 클라이언트 입장에서는 서버와의 관계가 패킷을 주고 받고

있는 관계가 아니라 일방적으로 패킷을 받게 되는 관계가 된다는 것입니다. NT의 경우 ACK를 보낼때

디폴트로 200ms를 그 클라언트로 가는 데이터가 있는지 기다리게 됩니다.( 물론 변경도 가능하지만

괜히 200ms로 해놓은것은 아니겠죠) 만약에 일방적으로 짧은 주기의 데이터를 그냥 받기만 한다고

가정했을 때 절대로 200ms 이하의 주기로 데이터를 보내지 못하는 현상이 생기더군요. 예를 들어

TCP로 연결한다음 일방적으로 한쪽에서 다른쪽으로만 패킷을 쏘개 하면 절대로 200ms이하의 속도

로 보낼수가 없는 현상이 발생합니다. 소규모 인원이 모여서 하는 레이싱 게임 같은경우 패킷의 크기

보다 얼마나 자주 보낼수 있나가 싱크에 품질을 좌우하니까 아무래도 Ack과정이 생략되는 UDP같은

경우 싸주고 싶을때 맘대로 싸줄수 있으니까 어느정도 가장 빈번하고 소실되도 상관없는 위치데이터의

경우 UDP가 훨씬 더 좋은 품질에 싱크를 제공할수 있는것같습니다.

근데 말씀 하신 내용은 TCP의 nagle 알고리즘때문에 발생한 현상인데

이 옵션을 끄면 ack을 기다리느라 ... 지연되는 현상은 없어진다고 보았습니다

[nagle이 디폴트로 활성화 되어 있고 , 이걸 끈다면 ...ack을 받으면서 동기화 하지 않고 비동기로 주고 받기 때문에...]

nagle 알고리즘 옵션을 꺼서 , 보내는 입장에서 ack를 기다리지 않고 바로 바로 보내면
어떤지 궁금해지네요 [테스트 할 입장은 못되서...]
[ 소켓책에 nagle 옵션 끄는건 다 있는거 같더라고요 , 설마 없을리는 없겠지만서도 ==; ]

근데 nagle 알고리즘이 인터넷 트래픽이나 기타 여러 상황에 대처할수 있도록 만들어진거라
알고 있는데 [TCP 윈도우 크기도 그렇고요] 회선이 안좋은 상태면 더 안좋은 결과를 유발한다고도
들었지만 (많은 트래픽 부하 유발) 책으로만 읽은 내용이라 실제로는 어떤지 궁금하네요

혹시 -_-; nagle을 그고 테스트 해보신다면
얼마나 향상되는지 답글좀 부탁드립니다
비회원

Re: 딱 한번 해본 제 경험으로는...

Post by 비회원 »

mastercho wrote:
비회원 wrote:서버 하나와 클라이언트 하나와의 관계만 생각했을때, TCP는 필연적으로 Ack가 필요한대

이 Ack라는게 패킷을 주고 받는 행위라는게 지속적으로 일어난다면 별 문제 없이 TCP도 짧은

주기로 자주 패킷을 전송할수 있습니다. 예를 들면 일초에 열번정도 .. 하지만 어떤 하나의 클라이

언트가 자신의 위치를 서버에 보내고 그 서버가 그 정보를 다른 클라이언트에 브로드 캐스팅 할시

에 문제가 일어나는것 같습니다. 다른 클라이언트 입장에서는 서버와의 관계가 패킷을 주고 받고

있는 관계가 아니라 일방적으로 패킷을 받게 되는 관계가 된다는 것입니다. NT의 경우 ACK를 보낼때

디폴트로 200ms를 그 클라언트로 가는 데이터가 있는지 기다리게 됩니다.( 물론 변경도 가능하지만

괜히 200ms로 해놓은것은 아니겠죠) 만약에 일방적으로 짧은 주기의 데이터를 그냥 받기만 한다고

가정했을 때 절대로 200ms 이하의 주기로 데이터를 보내지 못하는 현상이 생기더군요. 예를 들어

TCP로 연결한다음 일방적으로 한쪽에서 다른쪽으로만 패킷을 쏘개 하면 절대로 200ms이하의 속도

로 보낼수가 없는 현상이 발생합니다. 소규모 인원이 모여서 하는 레이싱 게임 같은경우 패킷의 크기

보다 얼마나 자주 보낼수 있나가 싱크에 품질을 좌우하니까 아무래도 Ack과정이 생략되는 UDP같은

경우 싸주고 싶을때 맘대로 싸줄수 있으니까 어느정도 가장 빈번하고 소실되도 상관없는 위치데이터의

경우 UDP가 훨씬 더 좋은 품질에 싱크를 제공할수 있는것같습니다.

근데 말씀 하신 내용은 TCP의 nagle 알고리즘때문에 발생한 현상인데

이 옵션을 끄면 ack을 기다리느라 ... 지연되는 현상은 없어진다고 보았습니다

[nagle이 디폴트로 활성화 되어 있고 , 이걸 끈다면 ...ack을 받으면서 동기화 하지 않고 비동기로 주고 받기 때문에...]

nagle 알고리즘 옵션을 꺼서 , 보내는 입장에서 ack를 기다리지 않고 바로 바로 보내면
어떤지 궁금해지네요 [테스트 할 입장은 못되서...]
[ 소켓책에 nagle 옵션 끄는건 다 있는거 같더라고요 , 설마 없을리는 없겠지만서도 ==; ]

근데 nagle 알고리즘이 인터넷 트래픽이나 기타 여러 상황에 대처할수 있도록 만들어진거라
알고 있는데 [TCP 윈도우 크기도 그렇고요] 회선이 안좋은 상태면 더 안좋은 결과를 유발한다고도
들었지만 (많은 트래픽 부하 유발) 책으로만 읽은 내용이라 실제로는 어떤지 궁금하네요

혹시 -_-; nagle을 그고 테스트 해보신다면
얼마나 향상되는지 답글좀 부탁드립니다
핸드셰이크 방식이 문제입니다. 일단 갔는지 안갔는지를 '확인' 해야한다는점은 레이턴시가 긴 회선에서의 p2p에선 치명적인 부분이죠.
비회원

Re: 딱 한번 해본 제 경험으로는...

Post by 비회원 »

mastercho wrote:
비회원 wrote:서버 하나와 클라이언트 하나와의 관계만 생각했을때, TCP는 필연적으로 Ack가 필요한대

이 Ack라는게 패킷을 주고 받는 행위라는게 지속적으로 일어난다면 별 문제 없이 TCP도 짧은

주기로 자주 패킷을 전송할수 있습니다. 예를 들면 일초에 열번정도 .. 하지만 어떤 하나의 클라이

언트가 자신의 위치를 서버에 보내고 그 서버가 그 정보를 다른 클라이언트에 브로드 캐스팅 할시

에 문제가 일어나는것 같습니다. 다른 클라이언트 입장에서는 서버와의 관계가 패킷을 주고 받고

있는 관계가 아니라 일방적으로 패킷을 받게 되는 관계가 된다는 것입니다. NT의 경우 ACK를 보낼때

디폴트로 200ms를 그 클라언트로 가는 데이터가 있는지 기다리게 됩니다.( 물론 변경도 가능하지만

괜히 200ms로 해놓은것은 아니겠죠) 만약에 일방적으로 짧은 주기의 데이터를 그냥 받기만 한다고

가정했을 때 절대로 200ms 이하의 주기로 데이터를 보내지 못하는 현상이 생기더군요. 예를 들어

TCP로 연결한다음 일방적으로 한쪽에서 다른쪽으로만 패킷을 쏘개 하면 절대로 200ms이하의 속도

로 보낼수가 없는 현상이 발생합니다. 소규모 인원이 모여서 하는 레이싱 게임 같은경우 패킷의 크기

보다 얼마나 자주 보낼수 있나가 싱크에 품질을 좌우하니까 아무래도 Ack과정이 생략되는 UDP같은

경우 싸주고 싶을때 맘대로 싸줄수 있으니까 어느정도 가장 빈번하고 소실되도 상관없는 위치데이터의

경우 UDP가 훨씬 더 좋은 품질에 싱크를 제공할수 있는것같습니다.

근데 말씀 하신 내용은 TCP의 nagle 알고리즘때문에 발생한 현상인데

이 옵션을 끄면 ack을 기다리느라 ... 지연되는 현상은 없어진다고 보았습니다

[nagle이 디폴트로 활성화 되어 있고 , 이걸 끈다면 ...ack을 받으면서 동기화 하지 않고 비동기로 주고 받기 때문에...]

nagle 알고리즘 옵션을 꺼서 , 보내는 입장에서 ack를 기다리지 않고 바로 바로 보내면
어떤지 궁금해지네요 [테스트 할 입장은 못되서...]
[ 소켓책에 nagle 옵션 끄는건 다 있는거 같더라고요 , 설마 없을리는 없겠지만서도 ==; ]

근데 nagle 알고리즘이 인터넷 트래픽이나 기타 여러 상황에 대처할수 있도록 만들어진거라
알고 있는데 [TCP 윈도우 크기도 그렇고요] 회선이 안좋은 상태면 더 안좋은 결과를 유발한다고도
들었지만 (많은 트래픽 부하 유발) 책으로만 읽은 내용이라 실제로는 어떤지 궁금하네요

혹시 -_-; nagle을 그고 테스트 해보신다면
얼마나 향상되는지 답글좀 부탁드립니다
------------------------------------------------------------------------------------
MSDN에서는 200ms란 값은 꽤 신중하게 결정된 값이라고 일단 겁을 주더군요. 것도이해할만 한것같고
레지스트리를 고쳐 테스트 해봐도 머 게임 전체적으로 봤을때는 별루 효과가 없었습니다.. ^^;;
이론적으로 봤을때도 서버와 클라간의 핑이상은 절대루 안나오겠죠.. 문제는 위치데이터의 경우 짧은주기로 게임 끝날때까지 계속 보내야 하는 경우 가 많은대 TCP의 경우 주기적으로 보내온 그 데이터 모두 패킷 인증과정이 다 적용되어 처리되어야 하는대 있 는것 같습니다. 한꺼번에 처리되거나(한번보낸거나 다름없는결과) 아니면 일정주기를 넘어서면 쌓이게 되 는 것(더 나쁜결과) 같습니다. 소규모 인원의 액션 게임은 UDP에 보장성을 주거나 혹은 역쉬 보장성이 필요한 데이터와 그렇지 않은 데이터를 구분해서 TCP와 UDP 두가지 연결을 사용하는것이 결국에는 가장 속 편하지 않나 하는 생각을 했었던것 같습니다. 솔직히 일초에 열번은 보내고 싶은 욕구가 자꾸 드니깐요 ..
Locked