ServerSocket의 accept 메소드는 자원을 낭비하는가?

동아리 서버 스터디 중에 나타난 질문에 대한 내용을 정리했습니다.

1. ServerSocket의 accept 메소드

ServerSocket의 accept 메소드는 
low level socket의 listen, accept 2개 함수의 역할을 다 하는 것으로 보입니다.

(JAVA로 소켓 프로그래밍을 해본 적이 없어서, C로 작성해본 소켓 프로그래밍을 low level socket이라고 가정하고

JAVA의 ServerSocket 클래스는 그보다 위에 있는 응용 레벨이라고 가정하겠습니다.)

명세서의 설명과 StackOverflow의 답변에 따르면 그렇습니다

 

명세서의 설명 https://docs.oracle.com/javase/8/docs/api/java/net/ServerSocket.html#accept--

StackOverflow 답변 https://stackoverflow.com/questions/4553380/waiting-for-serversocket-accept-to-put-socket-into-listen-mode

 

구체적으로는 ServerSocket은 객체 생성시 socket에 대한 listen을 시작하고(socket bind는 언제하는 지는 모르겠음),

accept 메소드 호출 시 accept를 진행하는 것으로 보입니다.

 

2. accpet method는 언제 null을 리턴하는가?

그렇다면 왜 accept의 리턴 값을

왜 while문에서 계속 null인지 체크하는 걸까요?(스터디 미션 코드에서)

설마 accept는 요청이 없으면 계속 null을 리턴하는 걸까요?

interrupt/blocked IO가 아닌 polling 방식으로 작동하며 리소스를 계속 낭비하고 있을까요?

 

결과적으로는 그렇지 않습니다.

명세서의 설명과 Gemini의 답변, 그리고 low level socket의 동작방식에 따르면 그렇습니다.

명세서에서는 accept 함수가 block을 한다고 합니다.

Gemini도 첫번째 accpet 호출은 코드의 실행을 block하고,
그 이후에 추가적으로 실행되는 accpet는 바로 request queue를 확인해서 request가 없으면 null을 리턴한다고는 합니다.

(그런 상황이 언제인지는 모르겠습니다. 같은 프로세스 내에서는 block이라서 그럴 수 없는 것 같은데..

그러면 하나의 소켓이 여러 process에 bind되는 경우를 의미하는 것 같습니다.)

Gemini의 응답

결정적으로, low level socket이 interrupt 방식으로 동작합니다.

1. 프로세스에서 socket의 listen 함수를 호출하면

2. OS는 그 process를 blocking state로 이동시키고,
3. 다른 process를 실행시킵니다

4. 그러다가 Client에서 socket connection request가 오면,

5. 랜카드(NIC)가 interrupt를 발생시키고,

6. OS는 그에 대한 interrupt handler를 실행시킵니다.

7. interrupt handler는 request 요청을 queue에 옮겨두고,

8. OS는 그 process를 runnable state로 만들고,

8. OS의 scheduling에 따라서 해당 process가 실행됩니다.

 

제 전공지식과 StackExchange의 답변에 따르면 그렇습니다.

network request interrupt 과정 https://superuser.com/questions/837933/how-do-web-servers-listen-to-ip-addresses-interrupt-or-polling

 

3. 결론

서버 재밌네요