[Feat] 서버 메인로직 작성

[ykoh42]

기능이 필요한 이유 http message를 받을 수 있는 서버가 반드시 있어야함.

우선 최소한 단일 요청이라도 처리할수있고, 버퍼 사이즈가 조금 유동적일지라도 request message를 온전히 다 받을수있어야 할것같고, 추후에는 메세지 전문을 다 가져온뒤 파싱작업을 진행할지 or read로 한번 읽을때마다 처리해줄지 고려해봐야할듯 두 가지 경우 성능차이가 있을지(?) 있을것같다면 성능이 우수한 방향으로 정해야 할듯

정리하자면, 단일 request이라도 처리할 수 있는 서버 로직 작성 (소켓옵션으로 소켓 재사용할수있으면 좋을듯) select 등은 위에 될때 추후에 수정해도될것같음

[ykoh42]

우선 request parsing을 버퍼 하나에 http message가 모두 담긴다는 가정하에 작성했는데,

상황에 따라서는 http message가 너무 크면 버퍼 하나에 모두 담기지 않을 탠데,

이때 버퍼를 모두 받아 놓고 처리를 해야하는지 아니면 한번 가져온 버퍼를 처리하고 버퍼를 또 받아오고처리하고.. 이런식으로 가야할지

이것도 나중에 고려해보아야할듯

[exgs]

버퍼 하나에 모두 담기는 않는 이유가 둘 중에 어떤 경우일까? (혹은 둘다 인가?)

1. read로 읽을 버퍼의 크기가 고정적이기 때문에 담기지 않음 (char buffer[1024])
2. HTTP에서 토큰으로 전송이 된다고 들었는데, 토큰으로써 전달 할 수 있는 byte의 한계가 존재함.

현재 내 생각

1. 둘 중 어느 것이던지 다 받아놓고 처리를 하는 것이 일반적이고, 또 그래야 뒤틀리지 않지 않나??
2. 위 경우 중 1번의 경우라면, string은 문자열에 대해서 엄청 많이 담을 수 있어서, 우리가 설정하는 버퍼에 대해서는 그냥 std::string에 값을 더해주는 것으로 해결 할 수 있을 것 같음

To: @kohyounghwan

[ykoh42]

단순히 컨탠츠가 길고 버퍼가 작기 때문인데,

성능적인 이슈때문에 다받아놓고 처리하면 안된다거나 하는 문제가 추후에 생길수도 있을것같음

• 연산이 cost가 얼마나 들지도 고민해봐야하고

내부적으로 어떻게 동작할까..?

string끼리의 연결이 strjoin같이 동작한다면 매 버퍼마다 전체를 한번씩 훑을탠데 이러면 성능문제가 생기지 않을까 고민이되긴함

근데 이건 우선 나중에 성능문제가 있을때 체크해보면될듯..?

To: @exgs

[exgs]

Yes, 성능상의 문제라고하면, 그때가서 처리하면 될 듯! (zenhub의 pipelines 으로 구별한다면, icebox 이겠네)

@kohyounghwan

[ykoh42]

안에 쓰여있떤 내용은 충분히 구두로 합의된것같음