LINUX.ORG.RU
ФорумJob

написать небольшой сервер


0

1

нужен человек, способный написать(дописать) небольшой сервер( на основе epoll(), запросы к БД Postgresql ). Сервер и клиенты обмениваются данными в виде xml; сам протокол обмена - простой, текстовый. Коннекты с «нормально» проинициализированными клиентами сервер поддерживает постоянно. ( одновременно максимальное кол-во постоянно поддерживаемых коннектов примерно 500).

денежное вознаграждение оговаривается в индивидуальном порядке с потенциальным подрядчиком.

требования: - C, linux; - сетевое взаимодействие; - сишный интерфейс к postgresql.

сгодится более-менее грамотный студент

контакты: linuxjobсобакаyandexточкаru



Последнее исправление: linuxjob (всего исправлений: 3)

требования: - C

Зачем? Разработку усложнит на порядок. Даже на tcl можно поставить раком любой бд сервер.

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

как вариант, python.

на С, т.к. есть часть работы, начатая одним программистом, у которого сейчас нет времени

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

нет, взялся за другую срочную работу. данная работа горит по срокам.

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

из вики: «Tornado был создан для обеспечения высокой производительности и является одним из веб-серверов, способных выдержать проблему 10000 соединений. Следует понимать, что при сравнении производительности речь идет о т.н. „легких“ запросах». Ибо длительная обработка запроса (например, по причине взаимодействия с сервером баз данных), сводит преимущества Торнадо на нет."

мне же необходим сервер, который постоянно поддерживает порядка 500 коннектов и пишет данные в БД. Так что, Tornado и momomko явно не подходят

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

мне же необходим сервер, который постоянно поддерживает порядка 500 коннектов и пишет данные в БД.

Ты забыл глянуть, что такое momoko.

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

На Tornado + momomko такое как два пальца о асфальт пишется.

При условии, что протокол пока не оговорен и готовых клиентов еще нет.

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

Было б у меня сейчас свободное время, с удовольствием помог. Там всего кода будет от силы строк 200-300. Правда с низкоуровневыми иолупами (twisted, gevent…) не работал напрямую, поэтому в часах это займет дня три.

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

куте с тредами

10000-коннекшнов-срач

На такую толстоту поведутся разве что школьники, но они сами кютисты => срача не будет.

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

Поведутся, как миленькие. Даже не будут читать, что в теме хотят 500. Заглянут фонаты Ц, которым Qt не нужен - и фпирет.

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

я думаю мы сможем договориться

Как уже оговорился, времени особо и нет. Если сам знаешь питон, то написать не проблема.

Посмотри на gevent, в последних версиях psycopg добавили его поддержку, поэтому остается написать автомат для разбора протокола и как бы всё.

Если честно, то брать за такую работу больше 3000р мне теперь сильно совестно, так как реализация получается до предела банальная и скучная — всю обвязку, которую планировал написать уже сделали :)

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

Ты же не проверял?

Ты ж не знаешь, проверял я или нет? Прокся у нас была, туннельная, как раз на потоках Qt. Обязательно нашелся крупный спец по «проблеме 10000», который не читал ТЗ, но сказал, что «эта ваша Qt не потянет». А потом сейлзы посрались из-за денег и всем стало "немного не до того" (c)

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

Я думаю сравнение не адекватно. Компиляция по сути вычислительный процесс. А обслуживание пятиста клиентов происходит не мгновенно, а по мене прихода запросов. Конечно максимальная нагрузка (если все 500 прислали пакеты) довольно большая будет, но всё зависит он реальной нагрузки, о которой ТС не написал. Да и сеть для процессора - очень медленная штука.

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

Кажется, ты об это уже писал на лоре где-то, ибо я это уже где-то читал. Месяца два назад приблизительно.

Ну а вообще, это был вброс. Извиняюсь.

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

Ну это касается любого неблокирующего сервака. Сделай долгое действие и все клиенты будут его ждать. Возможно в вашем сервере есть точно такая же проблема. И решается она только тем, что достаточно долгие операции запускают в отдельном треде.

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

