Пытаюсь написать простой чат на ассемблере с использованием сокетов. И никак немогу разобраться как лучше организовать работу с несколькими клиентами и как при этом отслеживать не отключился ли какой-то из клиентов. Если можно подскажите где можно найти примеры и литературу на эту тему.
mChief Смотри в сторону организации пула потоков. Каждый поток будет обрабатывать сообщения от одного клента в отдельном для каждого окне. Почитай Руссиновича про синхронизацию в многопоточных приложениях. Ща ссылку дам... Блин..то был Рихтер. Вот сцылки http://www.ebdb.ru/Search.aspx?p=1&s=создание+эффективных+приложений&x=0&y=0
Только я не понял зачем вам потоки. Есть функция WSAAsyncSelect (если есть окна, то оно) или select (если окна стряпать неохота)
max7C4, а можна подробнее про WSAAsyncSelect? Как различать клиентов и узнавать от какого пришло сообщение? n0name, если создавать каждому клиенту свой поток, то как потом организовать между ними обмен сообщениями? з.ы. всем ответившим огромное спасибо
calidus, спасибо, как раз то что я представлял, но мне неповерят что я его написал Тем более что я хочу сам разобраться
mChief Не смотри туда! Напиши сам! Тем более то, что тебе дали не по теме) Тебе n0name хорошо сказал, а jCronuzу надо побошке дать за тупые ссылки по сокетам. Литературы нет, тебе просто надо придумать свою архитектуру сетевых взаимодействий исходя из возможнотей socket api (или того api, что ты используешь). Ну или с###ить откуданить. Чат. Хорошо. У него есть адрес и порт. Туда коннектятся пользователи. Каждому коннекту соответствует сокет. При коннекте создается поток, который знает конкретного пользователя. Все пользователи срут и создается общий пул сообщений, который отсылается каждому из клиентов с некоторым периодом. Если сокет отвалился, значит и пользователя больше нет. Если отослать в период ему не получилось, то можно чуть позже отослать еще раз и потом сделать вывод, что он отвалился. Помимо потоков клиентов, есть поток который следит за пользователями и за всеми сообщениями.
Osen вот возьми и напиши пример классный ему , а пока это тупо рассуждения , коды давай а потом уже советуй без советов абстрактно все мастера говорить. 8)
плохо опять плохо высокопроизводительные сетевые приложения используют неблокирующие сокеты и мультиплексирование I/O (select(), poll(), epoll(), ...)
rei3er Где речь шла о производительности? Вот о простоте было. И самое простое - это как раз блокирующие сокеты с recv в цикле в отдельном потоке на каждого клиента. А опрашивание по таймеру - это не то, что плохо, просто необходимости нету: recv в случае разрыва соединения просто вынесет с нулем или с ошибкой.
=) гггг уже речь до производительности зашла )))))))) Все мировые программы написаны на асинхронных сокетах. В чем производительность то блокирующих и не блокирующих ))))) ????!!!!!! Все зависит от того как напишешь функции , на асме пиши и будет тебе производительность ))))))))
Чат должен быть простенький, не больше 10 клиентов, поэтому можно было бы и поток для каждого создавать, но я решил попробовать с неблокирующими сокетами. А как быть с длинной сообщений? Сделать ее фиксированной?
calidus можно и на асме написать так что тормозить всё будет, а производительность в том что нет кучи потоков и на них не рассходуются ресурсы. Прикинь например сервер IRC на блокирующих сокетах
если операция I/O на сокете не может быть выполнена, то может быть выполнено другое действие или операция I/O на другом сокете при хорошей реализации конечного автомата производительность будет максимальной на MP системе целесообразно запустить по _одному_ потоку на каждом CPU каждый поток реализует один и тот же конечный автомат синхронизация по возможности тоже должна быть неблокирующей (например, на атомарных операциях) во всех случаях, когда время ожидания при блокировке превышает время выполнения хотя бы одного полезного действия, нужно отказываться от блокирования что касается асинхронных операций, то они будут менее эффективны засчет накладных расходов на генерацию сигнала (или любого другого способа нотификации)
rei3er дык я про что и говорю =) сравните при лучших реализациях оба варианта , и врядли вы существенно выйграете в скорости ...
