Untitled

소켓 플밍 하려면..
뭘 어디서 부터 시작 해야죠?
API에서 지원해주는 함수가 있는건가요?
흑.. 걍 DPLAY로 함 될 줄 알았는데..

윈도우 소켓은 http://www.sockets.com 가보시고
유닉스 소켓은 리눅스 네트워크 프로그래밍 Howto먼저 보신후에
유닉스 프로그래밍 FAQ, TCP/IP FAQ등등 찾아 보시기 바랍니다.이화수 (soaring )

자료를 이거 저거 받아 봤습니다.
컴파일은 안 해 봤지만.. 들어 있는 화일들은 실행이 잘 되더군요..
그런데..
어디다 쓰는지 몰겠습니다.. ==;
DPlay 쓸때는 세션 만들고.. TCP/IP,IPX... 뭐 이딴거 물어보고 하는데..
이거 밑도 끝도 없이 서버 이름을 대라고 꼬장 부리고.. ==;
그래서 질문 하는건데..
winsock이란건 무엇을 위해 있는건가요? ^^;
대략적인 개념과.. 처음에는 어떤거 부터 시작을 해야 하는지
답변 부탁 드립니다..
음.. 아주 노골적인 처음.. 그러니까.. 첨에는 접속하는것 부터
시작을 해야한다.. 는 식으로 함수이름 같은거(봐야할 순서.. )
도 부탁 드립니다.

그 꼬장이 나온다면, 제대로 동작한다고 보면 됩니다.
그 꼬장이 뭐냐하면.. 어떤식으로 연결해서 쓸 것인가를 설정하는 것이라 보면
됩니다. 그러니까, "누구랑 멀티 붙을건데?" 를 묻는거라 보면 되죠. 그걸 좀
생소한 표현으로 알려주는 것 뿐이죠.
그런 꼬장은, 모든 네떡겜들은 웬만하면 다 묻습니다. 좀 차이가 있다면,
스타크래프트와 디아블로는 TCP/IP와 서버 주소를 입력하는게 아니라 그냥
배틀넷에 접속이 되죠. 그거는 이미 배틀넷 서버가 이미 지정되어 있기 때문에,
단지 서버 주소 입력을 생략할 수 있는 차이일 뿐이죠.
그럼 IPX는 왜 안묻느냐? 맞는지는 모르겠지만, IPX는 라우터였나?
게이트웨이였나? 암튼 보통 LAN을 벗어나지 않는 수준에서 처리됩니다. 정확한
구조는 모르겠지만, 그래서 LAN 내에 있는 세션만 나오죠.
나머지는..생략해도 되겠죠? 전화접속,케이블 연결 등일테니까요. 전화접속이야
당삼 전화번호를 물어볼테구요.. :)
우선,다른 네떡 게임은 어떻게 돌아가는지부터 살펴보시는게 더 좋을 듯 싶군요.

IPX는 주로 LAN상에서 화일공유나 프린터 공유등에 썼었죠.
노벨네트웨어가 기본적으로 쓰던 프로토콜입니다.
(원래는 IBM에서 설계 했던가 그랬을 겁니다. 잘기억이 안나네요.)
TCP/IP는 유닉스에서 발달했구 요즘 가장 많이
쓰는 프로토콜이죠.. 안정적인 데이터 교환을 목표로 하고
WAN환경에서도 잘돌아가죠. 그이유는 인터넷이 TCP/IP를 기반으로 하고
있고 라인과 장비자체가 TCP/IP를 기준으로 하고 있는거죠.
TCP/IP가 IP주소 기반이라서 IP주소를 적는 부분은 TCP/IP밖에 없는 거구요.
IPX자체는 LAN기반이라서 비교적 작은규모의 네트웍에서 돌리고 IP주소를
쓰지 않지요. (따라서 IPX로 게임할때는 주소를 적으란 말이 안나오죠.)
네트웍을 나눌때 쓰는 라우터나 브릿지 등의 장비에서 IPX를 필터링해주는
기능이 있습니다. (IPX를 필터링한다기 보단 TCP/IP이외의 프로토콜을 막는
것이죠) 전용선을 깐 회사마다 라우터가 있지요.
그래서 IPX는 하나의 서브넷(네트웍을 나누는 단위)을 통과하지 못하구요.
겜방도 IPX로는 하나의 겜방내에서만 게임을 할 수 있는것이죠.

kali나 지금 트윔넷클라이언트 에서 해주는 역할도 IPX와 TCP/IP의 게이트웨이
역할을 해주는 겁니다.
따라서 IPX를 이용해 게임을 해도 외부망과의 연결을 kali클라이언트가
TCP/IP를 가지고 IPX를 랩핑해서 바꿔주는 역할을 해주기 때문에
외부와도 IPX연결을 할 수 있는 것이죠.
Direct play는 이런 프로토콜에 관계없이 8명 정도의 연결을 하게 해주는
하이레벨 클래스 입니다.
Direct play만 잘써도 소켓이나 IPX등을 몰라도 8명정도의 연결은 가능하단
예기지요.
(Netview도 지원하구 PPP/Slip , 시리얼 케이블 연결도 지원 합니다.)
Socket은 TCP/IP 프로그램에서 프로그램의 기본 단위 입니다.
전원 컨센트를 생각하면 되는데.
전원 컨센트에 소켓을 꼽듯이 통신을 하기 위해선 두컴간에
어떤식으로든 연결이 되어 있어야 합니다. 물리적으로는 라인이 연결되어
있고 데이터상으로는 소켓이 연결되어 있다고 표현을 합니다.

소켓이라는건 가상의 개념이고 실재로 내부적으론 복잡한 과정을 거쳐야만
두 컴간에는 연결이 되었다고 말하는데 이건 논할바는 아니고요.
(이런 사항은 TCP/IP Illustrated Vol1을 참고 하십시요. 뭐 실재적으로
프로그램할땐 안쓰이지만 개념을 이해한다는 측면에선 도움이 되지요.)
암튼 가상의 개념이고 소켓이 연결된것이 두컴간에 데이터를 교환할 준비가
된것이고 우린 그 연결된 소켓을 이용하여 데이터를 주고 받을 수 있다는 게
중요하죠.
소켓이 연결되기 위해선 우선 연결하고자하는 곳의 IP주소와 port번호를 알아
야 합니다. Port는 하나의 컴퓨터에서 여러개의 연결을 하기 위한 가상의 번호
입니다. 1~65535개까지 부여가 되고 초반의 몇개는 기본 서비스를 위해 할당이
되어 있습니다. port 번호는 여러개의 연결을 위한 일련 번호도 될 수 있고
서버에서 서비스를 하는 통로가 되기도 합니다. 이런걸 서비스 포트라고 하는데.
예를들면 우리가 자주 사용하는 웹은 80번 포트를 쓰지요. 그래서 우리가
어떤 웹 서비스를 하는 컴에 들어가려면 브라우저엔 IP주소나 네임주소를적지요.
하지만 실재적으로 브라우저에서 소켓을 연결할때는 그 ip주소의 80번 포트로 들어

가게 됩니다. 그런식으로 특정한 서비스별로 정해진 포트 번호가 있습니다.
윽 말이 너무 많았군요. 할말은 많지만. 암튼 서비스 포트는 좀 생각해볼 구석이
있는 부분이죠. 내부적으로 TCP연결일때 하나의 포트에 그 많은 클라이언트들이
연결이 될까요?
그건 숙제입니다 ^^; 약간만 자료 찾아 보면 나오지요. (별건 아니지만. ^^;
손가락이 아파서리..)
암튼 소켓은 TCP/IP에서 네트웍 프로그래밍을 하기 편하기 위해
만들어낸 개념이라고 생각하면 됩니다. WinSock은 윈도우에서 구현한
소켓일 뿐이구요.
게임 프로그래밍 하기 위해선 그정도랑 TCP/UDP와의 차이 그리고 포트의 개념
서버 포트는 몰까? 정도만 알고 주어진 API로 열심히 짜면 됩니다.
정 궁금하시면 네트웍 개념서 몇권만 들춰 보시면 이해가 될겁니다.
그럼..
아이구 팔다리 어깨야..정두재 (isoft )

Unix 서버 프로그래밍...
  안녕하세요...

   Stevens의 책을 보세요...
   왠만한 것은 그거 보면 해결 하실 수 있을 거고요...
   실제로 쓸만한 서버를 만든다고 해서
   꼭 쓰레드를 써야 하는 것은 아닙니다.
   오히려 Unix에서는 포팅 문제로 인해
   쓰레드 사용에 신중을 기해야 할 것이고요...

   서버라는 것이 구조가 다양할 수 있고...
   용도와 예상되는 성능 수준에 따라서 맞춰 구성해야겠죠...
   부하가 심하지 않다면 one process로도 충분히 가능합니다.
   정도에 따라서 multi process로 구성해도 될 것이고...
또한 적절하게 IPC를 사용하는 것도 큰 도움이 됩니다.
   Unix에는 메세지나 뭐 그런 좋은(?) 프로그래밍 기법이 없으니...
   비슷하게 만들 수는 있는데...
   불필요하게 복잡해질 수 있으니 권장은 안합니다.

   꼭 쓰레드를 사용하시려면 윈도우 쓰레드랑 많이 다릅니다.
   컴파일러에 따라서 쓰레드 사용이 달라지기 때문에
   이것도 고려해야 할 것이고요...

   아직 Unix로 특별한 서버를 구성해 보신 적이 없으시다면
   One server 방식의 간단한 구조로 만드시는 것이 좋을 듯 합니다.
   loop time을 얼마로 주냐에 따라서 성능이 결정이 되겠죠...

   물론 처리 시간도 최소한으로 줄여야 하겠지만...
   Unix IPC 사용법 같은건 몰라도 되니깐요...
  테트리스 정도면 충분할껍니다.

   그리고 프로그래밍 관련 추가 내용은...
   마찬가지로 Stevens가 쓴 Advenced Unix Programming을 보시면 되거요.
   간단한 자료들은 Linux 동호회 가시면 구할 수 있습니다.
   gcc 잘하시는 분들이 많으니 도움이 될겁니다.

   실제 코드 예제가 쓸만한게 필요하시면...
   머드 소스를 한번 보시는 것도 도움이 될듯 하네요...
   직접 사용 하기에는 내용이 너무 다르겠지만...
   전체 구조나 소켓 사용에 대한 내용은 참조가 될겁니다.
   홍성민 (kingduke)