Скандалы. Интриги. Расследования...

А слабо неанонимно это же самое выложить? Все равно ведь почту засветил. Ну и хотелось бы ответ от ТС услышать на это. Так, из любопытства. Сам я уже понял, что работа эта мне не нужна.

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

я действительно тут не зарегисрирован

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

Как обычно единственный адекватный человек в треде оказался анонимом. Спасибо за пояснение, что автор топика - полный неадекват.
Пользуясь случаем, передаю привет здешним аналитикам вроде baverman, которые могут всё реализовать в 200 строк и за 3 тыщи, но почему-то сами браться не хотят. Короче, ищите дурачков дальше...

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

за 125 тысяч я возьмусь это сделать. Отписал на почту.

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

То что написал про тебе ТС «ты начитанный по статьям, не более» это похоже действительно так.)))

Обрабатываются 500 коннектов в епуле. Епул обнаруживает момент очередного запроса, затем мы(сервер) его обрабатывает. Все запросы обрабатываются последовательно, обработку нового запроса не начинаем пока не закончим с предыдущим. Если при обработке запроса придет новый запрос, то данные его будут накапливаться в буферах tcp.

Ты походу видимо даже не слышал о пуле средовых воркеров разгребающих очередь задач, которую набивает процесс «слушающий» епул.

Но правда все таки более адекватен по сравнению с baverman который замутит это за три дня и 3000 тыщ, но «с низкоуровневыми иолупами (twisted, gevent…) не работал напрямую» если настаивал на получении «внятное тз»)))

По ТС: Цена вопроса: 125000 - адекватная, срок неделя - нет. Строка «сгодится более-менее грамотный студент» и обещанная анониму цена - в комплексе настораживают.

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

Не вижу тут никаких особых сложностей.

в цикле работает некий автомат: 1) ждем соединения, 2) получили соединение - ждем данные. 3) Получили данные: а)данные от клиента соединяемся с БД, и этот коннект добавляем в epoll б) данные из базы - обрабатываем.

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

ну это конечно набросок в общих чертах. Главное чтобы библиотека которая будет для работы с постгресом умела работать асинхронно.

ну и парсер xml тоже должен это уметь, либо его самому писать ;-).

тут главное не ждать выполнения SQL ;) В таком случае БД если и будет узким местом, то это место будет в другом ТЗ.

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

ну это если я правильно понял что делается какой-то прокси сервер к базе.

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

Главное чтобы библиотека которая будет для работы с постгресом умела работать асинхронно...
...тут главное не ждать выполнения SQL

Вы мыслите почти верно. Задача по описанному здесь полу-ТЗ: написать сервер, который слушает клиентов, разбирает xml-сообщения и отсылает сгенерированные SQL-запросы в отдельный поток, в котором уже и будет реализована вся логика работы с БД. И вот тут надо сделать умное лицо и заявить, что о производительности работы с БД речи не шло. Речь шла о работе с 500 активными клиентами! А с БД пусть другие оптимизируют!

Но все это, во первых, не спортивно. Во-вторых, ТС не очень ясно, мягко говоря, понимает, что он хочет и во сколько это ему обойдется. Складываем это обстоятельство с тем, что нет полноценного ТЗ, на которое можно сослаться при появлении «хотелок» от заказчика и картина получается не очень приятная. Такой проект легко может перерасти в долгострой, а в худшем случае вообще в бессмысленно потраченное время.

P.S. У меня ведь тоже были смутные сомнения по поводу этого мутного «протокола обмена на xml». Конкретно, по поводу объема передаваемых данных и общей нагрузки на сервер. Но задать вопрос я так и не успел. К счастью, видимо, у меня вчера вырубили электричество из-за грозы на несколько часов...

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

Меня тут, всуе вспоминают. Так вот, реализация ОП задачи, элементарна. Если ТС, за неё (именно за неё) готов выложить, скажем 800$, то я с радостью возьмусь.

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

Что ж ты такой упертый то, а?

Штаны изгадит твоя джанга, супротив gevent'а и кастомного протокола. И по CPU и, особенно, по памяти.

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