Erlang

erlang

java

Erlang

насколько я понял, ТС спрашивает про проект...

обратите внимание на SNMP

Класика жанра:
с++
http-server
pthreads

Позволит познать глубины програмирования :)

Посля такого никакие джавы и ерланги не страшны :)

Напиши свой простенький чат-сервер

симулятор звёздной системы на MPI (или PVM). многопользовательский сетевой псевдографический арканоид

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

Устанавливаешь себе mingw и пытаеёшься написать сетевую многопоточную программу так, что бы она работала как под нормальными системами и виндовсом.

Потоки и сеть рекомендовал бы использовать не posix, а от какой-нибудь библиотеки. Например: sdl (есть сеть, потоки), wxwidgets (есть сеть, потоки), QT (есть сеть, потоки).

Как правило изучить это куда проще, да и работать будет ВЕЗДЕ. Не заканчивая linux, windows платформами. (я про сматфоны и прочую ерезь)

В голову приходят только GUI, но вероятно есть какие-нибудь популярные и хорошие решения, которые не базируются на GUI.

> В голову приходят только GUI, но вероятно есть какие-нибудь популярные и хорошие решения, которые не базируются на GUI.

(я про библиотеки, которые дают кросплатформенную сеть и потоки)

> для практитки сетевого и многопоточного программирования

ты бы еще вижуалбейсик посоветовал :)

>Потоки и сеть рекомендовал бы использовать не posix, а от какой-нибудь библиотеки. Например: sdl (есть сеть, потоки), wxwidgets (есть сеть, потоки), QT (есть сеть, потоки)

в Яве все это тоже есть)

>симулятор звёздной системы на MPI (или PVM). многопользовательский сетевой псевдографический арканоид

Это конечно хорошо, но хотелось бы сконценртироваться не на логике игры и GUI, а на сетевом взаимодействии, многопоточности, межпроцессном взаимодействии, при этом чтоб все это было действительно применимо и ощутимо в приложении. Т.е. чтоб была видна разница между однопоточной версией и многопоточной версией программы, например скорость работы. Сервера наверно лучшее под мои критерии. Собсвенно вариантов-то немного приходит в голову: сервера, клиенты, мониторинг сети. Вот если-б еще под мои задачи и БД прилепить в будующем, былоб вообще замечательно. Кроссплатформенность это конечно хорошо, но мне пока ни к чему, мне как раз POSIX-совместимое ПО нужно.

Резюмирую: какие категории программ(с примерами) лучше разрабатывать для освоения сетевого взаимодействия, многопоточности, по возможности работа с БД?

Не спорю, в Ruby тоже есть. И в Python тоже есть.

Я рискнул предположить, что человек пишет на C/C++.

Не понял наезда, использовать кроссплатформенные решения уже не круто? Обязательно нужно привязываться к одной среде, а потом думать, как это куда-нибудь портануть?

а разве для многопоточного серверного софта применяют Ruby и Python? а вот Яву часто используют (C/C++ тоже, конечно, и даже Qt начинают)

Так, читаем исходник:

Пока на ум пришла идея о многопоточном ftp клиенте,

Реч идёт о клиенте, по этому я и акцентирую на этом внимание. На тему серверного софта, обрати внимание на WEBrisc. Да и вообще сам понимаешь, если технология позволяет сделать серверную, многопоточную часть, значит это кому-то нужно.

Да и если надо сделать какую-либо программу, получив за минимальные сроки готовую программу(так называемый прототип), проще всего это сделать на Ruby или Python, а потом уже переписать на C, если не пропадёт необходимость. (не раз проверено на собственном опыте).

bruteforce ?!

>На тему серверного софта, обрати внимание на WEBrisc.

