port restricted cone 타입의 NAT 두 대로 hole punching 기능을 테스트 하고 있는데, 홀펀칭이 성공하지 못하네요.
장비하고 관련이 있는 것인지..?
참 신기한 것은 NAT A가 먼저 NAT B로 패킷을 쏘면 통신이 되는데, 그 반대는 되지 않습니다.
물론 path를 열어 놓기 위해 3번 반복해서 쏘는데.. 처음에 어떤것이 쏘는것이 중요한지 쏘는 타이밍에 따라 성공이 될때도 있고 안될때도 있는데, 이유를 혹시 아시는지요.
IP 중계서버를 만들거나
공유기의 포트포워딩을 열어주거나
공유기의 DMZ를 열어주거나
UPNP 를 열어주거나... 다양한 방식이 가능해 보입니다.
DirectPlay 같은 경우는 서버에 클라이언트가 접속하게 되면. 클라이언트를 자동으로 연결해 준다고 하네요. ㅇ_ㅇ;;
플래시도 커뮤니티 서버를 사용하면 그런것이 가능하던데요...
문제는. 임의로 사용자의 포트를 강제로 열고 드나드는것은 위법입니다.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
예제라기 보다.. 원리가 UDP와 동일합니다...
예제라기 보다.. 원리가 UDP와 동일합니다... 그냥 TCP로 쏘시면 됩니다.
다만 UDP 홀펀칭은 되는데 TCP홀펀칭은 안되는 NAT 장비들이 존재합니다.
장비만 문제없다면 잘 될겁니다.
아 그렇군요.. ^^
답변 감사합니다
그럼 UDP 든.. TCP든 홀펀칭이 이용된 참고할만한 예제소스같은거 구할수 없을까요..?^^
검색해보면 아래와 같은 글들이 보이네요.. 자세히는
검색해보면 아래와 같은 글들이 보이네요.. 자세히는 보지 않았습니다만..
http://ramonli.blogspot.kr/2012/03/tcp-hole-punching-how-to-establish-tcp.html
http://www.gamedevforever.com/47
한 5년전에 홀펀칭 고민했을 때, python으로 10줄이 안되는 코드 작성해서 테스트 했더니 동작했던 기억이 나네요..
네트워크 쪽은 원리에 비해 코드가 복잡하니까.. 먼저 동작원리를 파악하는게 도움이 되실겁니다.
감사합니다~~
감사합니다 참고하겠습니다~~^^
udp hole punching 실패
port restricted cone 타입의 NAT 두 대로 hole punching 기능을 테스트 하고 있는데, 홀펀칭이 성공하지 못하네요.
장비하고 관련이 있는 것인지..?
참 신기한 것은 NAT A가 먼저 NAT B로 패킷을 쏘면 통신이 되는데, 그 반대는 되지 않습니다.
물론 path를 열어 놓기 위해 3번 반복해서 쏘는데.. 처음에 어떤것이 쏘는것이 중요한지 쏘는 타이밍에 따라 성공이 될때도 있고 안될때도 있는데, 이유를 혹시 아시는지요.
홀펀칭 없이도....
홀펀칭....STUN 이라고도 불리웁니다.
STUN 없어도 NAT 뒤의 클라이언트간에 통신은 가능합니다.
중계해주는 서버를 거치면 가능해지죠..REALY 방식이라고도 합니다.
STUN은 라이브러리들이 있었던것같긴한데.....
직접 구현해본다고 학생때 설쳐보다가 결국 실패하고 좌절했던 기억만 남아있네요.
---------------------------------------------------------------
Opensource에 기여하는 것이 꿈입니다.
내가 만든 코드를 모두가 사용할 때 까지~
릴레이서버도 사용하는데요..^^
릴레이서버는 클라이언트 간의 파일송수신엔 직접적으로 관여하지 않아야 해서요..ㅎㅎ
릴레이서버는 단지 클라이언트끼리 public IP와 Private IP 정보만 중계하는 역할을 해야하거든요.. 안그럼 P2P연결이라고 볼수가 없어서..
조언감사합니다^^
ㅎㅎ
보시다 보시면 아시겠지만 공유기 방식마다 홀펀칭 방식이 다릅니다.
half cone , full cone, 또 다른방식 등등 각각의 방식에 따라 펀칭 기법이 달랐던것으로 기억합니다.
해당 문제로 인해 iptime측에 정보를 요청했으나 공개해주진 않더군요.
홀펀칭이 결국은 되지않는 상황도 발생할수 있습니다.
nat 밑의 nat밑의 nat 뭐 이런 이상한 경우가 나올수 있는데 어떤 케이스에선 결국 안뚫리는경우가 있더군요.
그런경우는 결국 relay방식을 쓸수밖에없다고 본듯합니다.
하도 오래전에 해당 부분때문에 고심했던지라....자세히는 기억이 안나네요.....화이팅입니다......
---------------------------------------------------------------
Opensource에 기여하는 것이 꿈입니다.
내가 만든 코드를 모두가 사용할 때 까지~
정확한지는 모르겠지만...
IP 대역이 서로 다른 상황에서 서로 통신하기 위해서는
Virtual Box같은 가상 PC 설치한 후에
xxx.xxx.xxx.254인가? 255인가? 멀티캐스팅인가? 뭔가로 송수신 하면 되던데요. ㅇ_ㅇ;;
홀드 펀칭이니 STUN 이니... 말은 많은데 뭔지는 잘 모르겠네요.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
P2P통신을 구현해야하는지라..
효율적인 통신이 되게 하려면
홀펀칭을 쓰는게 답인거 같더라구요..
열심히 찾아봐야죠 ㅠㅠ
구현 방식은
IP 중계서버를 만들거나
공유기의 포트포워딩을 열어주거나
공유기의 DMZ를 열어주거나
UPNP 를 열어주거나... 다양한 방식이 가능해 보입니다.
DirectPlay 같은 경우는 서버에 클라이언트가 접속하게 되면. 클라이언트를 자동으로 연결해 준다고 하네요. ㅇ_ㅇ;;
플래시도 커뮤니티 서버를 사용하면 그런것이 가능하던데요...
문제는. 임의로 사용자의 포트를 강제로 열고 드나드는것은 위법입니다.
----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.
매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.
각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com
P2P가 반드시 효율적이지는 않습니다.. 피어중에
P2P가 반드시 효율적이지는 않습니다.. 피어중에 성능이 안좋은 녀석이 있을 수도 있고.. 엉터리 정보를 보낼 수도 있습니다.
P2P의 강점은 네트워크 파괴에 대한 내성과 네트워크 대역폭의 분산입니다..
한국은 네트워크 대역폭의 단가가 비싼편에 속해서 가격면에서 P2P가 이득이 있습니다만 단순히 효율만 놓고 본다면 P2P가 낫다고는 말할수 없습니다.
물론 LAN상황이라면 P2P가 가장 효율적인것 맞습니다.
기술적인 개념 검증이라면 여러모로 연구해 보기 좋은 주제입니다만, 실무에서는 쉬운 길을 어렵게 가는 방법일 수도 있습니다..
댓글 달기