Помогоите с сокетами

Пытаюсь написать простой чат на ассемблере с использованием сокетов. И никак немогу разобраться как лучше организовать работу с несколькими клиентами и как при этом отслеживать не отключился ли какой-то из клиентов. Если можно подскажите где можно найти примеры и литературу на эту тему.

 

http://wasm.ru/article.php?article=socketbybeej
http://wasm.ru/srclist.php?list=5

 

Спасибо за ссылки, но там мало и я не нашел ответы на свои воросы.

 

1 клиент = 1 поток/процесс

по таймеру опрашивать клиентов.

 

mChief
Смотри в сторону организации пула потоков. Каждый поток будет обрабатывать сообщения от одного клента в отдельном для каждого окне. Почитай Руссиновича про синхронизацию в многопоточных приложениях.
Ща ссылку дам...
Блин..то был Рихтер. Вот сцылки
http://www.ebdb.ru/Search.aspx?p=1&s=создание+эффективных+приложений&x=0&y=0

 

Только я не понял зачем вам потоки. Есть функция WSAAsyncSelect (если есть окна, то оно) или select (если окна стряпать неохота)

 

max7C4, а можна подробнее про WSAAsyncSelect? Как различать клиентов и узнавать от какого пришло сообщение?
n0name, если создавать каждому клиенту свой поток, то как потом организовать между ними обмен сообщениями?
з.ы. всем ответившим огромное спасибо

 

=) Держи счастье твое ...

 

бесплатный консольный IRC бот-клиент с исходниками, но на С++

http://ircdb.org/botik.htm

 

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
дык я про что и говорю =) сравните при лучших реализациях оба варианта , и врядли вы существенно выйграете в скорости ...