일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 코딩테스트
- 멀티스레드
- 프론트엔드 스쿨
- 문자열&연산자
- N과 M(2)
- 자바스크립트
- 구현
- 코딩테스트 스터디
- 제로베이스 프론트엔드 스쿨
- Server
- c#
- Algorithm
- 메모리 배리어
- 구조체
- dfs
- 완전탐색
- 제로베이스
- React
- map
- socket
- C++
- BFS
- leetcode
- 알고리즘
- 백준
- 백트래킹
- JavaScript
- MemoryBarrier
- 서버
- 프로그래머스
- Today
- Total
목록Server (6)
Written
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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading; using System.Threading.Tasks; namespace client { //SpinLock class ..
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 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading; using System.Threading.Tasks; namespace client { //Dea..
싱글 스레드, 멀티 스레드 코드 흐름의 차이 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 58 59 using System; using System.Net; using System.Net.Sockets; using System.Text; using System.Threading.Tasks; namespace client { // 메모리 배리어 // 1) 코드 재배치 억제 // 2) 가시성 class Program { static int x = 0; static i..
캐시 => CPU와 가까운 메모리 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 static void Main(string[] args) { //캐시 철학 //Temporal Locality -> 최근에 변한 녀석이 다시 변할 확률이 높다. //Spacial Locality -> 변화가 발생한 녀석의 근처의 친구들(인접 )이 변화가 발생할 확률이 높다. int[,] arr = new int[10000, 10000]; { long now = DateTime.Now.Ticks; for (int y=0; y
비동기로 구현하기 사실상 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 순서로 잘 동작하고 있음을 확인함 ..