Written

차이점을 확실하게 알아두고자 잘 정리된 내용을 가져와봤습니다. 공통점은 결국 함수를 참조하여 사용하려고 하는 것이다 정도겠네요. delegate, action, func은 대리자라고 부르는 것으로 메소드에 대한 참조 변수를 만들기 위해 존재합니다. 이중 delegate가 가장 기본적인 형태입니다. action과 func은 C# 버전이 올라가면서 편의성을 위해 프로그래머가 일일이 delegate를 정의하지 않아도되게 C# 내부적으로 정의하고 있는 대리자로 action은 인자만 존재하는 delegate, func은 인자와 결과 값이 모두 존재하는 delegate입니다. 저는 delegate를 직접 정의하여 delegate가 어떤 목적으로 존재하는지 명시하는 것을 선호할뿐 action이나 func을 사용해도 ..

비동기로 구현하기 사실상 bloking 방식의 코드가 실제로 현업에서 쓰일일은 거의 없다고 봐도 무방하다. #1은 단순히 소켓 통신이 무엇인지에 대한 이해를 위한 코드였고, 실제로는 언제 통신이 발생할지 모르기 때문에 non-blocking 계열의 함수들을 사용하여 소켓 통신을 구현해야한다. => Listener라는 클래스를 새로 만들어 코드의 분리 시작. 서버 측 소켓의 동작들을 비동기 로직을 포함하여 구현해둔 클래스 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57..

코드의 흐름 아래 코드들을 실행하면서 코드의 흐름에 대해서 궁금한 점이 생김. => 클라이언트의 Connceting을 실행하는 코드와, 서버의 Accept를 실행하는 코드는 서로 연관성이 없어보이고 따로 서로를 호출하는 코드도 존재하지 않는데 위에 보이는 이미지의 순서로 정말 알아서 동작하고 있는걸까 ? => 콘솔 출력을 통해서 확인해보니 Connect 함수를 실행하기 직전에 이미 서버 콘솔창에는 Listening이 출력되고 있었다. Connect 함수를 실행하고 난뒤 서버 콘솔창을 보니 Accept 함수 다음으로 바로 아래에 추가로 만들어둔 콘솔 출력이 출력되고 있었음. 즉 코드간에 직접적인 연관이 없어 보였지만, 위 이미지의 순서처럼 connect -> accept 순서로 잘 동작하고 있음을 확인함 ..