Server на C

если что-то дельное найдешь- стукни в жаббер.Было бы интересно этим заняться.

http://www.kodges.ru/2007/10/14/u.-r.-stivens.-unix.-razrabotka.html

Спасибо, за ссылочку. А лично ничего не скажете по топику?

Прочитай книжку. Будут вопросы по существу - обращайся.

Есть такая штука libevent. То, что доктор прописал.

Я так понял, "сервак слабенький" это комп младше 10-лет и памяти хотя бы 256 мегов есть... Работать оно будет в любой реализации. И через fork тоже, и через inetd с bash-скриптом тоже.

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

На сервере: любой HTTP сервер с прикрученной штатными средствами (apache module,CGI,fast CGI) программой генерации картинки на любимом ЯП.На клиенте: библиотека HTTP для любимого ЯП.Велосипедов не надо.

человек может хочет получить экстаз от процесса, а не от результата.

Ок. Я понял. Надо читать вышеуказанную книгу.

А так хотелось живого общения. Жаль, что небыло хоть, каких-то
советов по реализации. Согласен штатные средства подходят. Но хотел свой, дабы разобраться.

Спасибо. Но если кто, что-то дельное посоветует, буду благодарен.

Все дельное описано в вышеупомянутой книге, с туевой хучей примеров, советов, справочных данных и тд. Из менее известного могу посоветовать "Шон Уолтон. Создание сетевых приложений в среде Linux". Она тоньше раза в 2-3, но тоже ниче так (хз когда последний раз издавалась, у меня 2001).

>> Жаль, что небыло хоть, каких-то советов по реализации.

А зачем? Ну если только man socket, man accept, man listen, man pthread_create :))

Вот еще мои 5 копеек:

Все дельное описано в вышеупомянутой книге, с туевой хучей примеров, советов, справочных данных и тд. Из менее известного могу посоветовать "Йон Снейдер Эффективное программирование TCP/IP". Она тоньше раза в 2-3, но тоже ниче так (хз когда последний раз издавалась, у меня 2001).

По большому счету это сжатая компиляция Стивенса, но с упором на нюансы.

Вообще, странно, то ли я старый, то ли все дельное уже издано 10 лет назад.

ИМХО все дельное издано 20-30 лет назад.

Угу, и 30 же лет назад придумали страшные в своей убогости smtp, ftp и кучу другого устаревшего мусора.

все советы почитать книжки конечно правильные,
но товаришч хочет иметь 100 соединений одновременно,
а здесь уже без того, как это реализовано на apache, ngnixe
не обойтись,  т.е. на каждое соединение необходимо создавать свой
subprocess/thread + заморочки с памятью (request/connections pools
как у апача), стабильностью (оборванные соединения и пр.).

Поэтому товаришч выше дал правильный совет - берёшь готовый веб-сервер
(apache, ngnix) и добавляешь ему, то что необходимо. Оптимальнее всего, как apache module

btw, вопрос - всем 100 клиентам передавать один и тот же контент
или каждому своё? Если один и тот же, то можно гараздо проще
через UDP multicast.

да вы чего такое говорите? 100 коннектов - это же полные понты! И зачем ему тот апач, если он хочет "общаться" по какому то бинарному протоколу? А для такого небольшого числа коннектов спокойно можно реализовать как потоковый серверок так и с асинхронными сокетми (select).

А вообще конечно все от поставленой задачи зависит... Одно остается неизменным: 100 коннектов - понты!

++ 
из того, что стоит почитать:
http://www.kegel.com/c10k.html
http://www.microsoft.com/mspress/books/sampchap/5726.aspx (windows)

шо то я камеди в свой огород не понял) вы поясните свою позицию...

>Но хотел свой, дабы разобраться.

Ну раз так, тогда смотри в сторону FastCGI, точнее тебе нужна своя реализация FastCGI Responder.Преимущества:

1.Необходимый тебе опыт сетевого программирования. 2.Интеграция с современными серверами (nginx,lighthttpd).

Для студентов:
http://www.nestor.minsk.by/sr/2004/03/40317.html

> но товаришч хочет иметь 100 соединений одновременно,
а здесь уже без того, как это реализовано на apache, ngnixe
не обойтись, т.е. на каждое соединение необходимо создавать свой
subprocess/thread + заморочки с памятью (request/connections pools
как у апача), стабильностью (оборванные соединения и пр.).

Фигня, одним процессом с асинхронной обработкой вытянет, да ещё и кино на фоне смотреть можно будет.

вот и я о том же... сразу видно человека, который видел вживую нормальные нагрузки))

> Я Молод, неопытен. Спрашиваю ибо хочется живого общения на данную тему.

Живое общение нужно осуществлять с дэушками. Это как молодому и неопытному советую.

А тех задротов, кто скажет - делай по потоку на 1 клиента -- отрывай им яйца.

ни кто ни накого ничего не гнал.
конечно, для 100 connections обычного selecta хватит,
у него ведь ограничение 1024.
спрашивается до какой степени?, e.g. 100 simultanious 
connections per second? or per millisecond?)

человек хотел обсудить threads/processes poll/epoll
http://www.kegel.com/c10k.html - всё отлично обьясняет

select/poll/epoll/kqueue и обрабатывать соединения как конечный автомат.. мне кажется самый лучший вариант. насчет масштабирования - запустить несколько таких "обработчиков" (по штуке на процессор).