네트웍 서버를 개발하는데.. 궁금한점이 생겼습니다.

왜 이걸로 문제가 생기는지요?
당연히 10명한테 보낼려면 10개의 패킷을 만들어서
Send 스레드에 넣어야 할텐데..

각 사용자마다 send 쓰레드가 하나씩 생기는 방식은 아닌 듯 하군요.
그렇다면 send 용 데이터 큐도 사용자 마다 있을 필요가 없는 듯 하니, send 쓰레드 용 큐 하나만 생성하고 그 큐에 데이터가 하나 들어오면 그 데이터를 접속된 모든 사용자에게 loop 를 돌며 send 한다면 원하시는 효과가 나올 듯 하군요.

하지만 한쓰레드가 loop 를 돌며 전체 사용자에게 전송하는 방식은 중간에 특정사용자의 네트웍이 느리다면 다른 사용자에게 영향을 준다는 문제점을 고려하셔야 겠네요. non block 모드로 쏘면 데이터가 잘리는 수가 생길 수도 있지요. 좋은 방법은 select 함수의 write 이벤트를 이용하는 방법이지만 프로그램이 복잡해 지더군요.

일단 저 같은 경우는 non block 로 셋팅하고 소켓 write 버퍼를 상당히 크게 잡은 후 그냥 한 쓰레드가 loop 를 돌며 송신하는 방식을 사용하고 있는데, 한 사용자당 한 쓰레드나 select 함수의 write 이벤트를 이용하는 방법으로 수정을 하고 싶은 상태 입니다.
(지금 하고 있는 방식으로도 잘 작동하고 있긴합니다.)

이 외에 좋은 구조가 있을까 궁금하네요.
일단 현재 제 지식으로는 위의 방식 이외는 모르겠네요.
고수님들 계시면 힌트라고 주고 가시면 감사하겠습니다. ^^

이건 버클리 소켓에서 write 함수를 사용할 때 non block 와 block 의 의미를 확실히 이해할 필요가 있는데요
non block 는 데이터를 client 직접 쏘고 송신 결과를 return 해주는 상태가 아닙니다.
그냥 단순 send 버퍼에 담고, 그 결과를 return 해주는거지요.
실제 데이터는 send 버퍼있는 것을 background 로 전송을 해줍니다. 이런 background 작업중에 에러가 발생했을 경우 어떻게 피드백 해주는지는 잘 모르겠습니다. (select 함수의 read, write 이외 하나 더 있는데 혹시 그게 아닐까 추측을 해봅니다.)

정말 background 로 작동하는지 못 믿으시겠다고요?
음 그렇다면 서버에서 send 버퍼를 20메가 정도 잡고 10메가 데이터를 non block 로 client 에 쏘세요. 그리고 그때까지 소요 시간을 로그로 남기세요.
역시 클라언트도 데이터를 받기 시작해서 끝까지 받았을때 까지 시작을 로그로 남겨 보세요.

제가 말씀 드린데로라면 send 버퍼가 실제 데이터 보다 크기 때문에 서버는 쏘자 마자 완료했다고 return 을 하겠지요.
하지만 클라이언트는 한참 있다가 완료하게 됩니다.
이건 서버, 클라이언트가 네트워크 속도에 따라 더욱더 시간차가 클겁니다.
혹시 해보시게 되면 테스트 결과 좀 올려주세요 ^^

오래전 글이 위로 올라왔군요.
네 TCP 는 일단 송신하면 수신측에서 정상적으로 수신이 되는 걸 보장해 줍니다. (물론 하드웨어 적인 문제로 접속이 끊겼을 때는 불가~)
그런데 이런 특징은 TCP 프로토콜의 스펙이고 이를 구현한건 커널일텐데, 커널은 소켓의 send 버퍼에 들어 있는 것에 대해서만 송신을 보장 해 주죠.
제가 말씀 드린 상황은 send 버퍼가 가득차서 send 버퍼에 데이터가 들어가지 못했을 때 문제가 생긴다는 것이었습니다. write 함수의 리턴 값을 통해 send 버퍼에 몇바이트가 입력됐는지 확인이 가능하고요.
그래서 가급적 send 버퍼에 데이터가 가득 차서 더이상 입력이 안되는 것을 막기 위해 차선으로 send 버퍼 사이즈를 늘리는거죠.

ASCII 데이터로 통신하신다면 수신측에서 데이터를 수신해서 찍어보면 디버깅이 용이 할 듯 한데 아마 binary 통신일 듯 하군요.
서버 클라이언트간 플랫폼이 다를때 binary 통신을 하시려면 구조체 팩킹 이라고 하나요?? memory alignment 에 의해 구조체 사이즈가 C의 소스상으로 같은 구조라고 실제 메모리는 다르게 구성될 수 있는데.
이 문제가 아닐까 하는 생각도 드네요.
일단 제일 먼저 송신측 사이즈와 수신측 사이즈가 같은지 확인해 보시면 좋을 듯 하군요.

send 버퍼 사이즈가 꽉 찬 상태라면 커널 버퍼의 데이타가 손실된다기 보다는 write 에서 에러를 리턴하지 않나요?
application 에서 에러처러된 데이타를 버리지만 않는다면, 데이타 손실은 없을것 같은데요..