2012-02-06 8 views
0

이것은 내가 몇 번 겪어 본 것입니다. 잠시 휴식을 취한 후에 클라이언트 용 응용 프로그램으로 돌아가지만 실제로 구현하기 전에 몇 가지를 기억하고 싶습니다. .소켓 C++ - 비 블로킹 또는 선택 접근 방식

여기서 TCP를 통해 서버 바운드 포트에 연결하는 클라이언트를 처리하는 다중 클라이언트 서버에 대해 이야기 할 것입니다.

select(), FD_ISSET, FD_ZERO, FD_SET을 사용하여 이것을 코딩 한 것을 기억합니다. 내 서버에서 연결된 클라이언트 목록을 수락하고 관리하는 패밀리 메소드입니다. 간단한 32 플레이어 RPG 게임에 대해 - 너무 빠르게 진행되지 않으므로 여기에 TCP가 있습니다.

간단한 GO_TO 패킷, WEATHER 변경, TIME 업데이트, TEXT 메시지, 항목 상태 변경 및 종료, 로그인 (브로드 캐스트) 및 지금 찾을 수없는 항목.

내가 오늘 잠을 자지 못하게하는 이유는이 서버가 원활하게 실행되도록 선택해야한다는 것입니다 (네트워킹 성능에 대해 말할 때).

사람들은 ioctlsocket (..) 또는 다른 '스레딩'괴물을 사용하여 소켓에 '논 블로킹'접근 방식에 대해 많이 언급하는 경향이 있습니다. 이러한 방식을 사용하면 다른 스타일로 제어해야합니다. 네, 저는 이것을 시도해 보았습니다. 응용 프로그램에서 많은 스레드를 다루는 많은 접근법을 보았습니다. 실제로 복잡하게 된 것은 무엇입니까?

메시지를받는 MSDN "ASYNCHROUNOUS"소켓도 보았습니다. 소켓에서 -하지만 이것은 너무 많이 생각합니다. 그래서 그 대신 내가 생각하고 물어 싶습니다 코딩의

,

  • 경우 선택() 게임 서버의 말할 때의이 simultanously 그 (32 명) 선수를 가정 해 봅시다 처리, 트릭을 할 수 있습니다. 여기서 내가 의미하는 바는 당신의 경험으로 어떻게 생각하니, 그 일을 할 것인가? 또는 마지막에 롤백하고 마감 시간까지 닫는 동안 전체 서버 코드를 수정해야합니다.

  • select/ioctlsocket을 수행하는 것과 정확히 다른 점은 무엇입니까?

  • 두 방법 모두 장단점은 무엇입니까?

많은 답장을 보내 주셔서 감사합니다. 나는 무엇에 관해 묻고 싶습니다.

+0

처리와 네트워크 코드 사이에 추상화 계층을 넣습니다. 이렇게하면 네트워크 계층을 나중에 swith 할 수 있습니다. –

답변

1

select-style 서버는 겸손한 하드웨어에서도이 소량의 동시 클라이언트를 쉽게 처리 할 수 ​​있습니다.

가독성을 가장 먼저 고려하고 가장 적합한 솔루션을 선택하십시오. 이전에 select를 사용하여 유사한 구현을 수행 한 경우 성능에 대해 걱정할 필요가 없습니다.

입출력 차단에 대한 나의 경험으로는 첫 번째 시도에서 올바른 결과를 얻는 것이 어렵지만 선택 방법은 다르지만 마일리지는 다를 수 있습니다.

1

C에서 고급 네트워킹 장비를 다루는 일에 정말로 진지한 사람이라면 boost::asio을 사용하는 것이 좋습니다. 철학을 이해하면 실제로 "지나치게 복잡한"것은 없습니다. 그리고 32 명의 플레이어를 지원하는 것은 궁극적으로 당신을 어쨌든 스레딩의 클러치로 이끌 것입니다. 그래서 오늘 시작하지 않으시겠습니까?

게임이 네트워크 입력을 기다리는 동안 연결이 끊어 졌거나 응답이없는 클라이언트를 처리하고 게임 상태가 업데이트되는 문제도 중요합니다. 어떻게 해결할 계획입니까?

+0

'죽은'연결 처리에 관해서는 일종의 'ping timeout'메커니즘을 구현하기 위해 서버가 클라이언트에게 ping 요청을 보냈습니다. 클라이언트는 PONG 패킷으로 응답해야합니다. X 초 이상 동안 연결이 끊어지고 브로드 캐스트가 전송되고 클라이언트가 삭제되었습니다. 반면 소켓에서 select()를 사용한다고해도 클라이언트 연결 상태를 알 수 없다는 의미는 아닙니다. 이는 recv()가 <0,0,> 0을 반환하는 것으로 이루어 지므로 필요한 것을 알려줍니다. – PeeS