구현하시고자 하는 목적에 맞게 프레임을 구축하셔야 할 것 같습니다..
예를 들어 사용자가 몇명이나 붙게 되는지.. 디비는 사용하는지..
사용한다면 얼마나 사용하는지.. 여러 기능을 서버에서 구현할건지 클라이언트에서 구현할건지.. 등등..
많은 경우를 생각해 보시면 그 경우에 맞는 구조를 찾으실 수 있으리라 생각합니다.
단순히 이건 select 아님 멀티프로세스라는건 좀... -_-a
우선 님께서 올리신 클라이언트 하나당 fork() 한번은 매우 나쁜 구조입니다.
예를 들어 동시에 클라이언트 접속이 100가 될경우 프로세스가 100개가 생성되는 구조입니다. 이정도 문제라면 안좋다는걸 아실테구...
마찬가지로 클라이언트 수대로 스래드를 만드시는것도 추천할 만한 구조는 아닌듯 싶습니다.
연결이 정말 많은 경우는 좀더 구체적이 구조를 생각해봐야겠지만 제 생각엔
select()를 쓰는 편이 좋을듯 싶습니다.
실제로 많이 쓰이고 있구요...
select()에 대한 소스자료는 아주 많이 널려있구요 특히...
W.Richard Stevens 의 UNIX Network Programming 책에 보시면
사용예까지 아주 친절하게 나와있습니다.
/***************************************************
* 가장 심플한 것이 가장 아름다운 것이다.
***************************************************/
smp 머신에서 돌아갈 게 아니라면 굳이 멀티스레드(혹은 멀티 프로세스)를 고집할 이유는 없습니다. 넌 블럭킹으로 간다면, 멀티프로세스에 비해 퍼포먼스가 뒤질 하등에 이유가 없죠. (멀티스레드/프로세스는 컨텍스트 스위칭 오버헤드 때문에 오히려 더 느립니다.)
smp 머신에서 돌아간다면 당연히 멀티스레드/프로세스로 가야합니다. 어떤 모델을 선택할 것인가는 상황에 맞춰야 하겠죠. I/O가 전체 프로세스에서 차지하는 비용이 그렇게 많지 않다면 boss-walker같은 것도 나쁘지는 않을테구요. 모델들에 대한 자세한 설명은 위에 걸린 링크에서 제가 할 수 있는 것보다 훨씬 더 자세하게 설명하고 있네요.^^
우선 님께서 올리신 클라이언트 하나당 fork() 한번은 매우 나쁜 구조입니다.
예를 들어 동시에 클라이언트 접속이 100가 될경우 프로세스가 100개가 생성되는 구조입니다. 이정도 문제라면 안좋다는걸 아실테구...
마찬가지로 클라이언트 수대로 스래드를 만드시는것도 추천할 만한 구조는 아닌듯 싶습니다.
연결이 정말 많은 경우는 좀더 구체적이 구조를 생각해봐야겠지만 제 생각엔
select()를 쓰는 편이 좋을듯 싶습니다.
실제로 많이 쓰이고 있구요...
select()에 대한 소스자료는 아주 많이 널려있구요 특히...
W.Richard Stevens 의 UNIX Network Programming 책에 보시면
사용예까지 아주 친절하게 나와있습니다.
멀티 프로세스(or 쓰레드) 구조가 매우 나쁜 구조는 아닙니다.
요즘엔 하드웨어가 좋아서 그런지 모르겠지만요.. :)
단순히 프로세스나 쓰레드가 많아진다고 나쁜 구조라고 보신다면 전 반대를.. :evil:
상황에 따라 멀티프로세스쪽에 넌블록이건 블록이건 싱글프로세스보다 더 좋은 경우도 있습니다.. :wink:
언제나 그렇지만 적절한 저울질이 필요합니다.
먼저 메신저의 성격은 한유저가 길게 접속할수도 있고..
자주 접속했다 끊을수 있는 성격이 있습니다. 이점을 기억하시면서...
다음으로 넘어가겠습니다.
가장 추천 하는 방법은..
쓰레드를 여러개 만들어서 멀티플렉싱을 (poll, select, epoll) 사용하는 방법입니다.
어떤 쓰레드는 recv만 주로하고.. 어떤 쓰레드는 처리만 주로하는 방식이겠죠.
이것은 recv쓰레드와 처리쓰레드의 갯수를 늘려서 cpu가 여러개인
컴퓨터에도 응용할수 있습니다. 하지만 프로그래밍하기 시간이 좀 걸립니다.
(이구조는 쓰레드의 장점과 멀티플렉싱의 장점 모두 있는거죠..)
클라이언트로 부터 메시지가 적을때는 해당 쓰레드를 blocking 시키므로
부하가 적을것입니다.
쓰레드나, fork()를 이용하는 방식은 메신저라면 한 유저에 하나의
쓰레드나 프로세스는 정말 죽음입니다.
처음에 짜기 쉽지만 유저가 좀 많아지면 다시 골치아퍼집니다.
쓰레드나 프로세스가 언제 사라질지 모르고 언제 다시 생길지 모르며...
만약 java를 이용한다면 이렇게 짜도 괜찮다고 들었습니다.
(전 java에 익숙하지 않으므로 확신하지는 못합니다. ^^;;;)
저도 네떡 공부이제 시작하는 초보입니다만.
제가 초보입장에서
첨엔 책에 보니 select와 poll을 이용하더군요..
이 둘을 최대한 우려먹고. 나온게
nonblock I/O구요
이 다음에 fork더군요..
거기에 thread가 더해지고.. 또 더해진게.. mutex와 semaphore입니다.
이정도 해놓구 file descriptor를 최대한 늘려서 각각의 경우에 대해
시간적으로 비교를 해놓았습니다.
nonblock select > pthread > fork 더군요..
하지만. 버뜨..
nonblock select가 좋다구 하지만. 개발성과 코드의 간단함으로
fork와 thread를 추천하였습니다.
보시면 아시겠지만. 감이 오시나요?
그런데 그 좋다는 nonblock select와 poll도
커널 자체에서의 메세지 처리에 대한 결점을 보완( file descriptor 에 대해 3 pass scan 자체에 대한 overhead때문에) 하여
FreeBSD 에서는 kqueue
Linux에서는 epoll을 이용하라는 ..
암튼.. 책에 보면 다 있습니다.
책에 나온 순서랑은 좀.. ^^;구현하시고자 하는 목적에 맞게 프
책에 나온 순서랑은 좀.. ^^;
구현하시고자 하는 목적에 맞게 프레임을 구축하셔야 할 것 같습니다..
예를 들어 사용자가 몇명이나 붙게 되는지.. 디비는 사용하는지..
사용한다면 얼마나 사용하는지.. 여러 기능을 서버에서 구현할건지 클라이언트에서 구현할건지.. 등등..
많은 경우를 생각해 보시면 그 경우에 맞는 구조를 찾으실 수 있으리라 생각합니다.
단순히 이건 select 아님 멀티프로세스라는건 좀... -_-a
http://blog.empas.com/stoneshim/?c=131
http://pynoos.x-y.net/cgi-bin/wiki/wiki.pl?Server_Frames
이런 훌륭한 분( :) )들의 글들이 많으니 더 찾아 보시고 참고하세요..
^^
처음 하시는 것이라면 단순해도 fork 로 구성하시는게 편하실것입니다.
참고하세요^-^
MSN Protocol 입니다.
http://www.hypothetic.org/docs/msn/index.php
-----------
청하가 제안하는 소프트웨어 엔지니어로써 재미있게 사는 법
http://sozu.tistory.com
select() 를 이용해 보세요
우선 님께서 올리신 클라이언트 하나당 fork() 한번은 매우 나쁜 구조입니다.
예를 들어 동시에 클라이언트 접속이 100가 될경우 프로세스가 100개가 생성되는 구조입니다. 이정도 문제라면 안좋다는걸 아실테구...
마찬가지로 클라이언트 수대로 스래드를 만드시는것도 추천할 만한 구조는 아닌듯 싶습니다.
연결이 정말 많은 경우는 좀더 구체적이 구조를 생각해봐야겠지만 제 생각엔
select()를 쓰는 편이 좋을듯 싶습니다.
실제로 많이 쓰이고 있구요...
select()에 대한 소스자료는 아주 많이 널려있구요 특히...
W.Richard Stevens 의 UNIX Network Programming 책에 보시면
사용예까지 아주 친절하게 나와있습니다.
/***************************************************
* 가장 심플한 것이 가장 아름다운 것이다.
***************************************************/
smp 머신에서 돌아갈 게 아니라면 굳이 멀티스레드(혹은 멀티 프로세스)
smp 머신에서 돌아갈 게 아니라면 굳이 멀티스레드(혹은 멀티 프로세스)를 고집할 이유는 없습니다. 넌 블럭킹으로 간다면, 멀티프로세스에 비해 퍼포먼스가 뒤질 하등에 이유가 없죠. (멀티스레드/프로세스는 컨텍스트 스위칭 오버헤드 때문에 오히려 더 느립니다.)
smp 머신에서 돌아간다면 당연히 멀티스레드/프로세스로 가야합니다. 어떤 모델을 선택할 것인가는 상황에 맞춰야 하겠죠. I/O가 전체 프로세스에서 차지하는 비용이 그렇게 많지 않다면 boss-walker같은 것도 나쁘지는 않을테구요. 모델들에 대한 자세한 설명은 위에 걸린 링크에서 제가 할 수 있는 것보다 훨씬 더 자세하게 설명하고 있네요.^^
모두 좋은 하루 되세요~!!
Re: select() 를 이용해 보세요
멀티 프로세스(or 쓰레드) 구조가 매우 나쁜 구조는 아닙니다.
요즘엔 하드웨어가 좋아서 그런지 모르겠지만요.. :)
단순히 프로세스나 쓰레드가 많아진다고 나쁜 구조라고 보신다면 전 반대를.. :evil:
상황에 따라 멀티프로세스쪽에 넌블록이건 블록이건 싱글프로세스보다 더 좋은 경우도 있습니다.. :wink:
언제나 그렇지만 적절한 저울질이 필요합니다.
제가 추천하는 방식은....
먼저 메신저의 성격은 한유저가 길게 접속할수도 있고..
자주 접속했다 끊을수 있는 성격이 있습니다. 이점을 기억하시면서...
다음으로 넘어가겠습니다.
가장 추천 하는 방법은..
쓰레드를 여러개 만들어서 멀티플렉싱을 (poll, select, epoll) 사용하는 방법입니다.
어떤 쓰레드는 recv만 주로하고.. 어떤 쓰레드는 처리만 주로하는 방식이겠죠.
이것은 recv쓰레드와 처리쓰레드의 갯수를 늘려서 cpu가 여러개인
컴퓨터에도 응용할수 있습니다. 하지만 프로그래밍하기 시간이 좀 걸립니다.
(이구조는 쓰레드의 장점과 멀티플렉싱의 장점 모두 있는거죠..)
클라이언트로 부터 메시지가 적을때는 해당 쓰레드를 blocking 시키므로
부하가 적을것입니다.
쓰레드나, fork()를 이용하는 방식은 메신저라면 한 유저에 하나의
쓰레드나 프로세스는 정말 죽음입니다.
처음에 짜기 쉽지만 유저가 좀 많아지면 다시 골치아퍼집니다.
쓰레드나 프로세스가 언제 사라질지 모르고 언제 다시 생길지 모르며...
만약 java를 이용한다면 이렇게 짜도 괜찮다고 들었습니다.
(전 java에 익숙하지 않으므로 확신하지는 못합니다. ^^;;;)
댓글 달기