TCP/IP가 안좋은 프로토콜인가요?

디아블로로 인해서 UDP/IP가 많은 사람들한테 알려진것은 사실입니다.
저도 디아블로 덕분에 그런 프로토콜이 있는걸 알정도였으니까요.
보통 PC통신 상의 모뎀 제어 하는 프로그램에는 날라오는 데이타를
에러채크하는 부분이 없습니다.
보통은 Error correction을 임의로 짜주도록 하는것이죠.
하지만 TCP/IP의 경우는 99%가 에러가 없다고 생각하고 프로그램을
짜나가면 별로 문제가 될게 없습니다.
문젠 약간의 확실한 에러채크때문에 조금 느리다는 점 빼고는요.
요즘같이 모뎀속도 빨라지고 있는 상황을 고려해볼때
TCP/IP로 게임을 만든다는것은 나쁘지 않다는 결론이죠.
하지만 빠른 속도를 요하는 게임에서는 UDP/IP를 쓰는게 좋을수도 있는데
실제 디아블로도 기어가던데요. 선로 문제때문에..손서호 (mouse )

throattling

한쪽은 랜으로,또한쪽은 28k모뎀으로 접속했다고 합시다. 만약 랜에서
모뎀으로 열라게 데이터를 보냈는데,모뎀쪽에서 그걸 다 맞받아치지 않
으면 문제가 생긴다네요.. 그걸 해결하기 위해서는 랜쪽에서 '천천히'
보내주는게 좋다는군요. 이른바 throattling이라는데..그게 왜 필요한
지 궁금합니다. 너무 빨리 오면 일단 큐에 저장된다고 알고 있는데요..
막걸리
너무 간단한 답변이 될지도 모르겠지만...
큐가 full이 되고서도 data가 더 오면 overflow가 되겠죠...
이 상황에서 큐가 어떻게 작용 하나가 관건이죠...
대부분은 data가 소멸되어 버리니...
말씀하신 문제가 발생하는 거죠...
이거 해결하려면...
직접 중간에 버퍼를 하나 만들어야겠죠...
넉넉하게 큼직한걸로...
더욱 좋은 방법은...
큐가 넘칠 듯 하거나... 버퍼가 넘칠 듯 하면...
상대방에게 메세지를 보내서
천천히 보내라고 하는 거죠...
sync 시키는 것과 같죠...

NT Service만들기
이런 프로그램을 제가 gma 5에 올렸습니다. 찾아서 써보세요.
NT Service를 만드는 과정이,초기 부분은 거의 딱 한가지 방법인데,이걸 처음부터
만드는건 상당한 짜증을 유발합니다. 그런데,이걸 해결해 줄 놈을 오늘 구해서
올립니다.
NT Service(MFC codeguru에서 찾은건데,MFC는 지원하지 않습니다. 당연하겠지만..)
초기 부분을 만들어주는 AppWiz입니다. 이걸 msdev/sharedide/template에
복사해놓고,new project 목록에 찾아보면 요놈이 있을겁니다.
게임 서버 등을 만들기 위해 NT Service를 만드려는 분들께 요긴할 겁니다.
설명은 템플릿에 나오니까 큰 어려움은 없을겁니다.
막걸리

전송 버퍼량 구하기
ioctlsocket()로 수신 버퍼량을 구하는건 알고 있지만, 반대로 송신 버퍼량을 알아
내는 방법을 모르겠습니다.
참고로, 저는 winsock 2/blocked socket을 씁니다.
                                         막걸리
..참고로,유닉스계열에서는 ioctlsocket으로 송신 버퍼량을 알아낼 수
있다는데요,유감스럽게도 저는 그걸 쓰진 않아요. :)
안녕 하세요 자유창고 duicleme입니다.
잘은 모르지만.
제가 알기로 비블록드에서 수신에 한해서 WSAioctl 사용하고..
블록드에서는 보낼 버퍼를 그냥 계산 하는 걸로 알고 있습니다.
윈속II를 사용 하신다면..아마..
블록드에서는 WSASend 함수 사용할때 주는 버퍼인자 크기 만큼
정확히 가는 것으로 알고 있습니다.고로 이게 그 보낸 버퍼크기.
참 그리고 보내기 버퍼를 일정크기로 두어서..
카운트 ...
   보낸량 = 버퍼크기*카운트.
(단,연결이 끊어 지지 않는다면)
비블록드에선 보낸 값에 대해서 보증하지 않는다고...알고 있습니다....
에고...조심스러워 지는군요.....혹시 찾아 보시고...
아니라면 저에게도 알려 주세요...
                               .......자유창고

TCP/IP 소켓 연결에서 send()한 데어터가 중간에 사라져 버리는 경우가 있을 수
있나요? 클라이언트에서 보낸 메시지에 대한 응답이 서버로부터 와야되는데, 분명
서버는 보냈다는데 클라이언트가 받지를 못하는 군요.
이런 경우에 대한 정보를 아시는 분 혹시 안 계시는지..???

넷상태가 아주 나쁘지 않는한 tcp/ip에선 없어지지는 않을 겁니다.
밑에 분하고 상황이 같은지는 모르겠지만 참고 하세요.
보통, send 하나 recv 하나로 대응되는줄 알고 recv루틴 만드시는데
send로 보낸만큼 꼭 recv가 되지 않습니다.
여러개의 send가 한 덩이가 되어 recv가 되는 경우가 있습니다.
send 여러개가 뭉처서 들어 올때 앞의 데이타 하나만 처리하고 뒤쪽에
붙은 데이타는 무시했기 때문에 페켓이 사라진것 처럼 보입니다.
(저도 위 경우때문에 좀 당황했었죠... ^^)
recv한 것의 size를 체크해 보세요.
recv쪽은 파서(?)를 만들어 써야 사라지는 페켓이 없어질겁니다. ^^
-- 이화수, soaring@netian.com
혹시 보내는 쪽에서 TCP_NODELAY를 0으로 설정하고,받는쪽에서 그걸 1로 설정하지
않으셨나요? 이게 답이 될지는 저도 궁금하군요. 해보시고 알려주시면
고맙겠시와요.. 막걸리
소켓 옵션에서 TCP_NODELAY를 해
주면 이런 경우를 막을 수 있다는 소문이 있던데 그 옵션을 키면 네트웍에 엄청난
무리가 간다고 해서 안쓰고 있죠.
어쨌거나 분명 메시지는 중간에 나뉘거나 한꺼번에 붙여서 수신될 수 있다는 것은
확인된 사실입니다. 이런 경우에 대한 대비를 하지 않음 삑사리나서 다운되거나
뭔가 이상해 집니다.

소켓 메세지 안정성 문제와 더불어.

안녕하세요...
소켓에서 전송시 안정성 문제 얘기가 좀 있는 것 같은데...
  저의 결론부터 말한다면,
  그 어떠한 경우에도 절대 100%란 존재하지 않는다는 거죠...
  이건 뭐, 그냥 저의 경험상의 결론일 뿐이니 반론이 있을 수 있겠지만...
  TCP, UDP가 중요하지는 않다고 생각합니다.
  물론 확률상 더 높은지 낮은지는 있겠지만요...

  TCP에서도 소켓 데이타를 못받을 때가 있습니다.
  여기서 못받는다는 의미는 두가지가 있겠죠...
  실제로 데이타가 전송되지 않은 경우가 있겠고...
  전송이 되긴 했는데 프로그램에서 정상적으로 받지 못한 경우죠...

전자의 경우는 해결할 방법이 없다고 생각해야겠죠...
물론 이런 경우를 대비해서 보완 회로를 구성해야하겠지만...

  TCP와 UDP 프로토콜 자체는 하드웨어에서 인식하는 것입니다.
  특히 요즘의 스마트 네트웍에서는 그때 그때의 상황에 따라서
  가장 안정적이고 빠른 경로로 인식되는 곳으로 전송하게 되죠.
  근데 그것이 항상 안정적이고 빠르다고 보장할 수는 없죠...
  0.01%의 오차도 생길 수는 있으니깐요...
  결국 이러한 경우 데이타를 못받을 수 있게 되는 것이죠.

  프로그램상의 문제는 대부분 읽고 쓰는 순서의 조합에 있습니다.
  보낼때는 2번을 썼는데 읽을 때는 한번씩 밀려서 3번 읽어야
  끝까지 다 읽거나 그 반대일 경우가 발생할 때가 있습니다.
  그나마 이것은 읽거나 쓰는 버퍼에서 조절하면 되지만...
  읽어도 읽어도 검출이 안되거나 써도 써지지 않는 경우는 골치 아프죠.

  이 경우는 많은 경우 소켓 설정에 문제가 있을 경우입니다.
  또는 멀티 프로세스나 멀티 스레드로 인한 문제가 가능성이 높죠.
  NODELAY를 말씀 하셨는데...
  구조에 따라 조금씩 다르긴 하지만...
  써 주는 것이 좋다고 생각합니다.
  요즘은 시스템이 워낙 좋아서 약간의 부하는 걱정할 것이 안되니깐요.

