수정해 주세요: 문제의 가능한 핵심 사항: 클라이언트는 accept()를 한 번만 수행하고 출력 스트림을 닫지 않습니다
1. 클라이언트는 clientSocket 인스턴스를 유지하고(connect는 한 번만 호출됨) 서버는 ServerSocket 인스턴스를 유지합니다. 하나의 클라이언트 소켓만 유지하고 두 번째 입력 처리를 기대하는 것은 긴 연결을 준비하는 것 같습니다.
출력 스트림이 닫히면 출력 스트림에 해당하는 소켓도 닫힙니다. - "Crazy Java 강의 노트(제3판)" p786
2. 서버를 살펴보겠습니다. ss.accept()는 여러 클라이언트 연결을 처리하기 위한 루프에 배치되며, 각 클라이언트에 대한 읽기 작업이 있고 문제가 될 수 있는 후속 읽기 작업이 없습니다.
짧은 연결인가, 긴 연결인가? 연속적인 다중 통신의 경우 한 번의 연결로 여러 번 읽고 쓰기(긴 연결)를 사용하거나 여러 연결, 각 연결에서 한 번 읽고 쓰기(짧은 연결)를 사용할 수 있습니다. 연결) 클라이언트는 긴 연결을 원하지만 서버는 짧은 연결을 원하는 것 같습니다. 제안:
긴 연결: 클라이언트는 변경되지 않은 상태로 유지됩니다. 서버는 각 클라이언트에 대해 한 번만 ()을 허용하고 루프에서 여러 입력 통신을 처리하며 스트림을 모니터링합니다. 하지만 소켓은 닫혀 있지 않습니다.
짧은 연결: 클라이언트가 새 소켓 연결을 시작할 때마다(새 소켓 인스턴스 생성) 작업이 완료될 때마다 스트림을 닫고 소켓을 닫습니다. 서버 루프 본문은 변경되지 않고 그대로 유지되며 루프 본문에서 스트림이 닫히고 각 accept()에서 반환된 소켓 이 닫힙니다.
저는 귀하의 업종을 모르기 때문에 코드의 진정한 의도를 모릅니다. 확장할 가치가 있는 다른 사항은 다음과 같습니다.
수정해 주세요:
문제의 가능한 핵심 사항: 클라이언트는 accept()를 한 번만 수행하고 출력 스트림을 닫지 않습니다
1. 클라이언트는 clientSocket 인스턴스를 유지하고(connect는 한 번만 호출됨) 서버는 ServerSocket 인스턴스를 유지합니다. 하나의 클라이언트 소켓만 유지하고 두 번째 입력 처리를 기대하는 것은 긴 연결을 준비하는 것 같습니다.
2. 서버를 살펴보겠습니다. ss.accept()는 여러 클라이언트 연결을 처리하기 위한 루프에 배치되며, 각 클라이언트에 대한 읽기 작업이 있고 문제가 될 수 있는 후속 읽기 작업이 없습니다.
짧은 연결인가, 긴 연결인가? 연속적인 다중 통신의 경우 한 번의 연결로 여러 번 읽고 쓰기(긴 연결)를 사용하거나 여러 연결, 각 연결에서 한 번 읽고 쓰기(짧은 연결)를 사용할 수 있습니다. 연결)
클라이언트는 긴 연결을 원하지만 서버는 짧은 연결을 원하는 것 같습니다. 제안:
긴 연결: 클라이언트는 변경되지 않은 상태로 유지됩니다. 서버는 각 클라이언트에 대해 한 번만 ()을 허용하고 루프에서 여러 입력 통신을 처리하며 스트림을 모니터링합니다. 하지만 소켓은 닫혀 있지 않습니다.
짧은 연결: 클라이언트가 새 소켓 연결을 시작할 때마다(새 소켓 인스턴스 생성) 작업이 완료될 때마다 스트림을 닫고 소켓을 닫습니다. 서버 루프 본문은 변경되지 않고 그대로 유지되며 루프 본문에서 스트림이 닫히고 각 accept()에서 반환된 소켓 이 닫힙니다.
저는 귀하의 업종을 모르기 때문에 코드의 진정한 의도를 모릅니다. 확장할 가치가 있는 다른 사항은 다음과 같습니다.
다중 클라이언트 연결, 다중 연결, 세션 관리, 동시성 등.
while 루프에서 코드를 닫을 때마다 코드를 자세히 살펴볼 수 있습니다.