굳이 비동기 방식을 사용하는 이유

낚시를 하러 가는데,

블로킹 방식은 낚시대 한개를 던져놓고 그 앞에 기다리면서 하염없이 뚫어져라 쳐다보고 있는 셈입니다.
낚시대에 물고기가 낚이지 않으면 일평생 그 앞에서 아무것도 안하면서 대기를 타야 할 수도 있습니다.

논블로킹 방식은 낚시대를 N개 던져놓고, 그냥 다른 일을 하러 간 셈입니다.
폰 게임을 하다가 낚시대에 입질이 와서 뭔가 신호가 오면,
그제서야 돌아가서 낚시대를 끌어올릴 수 있겠죠.

대기 방식의 차이만 미세하게 있는 정도라고 볼 수는 없고,
오히려 대기 방식에 따라서 아무것도 못하느냐 vs 다른걸 할 수 있느냐는 엄청 큰 차이가 있습니다.

Accept 정도는 와닿지 않을 수도 있지만 Send/Recv는 더 치명적입니다.
만약 클라/서버 통신에서 Send를 동기 함수로 만들다면,
실제로 클라에서 데이터를 보내고 서버에서 그 데이터를 받아서 처리하기 전까진
클라는 렌더링은 커녕 그 자리에서 멈춰서 서버 신호만 기다리는 상태가 됩니다.

논블로킹 방식의 함수를 호출하면, 당장은 다른 일을 하러 갈 수는 있지만
어찌됐건 그 함수가 성공적으로 처리가 되는지는 확인할 수는 있어야 하는데
크게 분류하면 polling 방식 (주기적으로 우리가 직접 체크하는 것)과
이벤트 방식 (처음에 걸어놓은 콜백 함수가 알아서 호출되는 것)이 존재합니다.

위의 AcceptAsync는 이벤트 방식으로 우리가 걸어놓은 콜백 event가 호출되는 쪽인데,
예외적으로 실행하자 마자 bool 값이 false로 반환되면
AcceptAsync가 지연되지 않고 바로 완료된 케이스라서
우리가 직접 콜백 event를 호출해줘야 합니다.
AcceptAsync을 호출하는 시점에 딱 맞춰 진짜로 어떤 클라가
연결 요청을 절묘하게 한 상황이라고 볼 수 있는거죠.

네 정확히 이해하셨습니다 ㅎㅎ

아하, 그럼 _listenSocket.AcceptAsync(args)가 호출된 뒤 부터 연결에 성공할 시 args의 이벤트가 작동하여 동작하는데 근데 만약 _listenSocket.AcceptAsync(args)가 호출된 순간에 양 끝단의 컴퓨터가 연결이 된다면 이벤트가 정상적으로 동작하지 않아 저희가 직접 호출해주는거죠?