패킷이 짤리는 것 또한 인위적으로 막을 방법은 없는 걸로 압니다.
따라서 이것도 염두해 두고 프로그램을 구성해야겠죠.

  결국, 프로그램 아키텍쳐 자체에 대한 문제부터 시작해서
  소켓 구성과 데이타를 주고 받을 때 발생할 수 있는
  모든 경우의 문제점을 case by case로 대응할 수 있는
  시스템을 구성하는 것이 그나마 가장 안정성을 가질 수 있다는 것이죠.

  많은 분들이 프로그래밍 하실 때 꼭 필요한 것, 책에 있는것만
  가장 컴팩트하게 꾸미려고 하시는 경향이 있는데...
  이제는 더 이상 8086과 640K 메모리에서 프로그래밍 하는 것이 아닙니다.
  전 오히려 여유와 복잡하고 커지더라도 넉넉한 프로그래밍을 권합니다.

  이제는 하드웨어적으로 충분히 뒷받침이 되는 상황이고
  따라서 안정성과 신뢰성 자체에 더 관심을 가져야 할 것이기 때문입니다.
  M$처럼 블루 스크린과 구입처에 문의하세요 어쩌구 저쩌구 띄우며
  자기들의 실수를 덮으려 하지 말고 사전에 막아야 하는 것이 좋겠죠.
  물론 예외 처리를 넣는 배려까지 생각해서요...

  횡수가 되었군요...
  하지만...
  많은 분들이 더욱 안정적이고 효율적이면서도 신뢰성 있는
  서버 프로그래밍이 되었으면 합니다.
  저처럼 맨날 시도만 하다가 이런 저런 버그 만들어 내시지 말고... 흐...
        홍성민 (kingduke)

뉴스그룹에다 질문해서 그 답을 얻었습니다. 저도 비슷한
문제를 겪었지만,다행스럽게 저는 간단히 해결했습니다. 다행히 제가
만드는게 이미 고치기 쉬운 스타일이었죠. :)
자,그럼 왜 그런 문제가 생기는지 설명해보죠.. 상당히 자주 올라오는
질문이라는군요. 데이터가 뭉치는건 TCP/IP의 고유 성질이랍니다. TCP/IP가
streaming protocol이라죠.. 괜히 그런 이름이 붙은게 아니랍니다. 더구나, 뭉치는
문제 뿐만 아니라 떨어져서 수신되는 경우도 있답니다. 그렇기 때문에,그러한
문제를 막기 위해서 앞에다 보내는 데이터의 실제 크기를 마킹하거나,텍스트의 경우
CR/LF를 붙인답니다. 떨어지거나 붙어서 날아오는 것을 해결하는건 전적으로
프로그래머의 몫이라는군요. 단,UDP는 이런 문제는 없다고 합니다.
막걸리

송신이되는데 수신이 안되면..
통신이 어느 순간부터 중단되는 문제의 원인은 무지 많다고 알고 있습니다. 우선,
소켓의 상태를 하나하나 점검해보세요. 중간에 어디서 끊어졌다거나 하는거 말입니
다.
그리고, 제가 MFC소켓을 쓰지 않고 그냥 블럭드 소켓을 쓰기 때문에, 정확한 답변을
  하기가 어렵지만, 제가 알기로, MFC소켓은 송신은 블럭드라고 알고 있습니다. 그게
  맞다면, 송신이 되었을 경우 상대방이 그것을 이미 받았다는 얘깁니다.
그냥 짐작하자면, 예전에 여기서 잠깐 이슈였던, 패킷 뭉치는 문제거나, 메시지를
받지 못했다거나, 메시지 큐를 어딘가 꼬아서 사용한 게 아닌가 궁금하군요.
또 하나 짐작되는건..WSAAsyncSelect를 사용하는 경우, 수신 처리에 대해 좀 더 신
중하게 해야 합니다. 그걸 무뎃뽀로 쓰면 짜증나는 뽀록이 생기기 쉬운데, 그런 것
을 쓰는 상황이라면 차라리 아예 winsock nonblocked socket을 쓰거나, 앗싸리 MFC
소켓을 오리지날로 쓰는 게 좋다고 봅니다. 좀더 구체적으로 말하자면, WSAasyncsel
ect는 메시지 처리가 아닌 win32 event로 수신 등을 알리는 역할을 하는데, 그것이
연속해서 두번 이상 발생할 때의 처리를 잘 메꿔줘야 합니다.
                                        막걸리

[질문] virtual PPP 컴퓨터에 UDP송신하기

proxy server

제가 알기로도, proxy server는 '엿장수 맘대로다'라는 점 때문에, 사실 상대
주소를 필요로 하는 직접 연결의 경우 그 proxy server를 만지는 사람들과 대
면해서 정해진 약속에 따라 연결을 해야 한다고 하죠.
ms proxy server의 설명을 따르자면, UDP 연결에 대한 proxy의 조작은,
1. 패킷 내용에 부연 정보를 추가해서 가짜 주소를 송달하는 방법
2. proxy와 인터넷간의 별도 포트를 열어,그걸로 통신하는 방법
이 있다는군요. 1의 방법은 데이터를 컴퓨터에서 조작해야 하기 떄문에
2의 방법에 비해 비효율적이라는 지적도 있습니다.. 아무튼간에,이런
식이라면 이미 언급했지만 사람들을 만나서 약속을 정하지 않으면
안된다는 얘기겠죠. 화수님 대답의 이유가 여기에 있는게 아닌가 짐작되는군요.
근..데! subspace라는 게임은 가상 PPP에서도 돌아간답니다. 하이텔 등과 미리
얘기를 해서 나름대로 proxy를 통과하는 방법을 알아냈다면 할말 없는거지만,
혹시 그들은 proxy의 종류에 상관없이, '일반적인' proxy를 통과하는 UDP 접속 방법
을 알고 있는것이 아닐까요?
아..참고로, VDOlive나 RealAudio등도 UDP를 쓰고 있습니다. 그것들도 조만간
시험해봐야겠군요.
좀 희한한 것들이 발견되더군요.. 우선, subspace 자체도 FAQ에 보면 firewall/prox
y에 물려있으면 게임이 안된다는 말이 있군요. 그런데도 불구하고 proxy.hitel.net
에는 잘

만 UDP 통신을 하고 있구요. 그런 점을 감안하자면, 가짜 PPP로 전화접속네
트워킹을 쓰는 컴퓨터에 한해 proxy를 통과하는 방법이 있는것이 아닐까요? 궁금하
군요.
엘란
..이 문제를 해결하지 못하면, 하이텔 인터넷 등으로는 UDP를 쓰는 게임을 전혀 할
수 없다는 얘기겠죠?
..오늘 하루종일 proxy,UDP등에 대한 키워드 등올 쭉 뒤져봤죠. RFC쪽도 뒤져봤구요
.. 그런데 별다른 얘기는 나오는 것 같지 않더군요. proxy셋업에 대한 얘기까지는
나와있지만요..영어 실력이 딸려졌나? 음.. 하루가 걸리다니.

하이텔은 real ppp에, proxy는 필수가 아니고 선택사양인것으로 알고 있는데요.
proxy를 쓰고 싶으면 쓰는거구 필요없으면 그냥 쓰는거구...
제금 제가 쓰고있는 천리안ppp도 그렇구... 코넷도 그런걸루 알고 있네요.
글고 proxy는 특정 포트(http, ftp등)에만 사용되는것으로 알고 있습니다.
게임 데이타를 케쉬할 필요가 없으니...
게임이 사용할 포트하곤 전혀 관계가 없을텐데요...
real ppp에서 포트가 문제를 일으키는것은 방화벽이 막아버렸을때나 그렇겠죠.
방화벽은 공인된 포트만 사용할수 있으니까요.
섭스페이스가 사용하는 포트를 따로 열어 달라구 네트웍 관리자에게 부탁은
해볼수 있겠죠... 과연 들어줄지 의문이지만...
-- 화수.

네트웍 게임용 네트웍 부분을 프로그래밍 중입니다.
그런데 아직도 확실히 그 접속방법을 모르겠네요.
(우수운 질문인가.. ^^;)
제가 알고/해본 결과로는 TCP나 UDP나 서버/클라이언트가
각각 존재해야 하는것 같은데..
처음엔 TCP는 서버/클라이언트 구조이고 UDP는 서버가 없는구조
라고 알고 있었거든요.
TCP는 Connect가 먼저 되어야 통신이 가능하고,
UDP는 Connect 자체가 없이 IP주소만 알면 통신이 가능한것 같은데..
우~ 뭐 하나 확실한게 없군요.
원래 제 의도는 서버/클라이언트 의 시스템명령(속도를 요하지 않는)은
TCP를 사용하고 서버/클라이언트나 클라이언트/클라이언트 의 데이터명령
(속도를 요하지만 반드시 서버를 통하지 않아도 되는)은 UDP를 사용하려는
것이었습니다.
이렇게 하면 접속이나 그외에 서버에서 데이터를 참조하는 부분만 빼고
실제 게임에 쓰이는 데이터는 UDP를 사용해서 클라이언트끼리 직접
데이터를 주고받게 하여(서버를 거치지 않고) 서버의 부하를 줄일 수 있다
라고..(배틀넷처럼) 하는거였는데.. 음..
글이 너무 길어지는군요...
보시는 분들이 잘 이해하셨을지 모르겠는데.
아시는분 아니면 좋은 의견 있으신분 꼭 답변 부탁드립니다.
네트웍 프로그래밍에 손대시는 분들은 많은데..
모두 각각 같은일을 반복해서 하는것 같아서 좀 안타깝군요.
혹시 네트웍 프로그래밍을 같이 하실분이 계시면 연락 주세요. ^^;
제가 하려는건 배틀넷 방식과 울온(리니지같은) 방식 두가지 입니다.
(그 외에는 없겠지만요.. ^^;)

