셩잇님의 잡동사니

네트워크 프로그래밍 지난 시간에는 Session을 상속하는 과정과 총 4가지의 Event Handler(OnConnected, OnRecv, OnSend, OnDisconnected )를 이용하여 구현하는 시간을 가졌다. 이번 시간에는 Connector를 만드는 시간을 가진다. 👍 Connector를 만들기 전에, 왜 만들어야 할까? 클라이언트와 서버간의 통신은 당연히 필요하기 때문에 구현하는 것이 맞지만, 서버만 이용하고 있는 곳에 왜 Connecotr가 필요할까? 그 이유는 다음과 같다. 1. 현재 서버 코어 같은 경우에는 서버를 메인 용도로 만들고 있지만 커넥트, 샌드, 리시브 하는 부분은 사실 공용으로 사용하면 좋다. 2. 서버 또한 분산처리를 할 수 있기 때문에 서버끼리의 연결과 통신이 필요하다..

네트워크 프로그래밍 지난 시간에서 우리는 Session을 만들어 소켓 프로그래밍의 Receive 부분과 Send 부분을 분리하여 작업이 진행되도록 처리 했다. 오늘은 Recv 부분의 코드 로직을 서버 단과 컨텐츠 단을 나누어서 작업이 진행될 수 있도록 개선할 것이다. 이 작업은 이벤트 핸들러를 이용하는 방법과, 상속을 이용하는 방법이 있지만 루키스님은 상속이 보다 구현하기 쉽기 때문에 상속 방법을 통해 이를 구현한다. 😎 Session 클래스 내 상속 메서드 추가 먼저 우리가 무엇을 사용해야 되는지 다시 한번 생각해보아야 한다. 이를 곰곰이 생각해 나누어 보면 크게 4가지로 나뉘어 질 수 있는 것을 알 수 있다. 1. 어떤 클라이언트에서 접속을 했는지 알 수 있는 OnConnected 2. 클라이언트가 ..

네트워크 프로그래밍 지난 시간에서 우리는 새로운 클래스인 Session을 만들어 소켓 프로그래밍의 Receive 부분과 Send 부분을 분리하여 작업을 진행했다. 오늘은 이어서 Send 부분의 코드 로직을 조금 더 우아하게 사용하기 위해 개선할 것이다. Send 개선 class Session { Socket _socket; int _disconnected = 0; object _lock = new object(); Queue _sendQueue = new Queue(); List _pendinglist = new List(); SocketAsyncEventArgs _recvArgs = new SocketAsyncEventArgs(); SocketAsyncEventArgs _sendArgs = new So..

네트워크 프로그래밍 지난 시간에서 우리는 새로운 클래스인 Session을 만들어 소켓 프로그래밍의 Receive 부분을 분리하여 작업을 진행했다. 오늘은 이어서 Send 부분을 분리하여 비동기로 처리할 것이다. Send 비동기 처리 구현 Send는 Receive 와는 다르게 언제, 어디서, 얼마의 버퍼(Buffer)의 크기를 사용하여 보낼지 모르기 때문에 기존 구조와는 다르게 비동기 처리 구현이 필요하다. Send의 동작 구조는 기존의 Receive의 동작 구조와 유사하다. 하지만 Start 메서드에서 SocketAsyncEventArgs 클래스를 이용해 소켓을 생성했던 기존의 Receive와는 달리 Send에서는 이벤트만을 연결해 줄 것이다. 왜 이렇게 처리해야 할까? 기존의 Receive 동작 구조는..

네트워크 프로그래밍 우리는 이전 시간에 Accept를 비동기 함수로 변경했다. 그래서 해당 로직이 AcceptAsync 👉 RegisterAccept 👉 OnAcceptCompleted를 왔다갔다 하면서 호출이 되게끔 했다. 그러나 이 함수를 자세히 보면 '혹시 RegisterAccept 메서드 내 pending의 값이 false 처리가 되어 재귀적으로 뺑뺑이를 돌다 스택 오버플로우가 일어나지 않을까?'라는 의문이 들 수 있다. 그리고 이는 이론상으로는 가능하다. 하지만 이는 현실적으로는 일어날 수 없다. 왜냐하면 우리는 Init() 메서드 내부에서 Listen의 값을 10으로 설정해주었기 때문이다. 따라서 동시 다발적으로 pending의 값이 false로 뜨는 것은 현실적으로 일어날 수 없다. 또 현재..