спасибо, не знал об этой штуке. но сайт не открывается(

>Я рискнул предположить, что человек пишет на C/C++.

Уточню: желаемый язык C++, причем с применением ООП, а не просто C-подобный код скомпиленный g++. Хотя увы вроде большинство софта подобного рода написано на сях, на плюсах вроде только GUI. Если есть опровержение моих предположений, дайте примеров серверов, клиентов и т.п. на плюсах с многопоточностью.

Это не наезд. Человек ИЗУЧАЕТ сетевое и многопоточное программирование. Не QT, не SDL, а именно перечисленное выше. Перечисленное Вами является ПОЛУГОТОВЫМИ решениями, которые могут дать(смогут ли) понимание как работать с конкретным АПИ, очень сильно вероятно что без понимания самого процесса.

> а на сетевом взаимодействии, многопоточности, межпроцессном взаимодействии, при этом чтоб все это было действительно применимо и ощутимо в приложении

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

я откровенно не понимаю, чего ты хочешь, и чем тебе не нравятся мои предложения. ну напиши распределённую файловую систему, например,- тут тебе взаимодействие полезет изо всех щелей

Напиши свой DBus, или RPC какое-нибудь.

>я откровенно не понимаю, чего ты хочешь, и чем тебе не нравятся мои предложения

Ты про симулятор? Нехочется заморачиваться на самом симуляторе, хочется именно на сетевом взаимодействии и многопоточности сконцентрироваться.

ну напиши распределённую файловую систему, например,- тут тебе взаимодействие полезет изо всех щелей

Типа NFS? Неплохое предложение, есть сетевое взаимодействие, но нет многопоточности.

Примеры можно, чтоб можно было заценить удачные проекты?

есть сетевое взаимодействие, но нет многопоточности.

порошок уходи

Примеры можно

http://zeroc.com/doc/Ice-3.4.1/manual/Filesys.html#49348

Нехочется заморачиваться на самом симуляторе, хочется именно на сетевом взаимодействии и многопоточности сконцентрироваться.

если у тебя проблемы с заморачиванием на что-либо, отличное от двух-трёх пунктов, то выход один - реализовать собственный планировщик и TCP/IP стек. можно в QNX, там это попроще будет чем в Linux

Это не наезд. Человек ИЗУЧАЕТ сетевое и многопоточное программирование. Не QT, не SDL, а именно перечисленное выше. Перечисленное Вами является ПОЛУГОТОВЫМИ решениями, которые могут дать(смогут ли) понимание как работать с конкретным АПИ, очень сильно вероятно что без понимания самого процесса.

Ну ладно, тогда так: рекомендую делать кроссплатформенность без исползования сторонних приблуд и части, которые различаются для разных ОС обрамлять define-ами.

Например, простой клиент у меня получилось написать вставив два дефайна, первая в области #include-ов, вторая типо этого:

#ifdef WIN32
  hints.sin_addr.s_addr = inet_addr( "127.0.0.1" );
#else
  int res = inet_pton(PF_INET, "127.0.0.1", &hints.sin_addr);
#endif

С тредами в сервере не боролся, но думаю там тоже не много дефайнить придётся. (хотя если в сетевой части почти всё одно и тоже, то стредами там явно по другому, mthread вроде используются)

Плюсы подхода: например, научился пользоватся recv функцией весто read. Так как read не работает в WIN32 окружении.

Уточню: желаемый язык C++, причем с применением ООП, а не просто C-подобный код скомпиленный g++.

Функции придётся исползовать от C. Но вот никто не мешает сделать классы:

class TCPClient <  TCP
class TCPServer <  TCP
class TCP < Newtowk 
class Network

Так, можно просто категории ПО под мои нужды озвучить: web/ftp/chat -сервера, web/ftp/chat -клиенты, снифферы ...??

Многопоточный клиент для игры MUD. ;-) Вполне может быть консольная, там практически обязательно делать многопоточность, что бы оценивать текущую ситуацию в мире и обрабатывать запросы пользователя. Так же можно навесить поток на «поддержание жизни», который будет анализировать состояние игрока и выдавать какие-либо события, если параметры куда-то сильно откланяются.

Вообщем вещь занятная.

Ещё вариант, если клиент-сервер:

Сетевой музыкальный плеер (аля mpd).

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

Клиент может вести себя как mplayer, типо указать naplay filename.ogg, клиент соединятесяс сервером, сливает туда файл filename.ogg, редактирует расписания так, что бы filename.ogg играл прямо сейчас. Многопоточность можно запихнуть в процесс отправки файла. То есть пока сливается какой-то файл, можно начать редактировать рассписание и играть его, так же парарельно получать результаты с сервера (о том что сейчас играет, сколько секунд и тп)

Тоже занятная вещь, причем аналогов я не встречал (хотя подробно с mpd не разбирался, но помоему там такого нет)