대표적으로 퀘이크가 있죠.
TCP건 UDP건 피어투피어, 클라이언트/서버방식을 구분짓는것은 네트웍게임에서
어떻게 처리하냐에 달려 있습니다.
패켓로스가 발생하는경우 UDP가 약간 장점이 있습니다.
리얼오디오가 왜 UDP를 사용하시는지 생각해보시면 되겠죠.

둘은 소켓의 연결 방법과 관련된 것이고 서버/클라이언트 구조와는 무관한
것입니다.

TCP연결의 경우 일단 Connect가 되면 소켓이 끊어지기 전까지 데이터의 전송,
수신에 있어서의 연속성이 보장되지만, UDP의 경우 보낸 데이터가 없어지기도
하고 두번 가기도 하고 순서가 바뀌어 가기도 하죠. 대신 속도는 UDP가 더 빠
르구요.

배틀넷같은 경우, 로비부분만을 서버가 관장하고 게임에 들어가면 클라이언트끼리만
통신을 하는 구조입니다. 로비란 말그대로 게임을 하고자 하는 사람들이 서로
만날수 있는 채팅공간을 제공하는 것이죠. 고광현 (Soph )

안녕하세요 회사아이디 쓰는 이경만 입니다.
TCP/UDP는 TCP/IP의 Layer중에 Transfer Layer에 해당하는 것으로
전화와 삐삐의 차이라고 예를 들면 좋겠군요.
TCP는 전화 입니다. 기본적으로 연결이 되어 있는 상태에서
순서적으로 데이터를 보내고 데이터를 안보내더라도
계속 연결을 유지 하고 있습니다. 그러면서 연결은 유지되어 있는가?
등을 계속 체크하면서 트래픽을 잡아 먹지요. 또 계속적으로
에러 체크를 하지요.
그래서 에러가 생기거나 연결이 끊기면 즉각 서버나 클라이언트가 알
고 그부분만 다시 요구하거나 하거나 어플리케이션에 끊겼다고 알리게되지요.
대부분의 어플리케이션들이 많이 사용 하지요.
머그겜들이나 머드겜 등에서..
안정적으로 데이터를 주고 받을 수 있다는 점이 최대의 장점이고
네트웍 회선 상태가 않좋은 경우에도 사용 할 수 있고요.. 인터넷의
TCP/IP의 앞머리 글자인 TCP인 만큼 많이 사용 되는 프로토콜이죠.

UDP는 삐삐나 우편물의 소포를 연상하시면 됩니다. 보내는쪽에서
받는 쪽에 팍 보내주고 신경을 안쓰죠.. 그럼 받는 쪽에선 받은후
다 받았으면 보낸쪽에 야 다받았어~ 만약 받다가 에러나면 얌마
2번 패킷 잘못 받았어 오다가 딴데로 세버렸어~ 라고 메시지를 주면
다시 보내주는 그런 프로토콜이죠.. 보내는 쪽은 보내는 데이터를
정해진크기로 짤라서(이걸 패킷이라고 하죠. 크기가 완전히 정해지진 않았고
최대와 최소 크기만 정해졌지요. ) 번호를 맥여서 보냅니다.
하지만 받는쪽은 순서 대로 받을 수도 있고 그렇지 않을 수도 있지요.
그래서 중간에 빠뜨릴 수도 있겠지요.
하지만 이경우 전송 속도는 빠르겠지요..
네트웍 트래픽이 허용하는 한 한꺼번에 마니 보낼 수 있으니까요.
하지만 만약 네트웍 상태가 별로 않좋다면 다시 보내줘야하는 것들이
많아지니까 오히려 비 효율적이 되지요. 따라서 데이터 손실을 어느정도 인정하는
음성 데이터같은 아나로그 데이터를 전송시 UDP를 마니 쓰게 되지요.
그래서 REAL Audio같은데서 쓰는건 기본적으로 UDP가 되는거고 Mud나

Mug같은 데선 TCP 를 쓰게 되지요..
TCP/IP에 대해 그리고 기본적인프로토콜들에 대해 자세히 공부 하시려면
TCP/IP Illustrated 1,2,3을 보십시요.
이게 바이블이니까여..

fROM PSYCHO

TCP/IP에서의 소켓이벤트 설명.

소켓이벤트의 작동구조를 모르면 정말 어디서 에러가 생긴 것인지 알수가 없더군요.
제가 프로그래밍 하다가 헤맸던것 좀 적어 봅니다.
FD_CONNECT
  소켓을 논블록킹으로 connect()한 후 잠시 있다가 이 메시지가 오는데요, 메시지가
온다고 접속이 성공한 것은 아닙니다. wParam이던가 값을 확인해야 합니다.
에러코드가 없으면 성공한 것이죠. 연결이 된 소켓은 이제 사용이 가능해 집니다.
FD_WRITE
연결되자 마자 send()하면 send()함수에서 에러가 뜨고 GetLastError()해서 에러
코드를 확인해보면 BLOCK어쩌고 나옵니다. 이것은 소켓이 아직 전송할 준비가
안되어 있거나 네트웍상황이 바빠서 '블록'된 상태를 말합니다. 이경우에는 더이상
메시지를 전송할 수 없습니다. 때문에 사용자가 소켓에 전송을 하기 위해서는
소켓이 전송가능 상태가 되었다는 것을 알려주는 FD_WRITE메시지를 받은 후에
send() 해야 합니다. *** 주의해야 할점은 FD_WRITE는 소켓이 사용가능해 진 시점에
한번씩만 통보되므로 send()함수와 1:1 대응관계에 있지 않습니다. 이거 헷갈리면
안되죠.

FD_READ
소켓에 읽어야 할 메시지가 있는 경우 FD_READ가 통보되고 이때 어플리케이션은
recv() 함수로 읽을 수 있습니다. 만약 100바이트가 수신되었는데 recv()에서
50바이트만 읽었다면 FD_READ가 또 통보됩니다. 즉 소켓버퍼에 데이터가 남아 있는
한 계속 옵니다. *** FD_READ 메시지 1개 당 recv() 1번으로 읽는것이 정석이구요,
두번 세번씩 읽으면 이상한 일이 발생하므로 주의해야 합니다. (메시지가 꼬임)
FD_CLOSE, FD_ACCEPT 등등은 뭐 신경쓸게 별로 없더군요.

소켓 프로그래밍에 있어 문제의 핵심은 FD_READ, FD_WRITE, 그리고 블록킹 상황
같더군요. 메시지를 한참 보내다 블록킹 에러 생기면? 더이상 보낼 수 없습니다.
FD_WRITE메시지가 올때까지 기다려야 합니다. FD_WRITE가 오면 그때부터 또 막
메시지 보냅니다. 그러다가 어느순간 또 블록킹 걸립니다. 그럼 또 FD_WRITE
올때까지는 메시지를 보낼 수 없죠. 그럼 그 기둘리는 시간동안 보낼 메시지는
어떻게 하느냐 하면, 메시지 큐 같은곳에 넣어 두었다가 다음 FD_WRITE오면
큐에 남아있는 데이터를 다 전송시키면 되는 거죠. 물론 그것 보내다가도 또

블록킹이 걸릴 수 있으니 주의해야죠.
이런 걸 구현하는데 소켓 1개당 클래스 1로 구현하면 좋더군요. 저도 그렇게
쓰거든요.

사용자 튕기는 문제 ...

안녕하세요. 지금 제가 네트워크 액션 게임을 만들고 있습니다.
다른 부분은 거의 완성이 되었는데 네트워크 부분이 만만치 않군요.
네트워크 부분은 액션형태가 RPG형태의 머그보다 10배는 어려운듯 합니다.
select문으로 유형을 판별한 후 ioctlsocket으로 소켓에서 읽어야 될
데이타를 미리 알아낸후 recv를 합니다.
문제는 select문으로 소켓에 읽어야할 데이타가 있는것으로 판단이 되어
ioctlsocket 함수를 실행하면 dwBytesRead값에 0가 들어오는 경우가 간혹
발생된다는 겁니다.
다른 부분은 거의 잡았는데 위의 문제 때문에 간혹 사용자들이 튕겨나가는
경우가 발생합니다.
소켓 프로그램은 메세지 방식이 아닌 블럭킹모드(맞나?)를 사용했습니다.

