LINUX.ORG.RU

Server на C


0

0

Здравствуйте.

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

Пишу программу, которая будет открывать TCP порт, и ждать, соединения.
Когда приходит соединение программа должна выдать в зависимости от запроса картинку из файлика (до 300 Kb). Кол-во соединенй одновременных, максимум 100.

Сервак слабенький.

Как реализовывать? С использованием потоков или poll(epoll)?
Подскажите. Как организовать архитектуру программы?
За обЪяснения буду премного благодарен.
И за ссылки тоже спасибо.

Спасибо.

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

Dikar ★★
()
Ответ на: комментарий от dimakolev

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

mv ★★★★★
()

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

Macil ★★★★★
()

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

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

ansky ★★★★★
()

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

capricorn20
()
Ответ на: комментарий от Deleted

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

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

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

dimakolev
() автор топика
Ответ на: комментарий от dimakolev

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

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

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

cathode
()
Ответ на: комментарий от cathode

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

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

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

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

ansky ★★★★★
()
Ответ на: комментарий от Macil

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

svr4
()
Ответ на: комментарий от svr4

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

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

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

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

Valeriy_Onuchin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

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

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

fabregas
()
Ответ на: комментарий от Valeriy_Onuchin

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

fabregas
()
Ответ на: комментарий от dimakolev

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

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

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

capricorn20
()
Ответ на: комментарий от Valeriy_Onuchin

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

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

mv ★★★★★
()

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

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

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

vnovouhov
()
Ответ на: комментарий от fabregas

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

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

Valeriy_Onuchin ★★
()

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

OxiD ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.