나의 브을로오그으

#1. 멀티캐스트(Multicast) 멀티캐스트 방식의 데이터 전송은 UDP를 기반으로 한다. 따라서 UDP 서버/클라이언트의 구현방식이 매우 유사하다. 차이점이 있다면 UDP에서의 데이터 전송은 하나의 목적지를 두고 이뤄지지만 멀티캐스트에서의 데이터 전송은 특정 그룹에 가입(등록)되어 있는 다수의 호스트가 된다는 점이다. 즉, 멀티캐스트 방식을 이용하면 단 한번에 데이터 전송으로 다수의 호스트에게 데이터를 전송할 수 있다. 멀티캐스트의 데이터 전송방식과 멀티캐스트 트래픽 이점 - 멀티캐스트 서버는 특정 멀티캐스트 그룹을 대상으로 데이터를 딱 한번 전송한다. - 딱! 한번 전송하더라도 그룹에 속하는 클라이언트는 모두 데이터를 수신한다. - 멀티캐스트 그룹의 수는 IP주소 범위 내에서 얼마든지 추가가 가능..

#1. send & recv 입출력 함수 윈도우 기반 예제에서는 send & recv함수를 사용했지만, 정작 마지막 인자에 0이외의 인자를 전달해본적이 없다. 즉 윈도우에서 사용한것 조차 제대로 사용하지 않은 것이다. 리눅스에서의 send & recv #include ssize_t send(int sockfd, const void* buf, size_t nbytes, int flags); -> 성공 시 전송된 바이트 수, 실패 시 -1 반환 sockfd : 데이터 전송 대상과의 연결을 의미하는 소켓의 파일 디스크립터 전달 buf : 전송할 데이터를 저장하고 있는 버퍼의 주소 값 전달. nbytes : 전송할 바이트 수 전달. flags : 데이터 전송 시 적용할 다양한 옵션 정보 전달. (위의 send ..

#1. IO 멀티플렉싱 기반의 서버 멀티프로세스 서버의 단점과 대안 이전 Chapter 11(Pipe라인 기반의 서버 모델)에서는 다중접속 서버의 구현을 위해서 클라이언트의 연결요청이 있을 때 마다 새로운 프로세스를 생성하였다. 그러나 프로세스의 생성에는 꽤 많은 대가를 지불해야 하기 떄문에 많은 양의 연산과 메모리 공간도 필요하다. 또한 프로세스마다 별도의 메모리 공간을 유지하기 때문에 상호간에 데이터를 주고받으려면 다소 복잡한 방법을 택할 수밖에 없다. (IPC는 다소 복잡한 통신방식임) "그렇다면 다수의 클라이언트에게 서비스를 제공할 수 있는 (프로세스 생성 없이) 대안이 없을까??" 있다! 바로 IO 멀티플렉싱 서버가 그것이다. 물론 이 방법이 모든 문제의 해결책은 아니다. 항상 상황에 맞는 서버..

프로세스간 통신이 가능하다라는 말은? 쉽게 말하면 두 프로세스가 데이터를 주고 받을 수 있다는 말이다. 이게 되려면 두 프로세스가 동시 접근이 가능한 메모리 공간이 있어야 한다. 프로세스간 통신의 기본 이해 "내게 빵이 하나 생기면 변수 bread에 1로 변경할게. 그리고 그 빵을 먹어버리면 변수 bread의 값을 0으로 변경할게. 그리고 너는 bread값을 보고 내 상태를 파악해" 위의 말은 가장 간단한 프로세스간 규칙이라고 볼 수 있다. 즉, 프로세스 A는 말하고, 프로세스 B는 들은 셈이다. 두 프로세스가 동시에 접근 가능한 메모리 공간만 있다면, 이 공간을 통해서 얼마든지 데이터를 주고 받을 수 있다. 그런데 챕터 10의 프로세스 생성에 대한 내용 중 프로세스 생성 시 생성한 프로세스와 별개의 독..

#1. 프로세스의 이해와 활용 9단원까지 공부한 내용을 가지고 '일렬종대'의 서비스 서버를 구현하여 만들 수 있다. 단, 연결에 걸리는 시간이 클라이언트 당 1초라면, 100번째 클라이언트는 100초가 걸린다는 함정이 있다. 두 가지 유형의 서버 "첫 번째 연결요청자의 접속대기시간은 0초, 50번째 연결요청자의 접속대기시간은 50초 그리고 100번째 연결요청자의 접속대기시간은 100초! 그러나 일단 연결만 되면 1초 안에 서비스를 완료해 드립니다." -> 물론 요청 순서가 5순위 안에 든다면 서비스 만족도는 높을 것이나... 이를 넘어선다면 클라이언트는 불만이 많을 것이다. 이럴바에 밑의 내용처럼 서비스 하는것이 낫다. "모든 연결요청자의 접속대기시간은 1초를 넘기지 않습니다. 그러나 서비스를 제공받는데..