while(1)
{
   if(select(socket, &rfds, &wfds, &efds, &tv) < 0)
     continue;

   if(FD_ISSET(connections[i].socket, &rfds)) // incoming data
   {
        addlen = ioctlsocket(connections[i].socket, FIONREAD, &dwBytesRead);
        if(addlen < 0)
          return(-11);

       if(dwBytesRead == 0)
          return(-12);
     recv(...
   .
   .
   .
}

사용자가 튕겨나가는것 자체가 문제가 아니라 ioctlsocket에서 0이 출력된다는게
문제라는게 질문의 요지라는 전제로 답을 해보겠습니다. 물론 정답이 아닐 수
있으니까, 다른 멘트도 있으시면 다른 분들의 답변을 역시 기대합니다.
제가 ioctlsocket 함수를 직접 써보지 않아서, 그 함수가 0을 출력하는 경우에 대한

설명은 못하겠습니다. 소켓이란게 이론을 완벽하게 이해하지 않으면 경험으로
구동방식을 알아내야 하는 경우가 많은것 같아서요..
자 그럼 변을 시작해보죠..

TCP/IP는, FAQ에서 심심찮게 발견되는거지만, send나 WSASend로 보낸 패킷을 그대로

받지 않는다는 성질을 갖고 있습니다. 송신한 내용을 모두 받기는 하지만, 그것이
송신한 내용의 양과 갯수를 그대로 유지하지는 않는다는 뜻입니다.
예를 들어,
aaa bbbbb cc dddd eeeee

이렇게 패킷을 보냈다면, 받는 쪽에서는 꼭
aaa bbbbb cc dddd eeeee
이렇게 받지 않습니다.
aa abbb bbcc ddddeeeee
이렇게 받을 수도 있고
a a a b b b b b c c dddd eeeee
이렇게 받을 수도 있고,
aaabbbbbccddddeeeee
이렇게 받을수도 있는겁니다.. TCP/IP가 스트림 운운한다는거 알고 계시죠?
TCP가 왜 이런 성질을 갖고 있는지는 정확하게는 찾아보지 않았습니다. 하지만, 이런
성질이 있는것은 확실합니다.
그리고, recv에서 0이 리턴되는건 graceful disconnect를 뜻합니다. 그런데, 이게
ioctlsocket에서도 통하는지는 잘 모르겠군요.
우선, ioctlsocket의 문제를 떠나서, ioctlsocket으로 받아야 할 데이터 크기를 정한
다음 받는건 위에서 언급한 TCP의 특성상 잘 동작할 것이라고 생각되지는 않습니다.
이상.. 다른 분들의 멘트도 기대해보고 싶군요.

안녕하세요.
저는 UDP를 사용하는데요.
bind 후에 SOCKADDR_IN 으로 자기 주소가 담겨져 나오는걸로 알고 있는데
UDP 에서는 0.0.0.0 으로 셋팅되어 나오는군요.
그래서 getsockname() 을 사용하는데도 마찬가지로 0.0.0.0 이 담겨 나오는데
혹시 UDP 에서 자기 주소를 알아내는 방법은 없는지요.
VisualC++ 헬프에서 찾아보니까 UDP 는 Connect 되기 전에는 0.0.0.0 이 나온다고
하는데 음.. 쩝.. TCP 하고는 틀린거 같네요..

아래와 같이 하면 자기 주소는 찾을 수 있는데 정확한 답은 아닌거
같네요.
아래 방식 말고 좀더 간단한 방식이 있을듯 ...
하여간 자기 IP Address는 알아낼 수 있습니다.
그럼.

#include "winsock2.h"
#include "stdio.h"

BOOL GetIPAddress(char *Address)
{
SOCKADDR_IN server_sin;
PHOSTENT phe;

     phe = gethostbyname("localhost");
     if(phe == NULL)
        return(FALSE);

     phe = gethostbyname(phe->h_name);
     if(phe == NULL)
        return(FALSE);

     memcpy(&server_sin.sin_addr, phe->h_addr, phe->h_length);
     strcpy(Address, inet_ntoa(server_sin.sin_addr));

     return(TRUE);
};
void main(void)
{
   WORD version;
   WSADATA wsaData;
   char IPAddress[128];

     version = MAKEWORD(2, 0);
     WSAStartup(version, &wsaData);

     if(GetIPAddress(IPAddress) == TRUE)
       printf("%s\n", IPAddress);
     else
       printf("Error !\n");
};

^_^ 전번 부터 Connect 문제를 그냥 참아서 쓰고 있었는데
이번엔 도저히 못견디겠더군요.. 있잖아요
Connect시에 블러킹 되면서(ip를 잘못치거나하면 끔찍한 블러킹이 발생)
프로그램이 정지상태에 이르잖아요~~
쩌비...그렇게 안할려고
넌블러킹 모드로 바꿀려고요~~

icoctlsocket(socket,FIONBIO,(unsigned long *)TRUE);
이렇게 했는데 별소용이 없네요~~ 끄~~~
제가 하고 싶은건요 connect 를시도해서
몇초동안 연결이 안되면 메세지박스를 띠워서
취소 다시시도
여부를 결정해서 진행하고 싶거든요.. 쩝....
^_^ 가능성이 보이는 함수는 여러게 보이고 생각하면 이렇게 될거

같은데... 아직 초보다보니 하는게 맞는지도 모르겟고 다른분들은
어떻게 처리하고 계신지... T_T 아녀요 잘모르겠어요~~
T_T 급한 프로그램이라서.. 엉엉~~
고수님의 답변 부탁 드립니다`~~ ^_^
기다릴깨요~~

setsockopt에서 time out을 설정하면 될겁니다.. recvtimeout,sendtimeout인가..쯤
될겁니다. 어느 쪽인지는 기억이 안나지만.. 확실한건 '된다'는겁니당. 흐흐.

이번엔 비동기 방식으로
FD_CONNECT 메세지로 처리할려니
제가 저한테는 잘 접속되는디 다른 IP에 접속할려니
10061 에러가 나네요 정말이상
WSAECONNREFUSED : 연결 시도가 강제적으로 거부 되었음을 나타낸다

switch(WSAGETSELECTEVENT(Event))
    {
        case FD_CONNECT:        sprintf(String,"Socket Error : %d",WSAGETSELECTE
RROR(Even
t));
                         MessageBox(NULL,String,"",0);
                                                break;
음냐 찌게 졌당 다시...
switch(WSAGETSELECTEVENT(Event))
{
case FD_CONNECT:sprintf(String,"Socket Error : %d",
                                         WSAGETSELECTERROR(Event));
                                         MessageBox(NULL,String,"",0);

break;
이렇습니다...
블러킹 모드로 그냥 connect시는 아무 이상없이 잘접속이 되었습니다
신기하게도 자기자신한테 접속할땐 0 이나옵니다 에러없음...

IP는 살아 있으나(?) PORT(서버)가 준비 안되었을때 발생하는 에러입니다.
서버가 제대로 실행되었는지 확인해보세요... port번호도...

안녕하세요?

UDP 를 공부하고 있는 사람입니다. 흑흑.. T_T
네트웍 프로그램을 손댄지가 얼마 안된지라..
이렇게 질문만 하게 되는군요..
UDP 에서는 여러사람에서 동시에 데이터 보내는게 가능하다고 하는데.
어떻게 하는지 아시는분 좀 갈켜주시기 바랍니다.
그리고 동시에 데이터를 보내면 그 데이터가 어떻게 처리되는건지.. 쩝..
보내는 사람은 한번만 보내고 ISP 처리하는곳에서 여러곳으로 분리해서
쫘악~ 보내버리는건지..
음... (으.. 알아가는것보다 모르는게 점점 많아지는군요..
언젠간 모르는것보다 아는게 너 많아지겠죠.. T_T)
그럼 부탁드립니다.

Broadcast는 실제적으로 데이터전송 퍼포먼스와는 무관하답니다.
사용상 편의에 불과한거죠. 사용법은 192.168.1.x등입니다.
위의 경우는 클래스C급이구요 서브넷마스크와 연계되겠죠.
이 같은 경우 x가 최대값 255가 됩니다. 그러면 x가 0부터 254까지의
IP를 갖는 대상에게 Broadcast하게 되는거죠. 자동으로.
어차피 로컬에서나 사용되니 UDP나 IPX나 별 상관없을 것으로 생각됩니다.

PS. 오늘 UDP로 Broadcast시키는 채팅프로그램을 만들었는데
     마침 이런 질문이 올라오는 군요.
     게임 채팅에서 UDP가 적절할듯 합니다.
     실제로 채팅이나 메일등에 UDP가 사용된답니다.

포트번호란

안녕하세요.. 리믹입니다..
tcp/ip를 사용할때는 반드시 포트 번호를 사용하는데요..
포트번호란 각 응용프로그램이 가지고 있는 고유 번호라고 생각하시면됩니다
머리가 나쁜관계로 기억이 잘 안나는데.. ftp나 telnet 프로그램들역시
고유한 포트 번호를 가지고있습니다.. 이외 모든 tcp/ip를 사용하는 프로그램들이
각각의 고유 포트번호를 가지고있는데요 이번호들은 중복사용되어서는 안됩니다.

음.. 좀더 깊이 얘기를 하자면(짧은 지식이 들통날꺼 같은데.. -_-)
보통 한쪽 컴퓨터에서 다른쪽 컴퓨터로 정보를 보낼때 가고자하는 종착지를
찾는 단계가 있습니다..
자세한 정보는 네트윅 관련책들을 보시구요..
일단 하드웨어적으로 가고자 하는 목적지를 찾은다음..
과연 이 정보가 어느 프로그램으로 가야하는지를 찾습니다..
바로 어느 프로그램인가를 구분하는게 포트번호입니다..
좀 두서 없이 얘기한거 같은데.. 도움이 되셨는지.. -_-

워낙 말재주도 없구 실력두 없어서리.. -_-
바람돌이 리믹였습니다.. 좋은 하루되시길.. ^^

안녕하세요.

소켓프로그램을 API로 만들고 있습니다.
TCP/IP로 서버와 클라이언트간 패킷을 보내는데
패킷 데이타의 버퍼크기를 지정할 수 있다고 들었는데 그 함수와
어떻게 쓰는지 간단한 예 부탁드립니다.
그리고 버퍼크기를 지정하는 이유도 알고싶고요.

또 간단하게 캐릭터들도 왔다갔다하는 머그형태를 만들었는데
이상하게 클라이언트가 많이 접속하니까 몇몇 클라이언트가
SEND와 RECV를 제대로 못하는거 같았습니다.

부하를 줄이는 것도 중요하지만 거의 먹통이 되는.. -_-;
어떤 클라이언트는 잘되는데 어떤건 안되네요.
또 어떤건 키를 누르면 자기는 안되는데 상대는 자기가 움직이고있고..

버퍼문제가 아닐까 싶어서요..

에고 그래서 조금 정리하고 추가해서 다시 질문드릴께요.

1) SEND/RECV시 버퍼지정 쓰임새, 버퍼지정함수를 어떻게 쓰나요?
2) WSASEND/RECV등이 있던거같은데 그냥 SEND/RECV와 차이점이 몬가요?
    또 어느게 더 효율적인지..
3) SEND/RECV시 비동기화와 넌블로킹을 씁니다.
    쓰다보니 비동기화는 그렇지만 넌블러킹은 패킷을 안보내고안받을수도 있으니까
    위험하진않은지.. 궁금합니다.
4) 넌블러킹했을때 SendMessage와 PostMessage를 써서 WD_WRITE,WD_READ등을
    돌리는데 (일반적인 형태인걸로 압니다) 보통 메세지처리중 SendMessage
    를 쓰는지 PostMessage를 쓰는지 알고싶습니다.
    Post를 하니까 부하는 적은데 제대로 보내질않아 캐릭터가 껑충껑충 뛰는 --;

  Send는 거의 잘 받는 반면 부하가 커서 클라이언트가 많으면 패킷을 아예
    보내지 못하는 듯합니다.

너무 많은 내용인거같아서 정말 죄송한데요.
제가 이 문제때문에 너무 골치가.. T_T
간단한 채팅이면 별 문제가 안되는데..
DX를 쓴 머그형태라.. 패킷송수신양도 많구해서 클라이언트가 많아지면
문제가 생겨서 꼭 부탁드립니다.
참고로 3명정도는 괜찮던데 5명넘으니까 WIN95,98은 괜찮던데 NT를 쓰는
몇몇 클라이언트들이 먹통이 되버리더라고요. --;

꼭 부탁드릴께요~.

흠냐.. 뭐 부터 말씀을 드려야 하나,... 흠..
소켓의 방식에는 블럭킹, 넌블럭킹, 비동기...
이렇게 세가지 방식이 있습니다.
넌블럭킹으로 할려면 오버헤드가 커집니다.
왜냐! 물론 제대로 동작이 이루어졌는지 계속 확인해야
하는 일이 있기때문이죠. 더군다나 그 책임은 프로그래머 몫입니다.
윈도 방식에서는 일반적으로 비동기 방식이 쓰입니다.
성능이나 여러 문제에서 양호하기 때문이죠.
저같은 경우는 데몬처럼 처리되는 소켓 쓰레드를 생각하므로...^^;
저는 블럭킹 방식을 사용합니다. 대신 timeout을 작게 잡지요..
물론 이 방식이 제대로인지는 아직 확실히 테스트 해보지
못했습니다.

send/recv와 WSASend/WSArecv의 차이는... 없습니다... 기본적으로
쓰시면 없어요. 하지만 WSA~ 붙은 거는 윈속 2의 새로운 기능들을

가능하게 합니다. 예를들자면 중첩소켓이나 QOS나...
이런 걸 사용하지 않는다면 그냥 send/recv 쓰세요..
저의 경우는 중첩입출력을 하는 소켓을 이용하므로...
WSA~ 가 붙은걸 사용하죠...^^;

버퍼 문제는 그냥 버퍼의 포인터를 넘겨 주는 것이지..
별도의 버퍼지정 함수나.. 그런건 없는거 같습니다.
윈속2의 멀티 버퍼도... 스캐터/개더링 을 이용하지 않는다면
필요가 없는 듯 합니다... (맞나요??? 이궁..)

메시지를 포스트하냐... 센드하냐...
이 문제는 잘 모르겠군요. 왜냐하면 저는 메시지 방식이 아닌..
이벤트 방식을 이용하므로....^^;
하지만 생각해 보니... 강제적으로 보내는 센드의 경우...
훨씬 빠르겠죠.. 포스트보담... 결국 빠른 반응속도가 필요한

경우는 어쩔수 없이 직접 보내야 할듯..
하지만 이 경우 부하는 어절수가 없는 거 같네여..
다른 방법을 찾아보세요~~
이만.. 참고가 되었기를..
덧> 예제 많은 세상에서 살구 싶다~~~~
내가 쓰는 함수의 예제가 전무하다닛~~~ 이잉..

안녕하세요~ 답변받아 여기만 오면 기분이 좋은 새내기입니다 --;;

광현님 답변 잘 받았습니다.
자체 큐형태를 지금 저도 생각해보기로 했습니다.
상당히 괜찮을꺼 같군요.

지금 질문드리고 싶은건
FD_READ로 수행할�㎖ recv함수로 패킷을 받은후 다 못받으면
FD_READ를 다시 호출하는 것에 대해서입니다.

case FD_READ:
         recv(socket,buffer,10,0);
         if (buffer==1) recv(socket,buffer,20,0);
         break;

대충 제 프로그램 돌아가는 형태입니다.
서버에서 send를 30byte 보냈습니다.
클라이언트에서 recv로 받는데 전 헤러 10byte받은후
더
헤더가 1이면 나머지 20byte를 받아라~ 이렇게 했습니다.

근데 이 프로그램에 문제가 있나요?

오늘 책에서 보니 FD_READ에서 recv받고 다 못받으면 다시 FD_READ를
호출한다고 했습니다.
그럼 결국 recv(socket,buffer,10,0)만을 3번 반복해버리고
if를 마지막에 수행하는게 되나요? --;

아님 recv(socket,buffer,10,0)해서 10byte받고
if문 수행후 다시 FD_READ로 recv 다 받을때 까지 반복하는건가요.

헉.. 정말 어렵네요.
질문은 좀 복잡하지만 네트웍프로그래밍하시는 분은
다 아실꺼같아서 꼭 질문드립니다.
까딱하면 완전히 소스를 어퍼야 할 상황이네요 -_-;;

부탁드립니다.

* buffer로 미리 다 받은 후 인자에 값을 넘기는 방법도 생각했었습니다만
   문제는 인자크기를 미리 알수 있는 방법이 없구요.
   인자크기를 알기위해선 어쩔수없이 한번은 헤더를 읽을 수 밖에 없는
   거 같은데.. 흑~

TCP 라면..
패킷이 어떻게 쪼개질지는 예측할수 없습니다..
30바이트를 보냈다면..
10바이트로 3번 읽힐지,
30바이트로 한번에 읽힐지..
5바이트씩 6번 읽힐지.. 모릅니다.
보통 로컬랜에서는 왠만하면 한큐에 읽히긴 합니다만..

아무튼,
recv를 몇번 호출해야하는이 모르죠.
Async소켓 쓰신다면, 큐를 만들어 FD_READ 올때마다 넣어야 합니다..
꼭 받아야할 데이타라면 데이타 완료 될때까지 메인 루프는 중지해야겠죠..?
메세지 받고.. 검사하고.. --;
아무튼.. 그럴바엔 블러킹소켓 쓰는게 낫지요..

저는... Async 소켓은.. 비추천입니다.. --;;
2주전 입사했는데, 소켓을 구현을 Async로 해놓았는데.. 곧 갈아엎는다네요..

구조에 따라 다르겠지만.. 전 고전적인 I/O 멀티플렉싱.. (select/poll)이
제일 좋은듯.. 싶네요..

- Testors

코드에 오류가 있습니다.
        recv(socket,buffer,10,0);
         if (buffer==1) recv(socket,buffer,20,0);
  여기서 buffer는 buffer[]형태의 배열이나 할당받은 메모리의 포인터일텐데
  buffer == 1이 성립할 수 없지요. 또한 FD_READ 메시지에서 두번의 recv를 하면
  이후에 메시지 동작이 정상적이지 못하게 됩니다. 즉 하나의 FD_READ에서는 한번의
  recv만을 해야 합니다. 간략하게 코드를 써 본다면 다음과 같습니다.

int iRemainBytes = 2;          // 헤더의 크기는 2바이트로 고정되었다고 설정
  int iRet;
  char * pBuffer, cBuffer[256]; // 메시지를 받을 버퍼와 포인터
  char cReadMode = 1;            // 1이면 헤더를 읽는 중, 2이면 본체메시지
  short * sp;

  pBuffer = (char *)&cBuffer[0];

  case FD_READ:
        switch (cReadMode) {
        case 1: // 헤더를 읽던 중이다
                iRet = recv(socket, pBuffer, iRemainBytes, 0);

      if (iRet == 0) {
                        // 소켓에러임. 블록킹이 아닌 치명적인 에러라면
                        // 소켓을 끊는 수 밖에 없다.
                }
                else {
                        // 헤더를 읽었다. 헤더 2바이트를 다 읽었는지 검사
                        iRemainBytes -= iRet;
                         pBuffer += iRet; // 읽은 바이트 만큼 포인터 이동

                        if (iRemainBytes == 0) {
                                // 헤더를 모두 읽었다. 헤더를 분석
                                // 헤더 2바이트 메시지의 사이즈라고 설정
                                // 되었으므로
                                sp = (short *)&cBuffer[0];
                                // 앞으로 읽어야 할 몸체의 사이즈는

                          iRemainBytes = *sp;
                                // 몸체 읽는 모드로 변환
                                cReadMode = 2;
                        }
                }
                break;

        case 2:
                // 몸체를 읽는 모드다.
                iRet = recv(socket, pBuffer, iRemainBytes, 0);
                if (iRet == 0) {
                        // 소켓 에러다. 블록킹이 아닌 치명적인 오류라면
                        // 소켓을 끊는 수 밖에 없다.
                }
                else {

        // 몸체를 읽었다. 읽은 사이즈 만큼 남은 바이트 수를
                        // 뺀다.
                        iRemainBytes -= iRet;
                        pBuffer += iRet;
                        if (iRemainBytes == 0) {
                                // 몸체 메시지를 모두 읽었다. 이 작업이 끝나면
                                // cBuffer[]에 전송한 메시지가 헤더부터 모두
                                // 저장된 상태다. 프로그래머는 여기서 cBuffer
                                // 의 메시지를 읽어 수신 메시지 큐에
                                 // 넣어 처리하면 된다.

                                PutRcvMsgQuene(cBuffer);

                                // 다 읽은 메시지를 반환하고 읽는 모드를 다시
                                // 헤더 읽는 모드로 초기화 한다.

                            cReadMode = 1;
                                pBuffer = (char *)&cBuffer[0];
                         }
                }
                break;

  비동기 소켓을 이용한 수신 루틴의 구조는 대략 위와 같습니다. 윈도우에서 이러한
메시지 방식의 소켓 운용방식에 대해서 처음에는 여러가지 걱정을 하고는 했는데
생각보다 Winsock의 비동기방식 동작은 만족스러운 수준입니다.

  현재 이런 방식을 사용하는 헬브레스 서버는 펜티엄II 300의 시스템에서 500명을
수용해도 별 문제가 없거든요.

몸체 메시지를 다 읽은 다음 읽기 모드를 초기화 할때 앞으로 읽어야 할 사이즈는
헤더값이므로 iRemainBytes = 2로 설정해 주고 끝내야 겠죠. (수정) 고광현 (Soph )

안녕하세요..
헉.. 또 이렇게 질문드리게 되네요 -_-;;

그렇다고 질문을 마구 올리진 않을꺼에요 ^_^;;

윈95,98과 윈NT에 패킷을 받을때 처리되는 형태가 틀린거 같습니다.
윈95,98은 그때그때 반응을 하는데 비해
윈NT는 받는 패킷이 많아질수록 동기화가 안되거든요.
이상하게 운영체제에 의해 문제가 생기는거 같습니다
(PC가 좋고나쁨이 아니구요. 그런문제였다면 완전한 동기화문제일텐데)

아무래도 제가 생각하기엔 버퍼문제인거같은데
제가 듣기론 setsockopt를 통해 받을 수 있는 패킷버퍼를 조절할수
있다고 들었습니다.
MSDN이나 네트웍책등으로 설명된 걸로는 너무 어렵고 어떻게 쓰는질

몰라서..

setsockopt로 버퍼량 조절에 대한 간단한 함수예를 들어봐주셨음
좋겠습니다.

그리고 혹시 운영체제가 다른탓으로 이런 경우가 생기신 분있는지도
궁금하구요.
문제발생은 클라이언트쪽 운영체제였습니다.

그럼 부탁드릴께요

SOCKET s;
int buf=0x1000;
setsockopt(s,SOL_SOCKET ,SO_SNDBUF,(const char*)&buf,sizeof(buf));
setsockopt(s,SOL_SOCKET ,SO_RCVBUF,(const char*)&buf,sizeof(buf));
이렇게 하면 됩니다.

근데,동기화가 문제라면..글쎄요,저걸로 해결될지 의문이군요. 혹시 패킷 뭉치고
쪼개지는 현상에 대한 처리를 안하신거 아닌가요?

자신의 IP 얻기

BOOL CAsyncSocket::GetSockName(CString& rSocketAddress, UINT& rSocketPort)
{
        SOCKADDR_IN sockAddr;
        memset(&sockAddr, 0, sizeof(sockAddr));

        int nSockAddrLen = sizeof(sockAddr);
        BOOL bResult = GetSockName((SOCKADDR*)&sockAddr,
&nSockAddrLen);
        if (bResult)
        {
                rSocketPort = ntohs(sockAddr.sin_port);
                rSocketAddress = inet_ntoa(sockAddr.sin_addr);
        }
        return bResult;
}

BOOL CAsyncSocket::GetSockName(SOCKADDR* lpSockAddr, int* lpSockAddrLen)
{ return (SOCKET_ERROR != getsockname(m_hSocket, lpSockAddr,
lpSockAddrLen)); }

..출처는 MFC4.2의 CAsyncSocket 구현부입니다. 잘 돌아가네요

안녕하십니까...

또다시 질문이 있어서....^^;

지금 이벤트 객체를 이용한 윈속2 프로그래밍을 하고 있습니다.

제가 알기로 버클리 타입의 recv()나 send()는
송수신 시 모든 데이터를 한번에 잘 받지 못하는 것으로
알고 있습니다. 그래서 예를들면, 수신시에 받은 데이터를
계속 축적하는 예제를 많이 보았습니다.

저는 지금 WSARecv()나 WSASend() 함수를 이용해서
데이터 송수신을 하고 있습니다.
지금 궁금한 것은 이 두 함수를 이용할 때에도
위의 버클리 타입의 함수에서와 같이 데이터 축적이

필요한 지입니다.

WSA~함수를 이용한 예제에서 데이터 축적을 하는 것을
보지 못한 것 같아서요.

고수님들의 답변 부탁드립니다.

아래 질문에 이은 초보적(?)인 질문입니다..

일반적인 send/recv 함수를 쓴다고 가정하고.
한번의 FD_READ에 상대가 보내준 모든 데이터를
다 읽을 수 있는 건지요.
그러니까.. 1000바이트를 보냈다면, 1000 바이트를
모두 수신해야 FD_READ가 발생하는 것인지.
제가 알기론 분할이 되어 오기때문에 한번에 다 받지
못하는 경우가 많은 걸로 알고 있습니다.
그렇다면, 한번에 받아야 하는 메시지를두번에 걸쳐 받게되고..
그렇다면 버퍼의 인덱스를 기억해야 하는 것 같군요.

도한 메시지의 길이가 가변적이라면,
이 메시지의 길이를 체크해야 하는 것도 같구요.

전반적인 FD_READ/FD_WRITE가 발생하는 시점이나..
상황에 대해 아직도 감을 못잡고 있습니다.

일단 제가 알고 있는 것을 정리하자면..
FD_READ의 경우, 송신측에서 보낸 데이터를 일부라도
수신하면 발생하고, 이때 일부분을 수신해서 버퍼에 넣고
버퍼의 인덱스를 조정하며, 다음 FD_READ때에 이어 붙인다.
이때, 전체 메시지의 길이를 체크해서 전체메시지가 들어왔다면
메시지를 리턴하고, 인덱스를 0으로 돌린다.
(WSAEWOULDBLOCK은 어떤건지 잘 이해를 못하고 있습니다)

FD_WRITE의 경우, 한번에 전체 메시지를 다 보내지 못하는 경우가
있으므로 일정량씩 끊어서(얼마정도 끊어야 하는지 모름...-_-;;)
계속 송신해 줘야 하며, 전체 메시지 길이만큼 보냈다면 작업을 마친다.
(이 경우도 WSAEWOULDBLOCK은 잘 모르겠구요,,,)
그리고 한 이벤트를 처리해 줄때, 여럿의 SEND나 RECV를 해주어도
문제가 없는지....

하... 정말 모르는 게 많습니다.
아직도 윈속에 대해 잘 모르니...
답변 부탁드립니다. ^^;

원속 1.1 기준으로 말씀드립니다.

FD_READ는 소켓 버퍼에 데이터가 수신되었을때 발생하는 메시지입니다.
1000바이트를 전송했다면 한번에 1000바이트 다 받을 수도 있고 데이터가 몇개로
쪼개져서 수신될 수도 있고 아니면 두번에 걸쳐 보낸 데이터가 한개로 합쳐져서
수신될 수도 있고 합쳐진 것이 또 쪼개져서 수신될 수도 있습니다.

이것은 소켓2에서는 어떤지 모르겠습니다. 아마 마찬가지 아닐까요?

어쨌거나 이러한 메시지의 조각들이 도착할때 마다 FD_READ 메시지가 발생하고 그때
recv함수를 콜해서 수신된 만큼만 받아서 버퍼에 저장하면 됩니다.

FD_READ를 사용하여 가변길이의 메시지를 받는 코드 예제를 제가 아래에 써 놓은
것이 있으니 참고하세요.

FD_READ가 메시지가 수신될때 마다 발생하는데 비해 FD_WRITE는 소켓이 처음 생성된
후에 사용이 가능해진 시점이나, 아니면 블록킹 된 후 다시 소켓이 사용 가능해 진
시점에 통보된다는 점이 다릅니다.

블록킹 상황이란 주로 send할때 발생하는데, 네트웍상황으로 인해 데이터의
전송이나 수신이 불가능한 상황을 말합니다.

데이터를 전송하다가 블록킹이 걸리면, 보내지 못한 데이터를 메시지 큐같은 곳에
보관해 두었다가 다음 FD_WRITE메시지가 오면 보내주어야 겠죠.

UDP에서 자신의 IP 얻기

UDP 에서 자신의 IP 얻기라..

자신의 IP를 얻는다는것은 TCP 같은 Connection 지향적인 소켓의경우
연결되었을때.. 연결된 인터페이스의 해당 IP를 얻는다는뜻이기 때문에.. (??)

음.. 말이 꼬이네요

아무튼 한 컴터가 IP를 여러개 가질수 있다는건 아시곘죠.
예를 들자면 모뎀으로 PPP 연결이 되어있고, Lan 카드가 꽃혀있어
내부 네트웍이 구성되어 있을때,
자신의 IP라 한다면 PPP서버로 부터 얻은 IP도 있고,
내부 네트웍에서의 IP도 있습니다.
비단 이런 경우 뿐 아니라 랜카드가 여러개 꽃혀있을수도 있고..
하기때문에 복수의 IP를 갖게 되는경우는 많습니다.

그렇기 때문에 TCP류의 프로토콜은 연결한 후에 소켓 핸들로 어떤 인터페이스와
연결되었는지 확정된 후 해당 인터페이스 연결의 IP를 얻어내도록 되어 있습니다.
그래서 UDP에서 getsockname()을 써도 "0.0.0.0"만 돌아올겁니다..

내부 네트웍에서 자신의 주소가 192.0.0.1 라면.. 내부 네트웍에 물린
클라이언트가 자신의 컴터에 접속했을경우.. 192.0.0.1을 돌려주지만,
PPP로 어떤 컴터가 접속하면.. 자신의 주소는 PPP서버로부터 받은것이
맞겠죠.

가령 UDP서버를 만들었을경우, 어느 인터페이스로 오는 전송도
받을 수 있습니다..
이런 이유로.. 연결같은게 없는 UDP에서는 소켓 핸들을 이용해
자신의 IP를 얻는것이 없습니다. (라고 알고 있습니다)

자신의 IP를 써야겠다.. 한다면..

자신의 IP 를 모두 뽑아서.. 적당한걸 쓰면 될지도..
자신의 IP 리스트 보여주는 소스는.. 아래 붙여놓습니다..

        char buf[100];
        gethostname (buf, 100);
        HOSTENT *p;
        p=gethostbyname(buf);

        struct in_addr *ptr;
        char **listptr=p->h_addr_list;

        switch(p->h_addrtype) {
        case AF_INET:
                while((ptr=(struct in_addr *) *listptr++) != NULL) {
                         printf("%s\n", inet_ntoa(*ptr));

}
}

- Testors

Direct Play의 성능을 의심해서,
직접 TCP/IP를 이용하여 소켓프로그램을 짜려고 생각하고 있습니다.
  (아직 네트워크의 기본도 모르고 있는 접니다만...)
그런데...막상 시작하려고 하니 IP위에 TCP를 얹을까 아니면 IP위에 UDP를
얹을까 결정을 못하겠습니다.

   물론 UDP가 속도는 빠르고 안정성은 떨어지고
   TCP가 안정성은 뛰어나나 속도는 느리다.

는 것은 알고 있습니다. 그러나 실제로 어느 정도인지 경험적으로 알지
못하겠습니다. 여러 고수님들은 알고 계시겠죠?
거의가 TCP를 이용하여 프로그램을 짠다고 하는데 어떤 프로그램이 그런지?
또, 실제로 UDP를 통해서 게임프로그램을 짜는 경우가 있기는 있는지요?

일반적으로 게임 프로그래밍은 TCP를 사용합니다.
거의 모든 데이타가 없어져서는 안 되는 것들이기 때문이죠.
속도는 머 그다지 걱정하지 않으셔도 될 듯...

TCP가 데이타의 안정성 때문에 사용하는 것이라는 것에서 유추해 보면
UDP가 사용되는 상황도 알 수 있겠죠.
그다지 중요하지 않은 데이타, 일부 소실되어도 상관없는 데이타들을
다룰 때 사용합니다.

아마도 스타크의 로비 채팅이나 ID확인등은 UDP를 사용하는 듯......

먼저 데이타의 중요성을 결정하시고 그 다음에 속도를 고려하시는 게
좋을 듯......

안녕하세요 이경만 입니다.
외국 게임들을 보면 에버퀘스나 퀘이크3등 몇몇
게임에서 UDP를 많이 활용하는 추세 입니다.
사실 정확히 말하자면 두가지 다 사용 하는것이 되겠군요.
로긴과정과 같이 서로간에 동기가 필요한경우
TCP를 씁니다.
그리고 캐릭터의 행동정보나 위치정보등 수시로 계속 주고 받으면서
왔다갔다 하는 정보는 UDP를 쓰지요.
이유는 어짜피 계속 왔다 갔다 하는 정보이므로
중간에 한두개쯤 빠져도 상관이 없는 것이죠.
그리고 UDP를 쓴다면 반드시 패킷안에 서버와 클라이언트의
시간 동기화를 해줄만한 프로토콜 인자를 정의해야 합니다.
TCP를 쓴다면 하나의 기능별로 끊어줄 기준을 마련하기 위해
Size정보가 프로토콜 인자로 들어가야 하듯이요.

게임에서 소실되어도 되는 데이터란..
네트웍 엔진의 구현방식에 따라 차이가 있겠지만..
소실되어도 되는 데이터란 없다고 보는게 맞겠죠..
스태크래프트의경우 게임에서는 UDP를 사용합니다. (로비에선 TCP입니다)
만약 소실되어도 되는게 UDP라면.. 사이오닉 스톰을 지졌는데
템플러가 멀뚱멀뚱 보고만 있는.. 사태가 일어나겠죠.
동기가 맞지않는 리니지같은 게임도 있습니다만..
누구도 그런걸 만들고 싶어하진 않겠죠..?

안정성 없는 프로토콜이라고 하셨지만,
UDP는 게임에선 필요없을수도 있는 그런?처리가 없다는것이 장점입니다.
그런 안정성을 보완해주는 코드만 light하게 작성해준다면
리얼타임게임에서는 UDP가 TCP보다 훨씬 더 좋은 성능을 내 줍니다..
실제로 UDP 사용시
패킷 소실에 대한 재요청/응답과 그에관한 동기처리를 해주게 됩니다.

그리고 매 패킷의 순서를 검사하는것도 필요합니다.
(UDP는 원래 패킷이 사라지기도 하니까.. 하면서 그냥 쓰거나 하지는 않는다는
예기입니다)

처리를 하면서까지 UDP를 쓰는 이유는
TCP에 비해 패킷 헤더 사이즈가 작다는데 있습니다.
왠만한 전략시뮬레이션게임을 TCP로 구현했다간 모뎀 사용자들은
플레이 해보지도 못하겠지요.
그리고 중요한것은 게임 플레이시 패킷소실이 일어날 확률은 매우 적다는 것입니다.
분명, 일어나긴 일어납니다만 그에대한 처리에 걸리는 부하를 계산하더라도
TCP보다 월등한 성능을 내주게 됩니다.

아무튼.. TCP를 쓰느냐 UDP를 쓰느냐는 어떤 게임을 만드느냐에 따라 다르겠지요
왠만한 그래픽 머드의 경우 사용자 1000명정도까지는 TCP로도 되지 않을까 생각
합니다만.. (그이상이 되면 UDP를 쓰는걸 고려해야 하겠지요.. 아마 울온도

UDP라고 알고 있습니다...)
스타크래프트같은 경우는 TCP로는 무리가 있습니다.
시간에 비해 패킷의 갯수가 많다싶으면 UDP, 아니면 TCP쪽이 낫겠네요.

그리고.. UDP다루는것과 그에따른 동기화 처리는.. 생각보다 어렵답니다..
네트웍 프로그래밍을 처음 하시는거라면 일단 TCP를 써보시는게 좋을듯 하네요.

- Testors

ps. E로 덧붙입니다. 위에 지적해주신것처럼 울온은 TCP라고 하네요.

분석해보면 TCP입니다.. ^^;
그리고 아랫글에 없어져도 되는 데이터란..
머그 게임에서 캐릭터의 위치정보등 그 시간이 지난 후
다음번 데이터가 오면 가치가 없어지는 데이터를 말합니다.
어짜피 프로토콜을 구현할때는 상대 좌표가 아닌 절대좌표를
전송해야 합니다. (동기화가 안되므로 이렇게 해서 보정해 주려고 하는거죠.)
따라서 계속 해서 위치정보가 절대좌표로 오는데 기존의 절대좌표는 무시되면서
(물론 이렇게 움직일 수 있는 범위를 검증하는 과정은 서버측의 데이터로
해야겠지요.) 다시 갱신되는 것이죠.
따라서 이런 위치정보는 UDP로 구현되도 상관이 없습니다.
물론 접속하는 유저수가 수백 수천인 게임에서 말이죠..
__
이경만

아니요. 너무 상식적인 답변이 아니라....저에게는
너무나도 고마운 답변이었습니다. 인호님.
정말 감사.
이렇게 자꾸 질문을 드려 죄송하지만...
여기가 가장 정보를 얻기 좋은 곳이거든요...
시간이 없는데 책에도 없는 내용이 이곳에는 있어서.. 이렇게
염치불구하고 계속 묻습니다.
혹시 그렇다면 TCP와 UDP는 공존할 수 있습니까?
예를 들어 한 프로그램에서 TCP함수인 write함수와
UDP함수인 sendto를 같이 쓸 수 있나요?
그럼 답변 부탁드립니다.
게제동 화이팅!
꾸벅.

안녕하세요.

tcp와 udp가 공존은 가능하죠.
한 프로그램에서 둘 다 이용할 수 있으니까요.
그렇지만 한 소켓으로 두 프로토콜을 다룰 수는 없는 걸로 알고 있습니다.
두 프로토콜을 동시에 사용하려면, 서로다른 2개의 소켓이 필요합니다.
각각 다른 프로토콜로 진행되겠지요.

그럼.

UDP헤더는 8바이트이고 TCP는 20바이트입니다.
IP레이어도 헤더가 있죠. (20바이트)
결국.. TCP를 쓸때 헤더는 40바이트쯤 되겠네요
하지만.. TCP의경우는 패킷확인과정이 있기 때문에..
데이터패킷 말고 다른것들도 몇번 왔다갔다 하지요.
아마 2번인가 5번인가로 들었습니다만..
응답시간이 UDP에비해 매우 떨어집니다.
해서 리얼타임성이 요구되는 곳에는
UDP를 쓰는게 낫습니다.
스타처럼.. 빠르게 진행되면 UDP..울온처럼 느릿느릿하면 TCP를 선택하는게 좋겠네요
안녕하세요...

저혹시 ip하고 서브네트 마스크를 구하는 방법을
알수가 없을 까요...(자신의 컴퓨터에서)
ip는 구하지 않아도 되는데...
서브네트 마스크는 꼭 구해야 하거든요...
내부 내트웍의 ip들을 구하려면 꼭 알아야 한다고 해서....
혹시 서브네트 마스크를 구할수 있는 방법을 알고 계시면
제발 좀 가르쳐 주세요.....

질문이 잘 이해가 안가지만..흠..
일반적으로 마스크 씌울 때 분류되는 부분만 빼고 1로 채워넣으면 됩니다.
10진수로 C클래스를 예를 들면 255.255.255.0 이겠죠.
앞의 세 옥텟은 network 식별이고요. 맨 뒤에 옥텟은 호스트를 식별합니다.