1. 현재상황
현재 request와 response를 하나의 변수로 두고 하는 방식으로 바뀐 상태임.
read를 하여 read한 버퍼를 바로바로 파싱을 하고 있는 상황이고 파싱이 완료되면 cgi또는 static으로 넘어가서 처리한다.
문제점
하나의 request에 대해 처리가 다 끝나기 전에도 request를 파싱하기 때문에 response까지 처리가 다 되기 전에 request가 새롭게 파싱되어 꼬일 수 있는 문제가 있음
해결방안
이대로 변수를 하나를 두고 가는건 동일
cgi, static 모두 PIPE또는 file I/O를 해야하기 때문에 I/O처리가 끝나서 response를 만들고 sendBuffer에 넣은 뒤에 client로의 write이벤트를 켜주기 전까지는 request파싱을 하면 안된다.
따라서 클라이언트로 들어오는 read 이벤트는 sendbuffer로 response를 쓰기 전까지 이벤트를 꺼놔야한다.
2. 현재상황
cgi가 처리가 되었는지 판단은 read 한 버퍼의 사이즈와 cgi에게 write를 다해줬는지를 동시에 보고 판단하고 있다.
문제점
정확한 판단의 기준이 아니다.
해결방안
EV_EOF를 사용해야한다. pipe로 들어오는 read에서 EV_EOF가 켜진채로 들어오게 되면 일단 마지막으로 read를 시도하고 그때서야 cgi처리가 끝났음을 알고 다음 처리를 시작해야한다.
3. 현재상황
static일 경우 ifstream을 사용하여 파일을 읽고 있음.
문제점
서브젝트 위반 사항이므로 파일을 open하여 받은 fd를 가지고 read event를 걸어줘야한다.
해결방안
file을 open하여 받은 fd를 read_event에 등록하여 static file처리중이라는 state또는 flag를 클라이언트에 두고(또는 다른 처리가 될 수 있는 상황을 피하도록 하여서) 해당 클라이언트는 static file만 받을 수 있도록 해야함.(해당 이벤트만 켜져 있어야함)
4. 현재상황
cgi가 다 처리되고 client당 하나씩 할당되어있는 send버퍼로 복사가 끝나면 request와 response를 pop해 준다.
문제점
cgi처리가 어떤것이 먼저 끝날지 보장되지 않은 상황에서 front것을 pop해주기 때문에 정확히 매칭되는 request, response를 pop해주고 있지 않다. 받은 request대로 response가 갈거라는 보장도 없을 뿐더러, 처리순서가 꼬이면 여러가지로 fd나 전송했어야했을 데이터가 손실되는등 꼬이는점이 많다.
해결방안
1번(변수를 하나만 사용하는것) 으로 해결하긴 했지만 처리할 내용이 없는 상황일때만 read하여 request message를 파싱하고 파싱이 완료되면 read이벤트를 꺼두고 하나의 응답처리가 끝나서 sendBuffer로 복사가 끝나면 read이벤트를 다시 켜주는 방식으로 해야함.
꼭 read event를 꺼야만 하는가? -> 사실 이벤트를 끄지않고 read를 계속하면서 readBuffer에 쌓아둬도 되긴함. 하지만 그럼에도 불구하고 request 파싱은 일어나면 안되고 client에게로 온 EV_EOF 이벤트(client disconnect)가 들어왔을때 static또는 dynamic처리중이더라도 즉각 처리되도록 해야하기 때문에 더 복잡하다고 생각하여 read_event를 꺼두는 방식을 제안하는 것임
5. 현재상황
EV_ERROR가 client에게로 올경우 바로 disconnect해주고 있고 read가 실패했을 경우, write가 실패했을 경우등 처리도중에 바로바로 client를 close해주고 있음
문제점
한번의 이벤트 리스트(kevent로 한번에 받아온 리스트)에서 disconnect와 read, write가 섞여서 들어올 수 있기때문에 disconnect는 모아뒀다가 한번의 이벤트 처리 for문이 끝나면 disconnect해줘야한다. 그렇지 않으면 disconnect된 client나 그의 pipe또는 파일에 I/O를 시도하여 EV_ERROR플래그가 켜지게 되어 문제가 생긴다.
해결방안
client를 disconnect해야하는 상황이 오면 disconnect해야할 client라고 vector또는 set에 client를 저장해뒀다가 pipe, file_fd등을 포함해서 한꺼번에 지워줘야함. 위치는 한번의 kevent로 받아온 이벤트들의 루프를 다 돌고 난 후임.
1. 현재상황
현재 request와 response를 하나의 변수로 두고 하는 방식으로 바뀐 상태임.
read를 하여 read한 버퍼를 바로바로 파싱을 하고 있는 상황이고 파싱이 완료되면 cgi또는 static으로 넘어가서 처리한다.
문제점
하나의 request에 대해 처리가 다 끝나기 전에도 request를 파싱하기 때문에 response까지 처리가 다 되기 전에 request가 새롭게 파싱되어 꼬일 수 있는 문제가 있음
해결방안
이대로 변수를 하나를 두고 가는건 동일
cgi, static 모두 PIPE또는 file I/O를 해야하기 때문에 I/O처리가 끝나서 response를 만들고 sendBuffer에 넣은 뒤에 client로의 write이벤트를 켜주기 전까지는 request파싱을 하면 안된다.
따라서 클라이언트로 들어오는 read 이벤트는 sendbuffer로 response를 쓰기 전까지 이벤트를 꺼놔야한다.
2. 현재상황
cgi가 처리가 되었는지 판단은 read 한 버퍼의 사이즈와 cgi에게 write를 다해줬는지를 동시에 보고 판단하고 있다.
문제점
정확한 판단의 기준이 아니다.
해결방안
EV_EOF를 사용해야한다. pipe로 들어오는 read에서 EV_EOF가 켜진채로 들어오게 되면 일단 마지막으로 read를 시도하고 그때서야 cgi처리가 끝났음을 알고 다음 처리를 시작해야한다.
3. 현재상황
static일 경우 ifstream을 사용하여 파일을 읽고 있음.
문제점
서브젝트 위반 사항이므로 파일을 open하여 받은 fd를 가지고 read event를 걸어줘야한다.
해결방안
file을 open하여 받은 fd를 read_event에 등록하여 static file처리중이라는 state또는 flag를 클라이언트에 두고(또는 다른 처리가 될 수 있는 상황을 피하도록 하여서) 해당 클라이언트는 static file만 받을 수 있도록 해야함.(해당 이벤트만 켜져 있어야함)
4. 현재상황
cgi가 다 처리되고 client당 하나씩 할당되어있는 send버퍼로 복사가 끝나면 request와 response를 pop해 준다.
문제점
cgi처리가 어떤것이 먼저 끝날지 보장되지 않은 상황에서 front것을 pop해주기 때문에 정확히 매칭되는 request, response를 pop해주고 있지 않다. 받은 request대로 response가 갈거라는 보장도 없을 뿐더러, 처리순서가 꼬이면 여러가지로 fd나 전송했어야했을 데이터가 손실되는등 꼬이는점이 많다.
해결방안
1번(변수를 하나만 사용하는것) 으로 해결하긴 했지만 처리할 내용이 없는 상황일때만 read하여 request message를 파싱하고 파싱이 완료되면 read이벤트를 꺼두고 하나의 응답처리가 끝나서 sendBuffer로 복사가 끝나면 read이벤트를 다시 켜주는 방식으로 해야함.
꼭 read event를 꺼야만 하는가? -> 사실 이벤트를 끄지않고 read를 계속하면서 readBuffer에 쌓아둬도 되긴함. 하지만 그럼에도 불구하고 request 파싱은 일어나면 안되고 client에게로 온 EV_EOF 이벤트(client disconnect)가 들어왔을때 static또는 dynamic처리중이더라도 즉각 처리되도록 해야하기 때문에 더 복잡하다고 생각하여 read_event를 꺼두는 방식을 제안하는 것임
5. 현재상황
EV_ERROR가 client에게로 올경우 바로 disconnect해주고 있고 read가 실패했을 경우, write가 실패했을 경우등 처리도중에 바로바로 client를 close해주고 있음
문제점
한번의 이벤트 리스트(kevent로 한번에 받아온 리스트)에서 disconnect와 read, write가 섞여서 들어올 수 있기때문에 disconnect는 모아뒀다가 한번의 이벤트 처리 for문이 끝나면 disconnect해줘야한다. 그렇지 않으면 disconnect된 client나 그의 pipe또는 파일에 I/O를 시도하여 EV_ERROR플래그가 켜지게 되어 문제가 생긴다.
해결방안
client를 disconnect해야하는 상황이 오면 disconnect해야할 client라고 vector또는 set에 client를 저장해뒀다가 pipe, file_fd등을 포함해서 한꺼번에 지워줘야함. 위치는 한번의 kevent로 받아온 이벤트들의 루프를 다 돌고 난 후임.