소켓의 다양한 옵션 Protocol Level Option Name Get Set SOL_SOCKET SO_SNDBUF SO_RCVBUF SO_REUSEADDR SO_KEEPALIVE SO_BROADCAST SO_DONTROUTE SO_OOBINLINE SO_ERROR SO_TYPE O O O O O O O O O O O O O O O O X X IPPROTO_IP IP_TOS IP_TTL IP_MULTICAST_TTL IP_MULTICAST_LOOP IP_MULTICAST_IF O O O O O O O O O O IPPROTO_TCP TCP_KEEPALIVE TCP_NODELAY TCP_MAXSEG O O O O O O getsockopt & setsockopt 표 09-1에서 보이듯이 거의 모든 옵션..

#1. Domain Name System DNS(Domain Name System) : IP주소와 도메인 이름 사이에서의 변환을 수행하는 시스템 도메인 이름이란? IP주소를 대신하여 도메인 이름이라는 것을 부여한 것. DNS 서버 인터넷 브라우저 주소 창에 네이버의 IP주소인 223.130.200.107를 직접 입력하면 네이버의 메인 페이지를 볼 수 있다. (주소가 변경될 수 있기 때문에 cmd -> nslookup www.naver.com을 을 입력) 사실 IP 주소를 직접 입력하나 도메인 이름을 입력하나 똑같이 네이버 메인 페이지를 볼 수 있다. 두 접속의 결과는 같지만 방법은 다르다. 도메인 네임은 서버에 부여된 별명(가상의 주소)이기 때문에 실제주소가 아니다. 따라서 도메인 네임을 실제 주소로 변..

지금까지의 종료는 그저 close(), closesocket()함수를 호출하여 상대방의 의사와 상관 없이 일방적으로 연결을 끊었었다. #1. TCP기반의 Half-close TCP에서는 사실 연결 보다 연결 종료과정이 더 중요하다. 연결과정에서는 큰 변수가 발생하지 않지만 종료과정에서는 예상치 못한 일이 발생할 수 있기 때문이다. 일방적인 연결종료의 문제점 리눅스의 close(), 윈도우의 closesocket() 함수호출은 소켓의 완전종료를 의미한다.(송수신 불가) 양방향으로 통신하고 있는 두 호스트간에 한 호스트가 연결종료를 하면 데이터가 존재해도 수신측 호스트는 데이터 수신이 불가능하다. 이를 해결하기위해 송수신에 사용되는 스트림의 일부만 종료(half-close)하는 방법이 제공되고 있다. (ha..

#1. UDP 소켓의 특성 UDP는 신뢰할 수 없는 전송방법을 제공한다. 그러나 SEQ, ACK와 같은 작업을 하는 일이 없기 때문에 좋은 성능을 발휘한다. 신뢰성보다 성능이 중요하다면 UDP가 더 나은 선택이 될 수 있다. 그렇다면 UDP의 역할은 어디까지일까? 앞서 TCP는 신뢰성 없는 IP를 기반으로 신뢰성 있는 데이터의 송수신을 위해서 '흐름제어(Flow Control)'를 한다고 설명했는데, 이 흐름제어가 UDP에는 존재하지 않는다. TCP와 UDP의 가장 큰 차이점이 바로 이 흐름제어이며, TCP의 흐름제어를 빼면, 별로 남는게 없다. 호스트 A -> 호스트 B : 패킷 전달될 때 호스트 B로 잘 도착하도록 하는것이 IP의 역할인데, 이렇게 전달된 UDP 패킷을 호스트 B내에 존재하는 UDP ..

#1. 에코 클라이언트의 완변 구현! 4장에서 했던 내용을 참고하면, 에코 서버보다는 클라이언트에 문제가 있다.] [EchoServer] /* Window */ while((strLen = recv(hSockClnt, message, BUF_SIZE, 0)) != 0) { send(hSockClnt, message, strLen, 0); } [EchoClient] send(hSocket, message, strLen(message), 0); strLen = recv(hSocket, message, BUF_SIZE - 1, 0); message[strLen] = 0; 클라이언트 쪽은 서버쪽에서 보낸 데이터를 100% 수신하지만, 단위에 문제가 있다. 바로 에코 클라이언트는 send()함수 호출을 통해 데이..