지정한 작업이 완료되면 클라이언트와 통신해야하는 TCP 서버를 개발 중입니다. 그래서 나는 서버에서 소켓을 열어 클라이언트가 소켓에 연결한다.
해당 연결을 사용하여 클라이언트로 데이터를 이전 할 수도 있습니다. 그건 아주 괜찮아.
하지만 연결이 끊어 지거나 그와 비슷한 것은 어떨까요?요청 처리시 영구 TCP 연결 또는 연결 설정
제 생각에는 클라이언트가 서버와 통신해야 할 때마다 서버에 연결할 생각이었습니다. 그러나 어떻게 데이터를 다시 클라이언트로 보낼 수 있습니까?
클라이언트 쪽에서도 소켓을 열어 볼까요?
편집 :
나는 WCF도 고려했다. 서버 클라이언트 계층을 구현하는 좋은 방법이 될 수 있다고 생각합니다.
당신은 어떻게 생각하십니까?
나머지 요구 사항에 따라 다릅니다. 우리가 하루에 한 번 보낼 수있는 서두르지 않는 메시지를 말하고 있다면 클라이언트가 주기적으로 서버에 연결하여 메시지가 있는지 확인하는 것이 올바른 해결책 일 수 있습니다. 우리가 더 많이 보편적으로 더 많은 것을 이야기한다면, 올바른 해결책은 클라이언트가 항상 서버에 연결을 유지하는 것일 수 있습니다. 경우에 따라 올바른 해결책은 가능하면 서버가 클라이언트에 '거꾸로'연결하는 것일 수 있습니다. '거꾸로'연결하는 경우 클라이언트에서 서버로의 영구 연결로 폴백하는 옵션이있을 수 있습니다 불가능합니다.
Push technology에 관한 기사, 특히 long polling에 관한 기사를 참조하십시오.
서버에서 클라이언트로 연결되는 런타임 POV에서이를 지원하는 네트워크 환경 (방화벽/IDS 등)이 필요합니다.
이것이 항상 사실인지 확신 할 수없는 경우이 옵션은 IMO를 배제합니다. 열린 연결을 유지하는 클라이언트에 관해서는
:
나는 이것이 좋은 옵션이라고 생각이 ... 클라이언트 구현은 어떤 연결 문제를 감지하고 자동으로 다시 연결 있는지 확인해야합니다 ...
어떤 솔루션을 구현하든 클라이언트 당 이벤트 대기열을 구현해야 할 수도 있습니다 ... 대기열에 따라 대기열이 필요할 수도 있습니다 ...
WCF는 내가 설명한 모든 방식으로 작동 할 수 있으며 여러 가지를 제공합니다 (직렬화, 선택적 세션 관리, 전송 보안 등) 순수 TCP/IP 기반 솔루션이 성능면에서 더 좋을지라도 강력하고 유지 관리가 용이 한 시스템을 구축하는 데 도움이됩니다. ...
이벤트가 있기 때문에 항상 많은 통신이 이루어집니다. 고객. – CSchulz
나는 WCF에 대해 생각해 보았다. 어떻게 생각해? – CSchulz