А зачем? если связь оборвется, вы просто получите ошибку в recv() при приеме. Или сигнал SIGPIPE если будете писать в неисправный сокет.

Если Вы хотите писать многопоточный сервер, и писать будете под Линукс - то Вам лучше всего разобраться с вызовом select, именно с помощью него работает большинство серверов в линукс, т.к. у многопоточной идеи много минусов, рассказывать не буду про них - лучше найдите в инете ман, про select есть даже русский ман и разберитесь с ним. Весь смысл в том, что select "берёт на обслуживание" любое (по теории) кол-во сокетов не блокируя основной цикл программы и экономя ресурсы процессора при таймаутах. У этого вызова есть ещё библиотечная обработка - pselect - это более новая ф-я. Пример приводить не буду пока - их в инете предостаточно, могу позже про выслать по почте.

Покажите хотя бы один недостаток, чтобы утверждение голословным не было. Вообще говоря, существует только два способа обработки параллельных запросов: многопоточность и ассинхронный ввод/вывод. Остальные методы должны сводиться к одному из них. Итак, select сводится к одному из этих способов, следовательно, обладает его недостатками.
Если я не прав, поправьте меня.

Нашёл статью:
Подходы к организации серверного приложения
Итак, select - это разновидность ассинхронного ввода/вывода и ему присущи недостатки этого метода (см. статью)

для Linux это лучший вариант.

Это сообщение отредактировал(а) adonin - 7.4.2006, 08:29

жабер сервер - опенсорс, под линух, очень прямо написанный, можно работу с сокетами оттуда взять. Если кому интересно - в маздае эта проблема решается порождением класса CSocket в новом потоке. Но сервера с такой "в лоб" реализованной многопоточностью на коммерческом уровне не делаются ибо макс число потоков даже на Крее будет весьма ограниченным. Техника плавающего (до опр числа потоков в каждом изних находится по 1у сокету, затем они заполняются по 2й и тд) распределения сокетов не сложна, но безопасна и эффективна и при реализации многопоточности не следует о ней забывать.

А у меня вот такой вопрос: если к серверу будут подключаться десятки тысяч клиентов, то как в таком случае организовать их работу. Не в отдельный же поток каждого     

Использовать ACE    

Это что?
 

The ADAPTIVE Communication Environment (ACE) 

Фактически - лучшая сетевая библиотека, которой пользуются многие крупнейшие компании. 
Кроссплатформенная, гибкая, защищенная + достаточно легка в изучении и использовании
 

cozzzy, А можете в 2-х словах описать как им пользоваться?
А то я чего-то недопонял... Вещица интерестная особенно прочитав кто ею пользуеться... 
Есть ли какое-то опиание сего на русском? 

Это сообщение отредактировал(а) Nuzur - 20.6.2006, 16:05

Не все-таки не смог я АСЕ осилить, буду пользоваться стандартными средствами! 

Это сообщение отредактировал(а) Nuzur - 21.6.2006, 17:02

adonin, Что-то я очень плохо понял ваш пример, тоесть до упора создаються потоки причем потом даже с "пустыми" сокетами. Всем все побарабану, подключился к нему кто-то или нет...
Можете пролить свет на происходящее? 

И код клиента который будет конектиться к такому серверу как бут выглядить? 

Это сообщение отредактировал(а) Nuzur - 22.6.2006, 09:46

А про pthread.h слышали? POSIX threads standard.
Работает отлично в nixe.

Для компиляции, используйте -lpthread флаг

Это сообщение отредактировал(а) Goryachev - 29.3.2007, 16:52

Под 'nix'ом не писал, но  почему не использовать такое явление, как порты завершения?( CreateIOCompletionPort( ) ) Это будет вполне логично, в случае если сервер расчитан на большое кол-во пользователей.

Создавать потоки на каждый сокет имеет смысл лишь в том случае, если ожидается сравнительно мелое количество пользователей. На мой взгляд около 20. Однако от многопотоковости отказываться не стоит. Просто распределить обработку данных на несколько потоков. Особенно продуктивно в многопроцессорных машинах.

Могу вывесить свой курсач по Linux - это HTTP - сервер. Там несколько вариантов работы сервера и через fork, и через потоки, и через пул потоков.

Если надо пиши!