일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- ip
- 프로그래머스 레벨 2
- HTTP
- 타입스크립트
- Node.js
- BFS
- Algorithm
- 크롤링
- TCP
- javascript
- Nestjs
- dp
- 레벨 1
- type challenge
- dfs
- 쉬운 문제
- 소켓
- 자바스크립트
- typescript
- 가천대
- 알고리즘
- 그래프
- 수학
- 타입 챌린지
- 문자열
- socket
- Crawling
- 백준
- 프로그래머스
- HTTP 완벽 가이드
- Today
- Total
목록서버 (3)
kakasoo
음, 해보다 안 것인데, server 하나에 client 여러 개를 연결할 수가 없다. 이게 아마, 프로세스와 스레드가 필요한 영역. 문제가 된 요소를 몇 개 발견했는데, client 2개가 있다고 하자, 하나는 A, 하나는 B라고 명명할 때 A를 서버에 연결했다. 이 상태로 연결이 잘 되고 있다고 할 때, B도 서버에 연결해보았다, 그런데 B는 전혀 동작하지 않는다. 이 서버는 동시성이 없기 때문이다. 그런데 B에서 메세지를 보낸다, 당연히 처리되지 않는다. A에서 서버와 연결을 종료한다, 그럼 B에서 동작해야 할 거 같지만, 앞서 B가 보낸 메세지는 씹혔다, 서버는 계속 B의 메세지를 기다리고 있는데 B는 이미 다음 단계로 넘어가서 메세지를 보낼 수가 없다. 동시성만이 이 문제를 해결할 수 있는 듯 ..
문제는 클라이언트가 전송을 할 때, BUF_SIZE 값보다 큰 경우다. 전송을 하게 될 때, 다 전송 받은 상태인지, 사이즈가 커서 잘렸는지 알 수가 없지 않은가, 그렇지만 괜찮다. echo_server와 client는 이미 "자신이 보낸 정보의 크기"를 알고 있는 경우에 해당하기 때문이다. echo_client는 정보를 보내고, 자신이 돌려 받을 때에도 똑같은 크기가 돌아왔는지 확인하고, 그렇지 않다면 대기하면 된다. echo를 괜히 만든 게 아니다, 우리가 만들려는 게 그저 서버와 클라이언트가 했던 말 따라 하는 프로그램을 작성하려던 게 아니고, 정보의 송수신이 문제 없이 이루어졌는지를, 매 순간 확인하기 위한 것이기 때문이다. 쓸 데 없이, 왜 했던 말 반복하는 서버-클라이언트를 만들었냐고 생각하지..
iteractive 라는 말 때문에 복잡해보일 수 있는데, 사실 이건 "반복적인" 이라는 뜻에 불과하다. 반복적이라니, 도대체 무엇이 반복적이란 말인가? 사실 매우 간단하다. 지금 우리가 소켓 프로그래밍을 해본 걸 보면, 서버와 연결되는 즉시 값을 반환하고 양측의 소켓이 종료된다. 이런 식으로 만들면 안 된다, 소켓이 몇 개인지 알고, 또 정보 요구가 몇 번이나 올 줄 알고 1회성 서버를 만드는가. 그래서, 반복문으로, accept() 함수를 여러 번 반복시킨다, 또는 무한히 반복시킨다. 어디서부터 어디까지가 반복인지 설명하기 위해서 아래의 도식을 봐주길 바란다. 1. socket() 2. bind() 3. listen() 4. accept() 5. read() / write() // 데이터를 송수신한다..