네트워크 프로그래밍 : 소켓 유지 여부

저는 현재 C#의 API를 네트워크 구성 요소가있는 Java로 번역하고 있습니다.네트워크 프로그래밍 : 소켓 유지 여부

C# 버전은 입력 스트림과 출력 스트림을 유지하는 것으로 보입니다. 그리고 소켓은 해당 클래스가 사용되는 동안 열려 있습니다.

이 정보가 맞습니까?

응용 프로그램이 명령을 보내고 사용자 입력을 기반으로 이벤트를 받는다는 것을 명심하십시오. 각 "메시지"에 대해 새 소켓 스트림을 여는 것이 더 합리적입니까?

이벤트를 발생시키는 서버를 수신 대기하는 ServerSocket을 유지 관리하고 있지만 아웃 바운드 통신을위한 소켓 및 출력 스트림을 유지하는 것이 좋습니다.

저는 소켓 프로그래밍에 익숙하지 않습니다. 많은 개발자들과 마찬가지로 소켓 계층이 아닌 네트워킹을해야 할 때 응용 프로그램 계층에서 주로 작업하며, 대학에서이 작업을한지 5 년에서 6 년이되었습니다.

환호성. 나는 이것이 결정적인 대답보다 더 많은 조언을 구하는 것이라고 생각한다.

출처

2009-02-06 Omar Kooheji

오, 기다려요 ... – Svante

무엇이 보이는지 혼란 스럽습니까? –

나는이 질문이 2.5 년 된 것을 알고있다. 그러나 나는 이것을 말할 가치가 있다고 생각한다 : 연결 풀. 그게 당신이 사용하고자하는 것입니다 (또는 앱이 이미 빌드 된 앱에 액세스 할 수없는 경우 구현하십시오). –

연결을 유지하는 비용과 연결을 생성하는 비용 사이에는 상쇄 관계가 있습니다.

연결 만들기 비용과 시간 및 대역폭. 3 방향 TCP 핸드 셰이크를 수행하고 새 서버 스레드를 시작해야합니다. ...

연결 유지은 주로 메모리와 연결 비용이 듭니다. 네트워크 연결은 OS에 의해 제한되는 리소스입니다. 너무 많은 클라이언트가 연결된 경우 사용 가능한 연결이 부족할 수 있습니다. 연결된 상태와 함께 각 연결에 대해 하나의 스레드가 열려 있으므로 메모리가 필요합니다.

올바른 균형은 예상되는 사용법에 따라 다릅니다. 짧은 기간 동안 많은 고객이 연결되어 있다면 연결을 종료하는 것이 더 효율적일 수 있습니다. 오랜 시간 동안 연결하는 클라이언트가 거의 없다면 연결을 열어 두는 것이 좋습니다.

출처

2009-02-06 11:18:01 Guillaume

얼마나 자주 사용자가 명령을 입력 할 것으로 예상하는지에 따라 다릅니다. 아주 드물게 발생하면 소켓을 닫을 수 있습니다. 빈번한 경우, 소켓을 반복적으로 작성하면 값 비싼 조작이 될 수 있습니다.

이제 컴퓨터 자원 측면에서 비용이 많이 드는 이유는 드문 데이터에 대해 소켓 연결을 열어 놓은 것입니까? "아웃 바운드 통신에 대한 소켓 및 출력 스트림을 유지하는 것은 좋은 생각이 아닙니다"라고 생각하는 이유는 무엇입니까? 반면에 다른 프로세스가 동일한 파일을 사용하기를 원한다면 파일 스트림에 따라 다릅니다. 이 경우 파일 스트림을 빨리 닫는 것이 좋습니다.

아웃 바운드 연결을 만드는 다른 프로세스가 사용할 수있는 많은 TCP 연결이 부족할 가능성은 얼마나 높습니까? 또는 한 번에 많은 수의 클라이언트가 서버에 연결할 것으로 예상합니까?

출처

2009-02-06 10:57:47 Mystic

포트 번호가 부족하기 오래 전에 연결이 끊어집니다. – paxdiablo

하나의 서버 한 클라이언트 연결이 끊어지지 않도록하십시오. API는 TCP 기반 프로토콜을 둘러싼 래퍼입니다. –

제 잘못, 내 네트워크 프로그래밍도 잊어 버린 것 같아요 – Mystic

클라이언트와 서버에 하나의 소켓 만있는 경우에는 오래 동안 열어 두어야합니다 가능한 한.

출처

2009-02-06 11:18:40

응용 프로그램과 대화하는 서버가 네트워크에 가깝고 연결을 닫는 것이 현명 할 수도 있지만 네트워크가 멀리 떨어져있는 경우 소켓을 사용하도록 설정하는 것이 좋습니다. 기간.

Guillaume은 3 방향 핸드 셰이크에 대해 언급했는데 기본적으로 소켓을 여는 것은 최단 패킷 전송 시간의 최소 3 배가 걸린다는 것을 의미합니다. 이는 "핑 왕복 여행의 절반"으로 근사치가 가능하며 장거리의 경우 60-100ms에 쉽게 도달 할 수 있습니다. 각 명령에 대해 추가로 300 밀리 초의 대기가 발생하면 사용자 환경에 영향을 미칩니 까?

개인적으로, 나는 소켓을 열어 둔 채 "쉽고 간단하게"뭔가를 보낼 필요가있다 "고 말하면 상대적 비용은 적다 (하나의 파일 디스크립터, 데이터 구조를위한 약간의 메모리 사용자 공간 및 커널의 일부 추가 저장 영역).

출처

2009-02-06 11:50:12 Vatine

또한 DatagramSocket 및 DatagramPacket을 볼 수도 있습니다. 장점은 오버 헤드가 낮고 단점은 일반 소켓이 제공하는 오버 헤드입니다.

출처

2009-02-06 15:46:21 Paul

프로토콜을 변경할 수있는 옵션이 없습니다. 공급 업체 응용 프로그램에 연결하고 있습니다. –

그리고 dev가 구현할 때 신뢰성이 필요합니까? 아닙니다! – hexafraction

ActiveMQ 또는 Netty와 같은 기존 메시징 솔루션을 사용하는 것이 좋습니다. 이렇게하면 메시징에서 찾을 수있는 많은 문제가 처리됩니다.

출처

2009-02-06 21:37:20

나는 약간 늦게 갈 것이지만 나는 아무도 그것을 제안하지 않는다고 생각한다.

소켓 연결 또는 TCP 연결을 유지하고 코드 기반에서 신속하게 재사용 할 수 있다는 점에서 연결 풀링을 고려하는 것이 현명한 방법이라고 생각합니다.

실제로 Roslyn 컴파일러는 많은 곳에서이 기술을 광범위하게 사용합니다. https://github.com/dotnet/roslyn/search?l=C%23&q=pooled&type=&utf8=%E2%9C%93

출처

2018-01-10 22:22:46 kuskmen

네트워크 프로그래밍 : 소켓 유지 여부

답변

관련 문제