104%

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071#include “lnp.h”intmain (int argc, char **argv){ int i, maxi, listenfd, connfd, sockfd; int nready, client[FD_SETSIZE]; //client배열은 파일디스크립터 번호를 담는 크기 256의 배열 ssize_t n; //ssize_t == unsigned int fd_set rset, allset; //나중에 allset에서 rset으로 옮겨 담을것임./* allset과 rset??? ..

이 프로그램은 문제가 발생하지 않는 클라이언트 프로그램이므로 이 프로그램을 활용하면 웬만한 상황은 모두 커버할수 있다. 그렇기 때문에 거의 외우다 시피 알아두는것이 좋을것 같다. 먼저 for문 윗부분을 살펴보자.stdineof 라는것은 일종의 flag인데 클라이언트에서 파일을 읽다가 EOF가 발생하거나 키보드로부터 입력을 받다가 Ctrl+d가 입력 되어서 EOF가 발생하면 이 flag에 1이라는 값이 세팅 되게끔 만들어 놓은 것이다. stdineof == 0 이라는 것은 아직 클라이언트에서 EOF가 발생하지 않았다는 것이기 때문에 그 다음 줄에서FD_SET을 통해서 그 파일 디스크립터를 rset이라는 읽기 전용 파일 보따리에 추가해서 그 파일이 데이터를 읽을 준비가 됬는지를 검사하게 된다.stdineof..

시험문제 앞에서 설명했듯이 , watermark라는 옵션이 있다. 그 소켓을 사용하는 응용프로그램이 만약 100byte를 받아야만 의미가 있는 프로그램이라고 할때 커널 버퍼에 100바이트가 도착하기 전에는 read를 깨우지 않는다. 100byte가 모두 도착한 경우에만 블락에서 깨어나게끔 해서 쓸데없는 오버헤드를 줄인다. 위의 그림은 Readable,Writable,Exception 상황이 어떨때 발생하는지를 나타내고 있다. 즉, select에서 깨어나는 상황을 요약한 것이다. Readable한 경우 1. 커널 버퍼에 데이터가 도착한 경우2. 상대방으로 부터 FIN메세지가 도착한 경우3. (서버의 경우) 상대방으로 부터 연결 요청이 들어온 경우4. 오류가 발생한 경우 - 앞의 Connection Abor..

select 시스템콜이 0보다 큰 값을 리턴하면 , 0이면 타임아웃, -1이면 에러이다. Select가 양의 정수를 리턴하는 상황select시스템콜은 정상리턴할때 read보따리 write보따리 등에 들어있는 소켓이 I/O가 가능한 상태가 되면 그 가능해진 소켓의 숫자를 리턴한다. Select가 0을 리턴하는 상황select의 마지막 인자로 넣은 시간동안 소켓보따리의 소켓이 I/O준비가 됬는지 검사하다가 타임아웃 되는 순간 0을 리턴시킨다.마이크로 세컨드는 10의-6승인데 실제로는 마이크로 세컨드 기준으로 시간을 조절하기는 힘들다. select가 -1를 리턴하는 상황select에서 블락되어있는 상태에서 시그널 핸들러가 호출되면 그 블락 시스템콜이 이상한값을 리턴할 가능성이 있으므로앞에서 그 블락 시스템콜을..

요즘 응용프로그램을 짤때 서로다른 프로토콜을 사용하는 서로 다른 2개이상의 소켓을 사용해서 구현하는게 일반적이다.예를 들어 비디오 실시간 서비스를 하는 서버가 있을때 로그인 같은 경우엔 신뢰성 서비스가 필요하므로 TCP로 구현하지만 실시간 스트리밍 같은 경우에는 빠른 전송을 해야하고 굳이 재전송을 할 필요가 없으므로 UDP를 사용해서 구현한다. block I/O -> 읽어야할 데이터가 없으면 블락된 상태로 기다린다. recvfrom은 블락킹 I/O model의 한 예이다.(read와 사용법이 거의 유사)recvfrom을 호출했을때 커널로 제어가 넘어가게 되는데 이때 커널의 네트워크 패킷 버퍼에 데이터가 없으면 블락 된다. 커널은 하드웨어 네트워크 인터페이스에 데이터가 있는경우 하드웨어 인터럽트 루틴을 통..

첫번째 경우. 서버가 Crashing된 경우 이 경우 클라이언트는 서버가 Crashing 됬는지 안됬는지 바로는 알 수 가없다.그 서버에 가장 가까이 붙어있는 라우터가 그 서버가 Crashing됬다는걸 제일 빨리 알게 되고 라우팅 테이블이 인접 라우터들에게 전송되면서 결국에는 전세계 라우터들에게 전파되기 때문에 클라이언트에게 가장 가까운 라우터가 결국에는 그 ip주소로는 못간다고 알게 되기 때문에 언젠가는 알게된다. 근데, 이런 방법은 알게 되기 까지 시간이 상당히 걸린다. 따라서, 우리 프로그램의 경우에서 바로 알 수 있는 방법이 있다.Fgets한다음에 Write를 하고 나서 read에서 블락되어 있을텐데 이때 상대방으로 부터 아무 반응이 없을 것이고(FIN도 안오고 RESET도 안옴) 그렇기 때문에 ..

블락 될수있는 시스템콜이 순서대로 동작하게끔 프로그램을 짜게 되면 문제가 발생할 확률이 존재한다.위의 프로그램은 서버에 데이터를 보낼때 write를 두번에 나눠서 한다.첫번째 write에서 서버 프로세스가 이미 종료되어서 RST메세지를 서버로부터 받게 되며(그 메세지를 받기 위한 시간이 필요하므로 sleep(1)이 필요하다)두번째 write로 RST된 클라이언트 커넥트 소켓에 한번더 write를 하게 될경우 SIGPIPE 시그널이 발생한다는것을 실험하기 위한 프로그램이다. 1. hi there를 입력할시 hi there가 정상적으로 서버로부터 에코됨.2. 그 이후에(while문 한번 돌고 나서) 서버 자식 프로세스를 kill해봄.3. 클라이언트는 서버로부터 FIN메세지를 받음.4.그상태에서 Fgets를 ..

우리가 여태까지 만들었던 concurrent서버에서는 서버의 커널에 incomplete큐와 complete큐가 클라이언트의 요청정보를 담는다고 했었다.그런데, 서버프로그램의 경우에 3-way핸드쉐이킹을 끝마친 클라이언트의 요청은 complete큐에 담기게 된다.매우 바쁜 서버의 경우에 이 큐가 꽉차게 될경우가 매우 빈번히 생길수 있고 그렇게 될 경우 클라이언트 입장에서는 반응성이 매우 떨어진다. 서버와 클라이언트가 통신중이라고 가정하자.이때, 클라이언트가 SYN 서버가 SYN+ACK 다시 클라이언트가 ACK를 보냈을때 ACK를 받은 서버는 incomplete 큐에 있던 클라이언트의 연결 요청 정보를 complete큐에 옮겨 담게 된다. 그러고 나서 서버프로그램에서 complete큐에 있는 그 요청 정보를..