Изучаю сетевое и многопоточное программирование, помимо учебных примеров надо заняться каким-нибудь несложным проектом. Пока на ум пришла идея о многопоточном ftp клиенте, типа gftp, пока без GUI. Может есть предложения лучше, чем заняться? ОС: Linux, язык программирования желательно C++ c применением ООП, но можно и С, желательно чтоб БД можно было задействовать. Что посоветуете? Какие есть готовые проекты(например на sourceforge)?
Re: С чем лучше поработать для практитки сетевого и многопот
S>Изучаю сетевое и многопоточное программирование, помимо учебных примеров надо заняться каким-нибудь несложным проектом. Пока на ум пришла идея о многопоточном ftp клиенте, типа gftp, пока без GUI. Может есть предложения лучше, чем заняться?
А что, хороший проект. Можно то же самое, только в HTTP — многопоточный веб-граббер.
Да здравствует мыло душистое и веревка пушистая.
Re: С чем лучше поработать для практитки сетевого и многопот
Здравствуйте, savgur, Вы писали:
s> Изучаю сетевое и многопоточное программирование, помимо учебных примеров надо заняться каким-нибудь несложным проектом. Пока на ум пришла идея о многопоточном ftp клиенте, типа gftp, пока без GUI. Может есть предложения лучше, чем заняться? ОС: Linux, язык программирования желательно C++ c применением ООП, но можно и С, желательно чтоб БД можно было задействовать. Что посоветуете? Какие есть готовые проекты(например на sourceforge)?
Если хочется FTP, то бывает иногда необходим такой замороченный use-case как синхронизация данных между локальной директорий и удаленной на ftp. При чем так, чтобы и размеры проверялись и даты и при обрыве связи он пытался восстановиться. В общем, проще говоря, аналог rsync только по ftp. Данный use-case встречается на хостингах, где хостер предоставляет место для бэкапа, но доступ к оному есть только по ftp. Если он будет кросс-платформенный, то еще лучше — очень часто с виндовых машинок на хостинг хотят грузить всякие прайс листы и выкручиваются через одно место, которое постоянно "дает течь".
P.S. Есть нечто похожее под названием lftp, но работает оно очень плохо на нестабильных соединениях.
Здравствуйте, savgur, Вы писали:
S>Изучаю сетевое и многопоточное программирование, помимо учебных примеров надо заняться каким-нибудь несложным проектом. Пока на ум пришла идея о многопоточном ftp клиенте, типа gftp, пока без GUI.
ftp — это такой странный протокол, что я бы несколько раз подумал, прежде чем начинать писать ещё один клиент.
Во-первых, исторически листинги каталогов давались в формате «для человека». Поэтому во всех серверах он разный. Только недавно приняли стандарт, включающий machine-readable file listing; многие действующие серверы его ещё не поддерживают. То есть, придётся писать парсеры листингов, для каждого типа сервера в отдельности, много.
В-полуторных, в этих человеческих листингах исторически было мало места под дату-время. Поэтому большинство серверов пишут месяц-день-время для файлов, изменённых за последний год, и месяц-день-год для всех остальных. В-полуторных-а), особо кривые серверы в постсоветском пространстве напишут месяц на русском языке. Поэтому парсер должен будет иметь несколько эвристик по поводу разбора дат.
Во-вторых, опять же исторически, кодировка имён файлов нигде не указывалась и не передавалась. Когда семибитного us-ascii стало не хватать, держатели серверов стали тупо передавать имена в той кодировке, в какой им было удобно — например, в СССР/России — koi8-r на юниксах, cp866 в DOS, windows-1251 на винде. В недавно принятом стандарте регламентируется исключительно UTF-8, многие серверы её ещё не поддерживают, а многие администраторы ленятся менять сервер. Поэтому придётся реализовывать выбор кодировки пользователем.
В-третьих, исходный ftp — довольно злой протокол по отношению к firewall’ам. Поэтому у него есть кроме активного ещё и пассивный режим, не такой злой. Уважающий себя клиент обязан реализовывать оба.
Ну и это ещё не говоря обо всяких экзотических серверах, (а) использующих кодировку EBCDIC; (б) использующих в качестве разделителя компонентов путей символ, отличный от '/'; (в) семантически различающих текстовые, двоичные файлы и файлы с постоянным размером записи; (г) … см. RFC 959, 5797, 3659, 2640, 2428, 2389, 2228, 1579 и, возможно, какие-нибудь ещё.
Re: С чем лучше поработать для практитки сетевого и многопот
Здравствуйте, savgur, Вы писали:
S>Изучаю сетевое и многопоточное программирование, помимо учебных примеров надо заняться каким-нибудь несложным проектом. Пока на ум пришла идея о многопоточном ftp клиенте, типа gftp, пока без GUI. Может есть предложения лучше, чем заняться? ОС: Linux, язык программирования желательно C++ c применением ООП, но можно и С, желательно чтоб БД можно было задействовать. Что посоветуете? Какие есть готовые проекты(например на sourceforge)?
Посоветую заняться серверными приложениями, а не клиентами. Ещё посоветую не бросаться сразу в живой проект, а поизобретать велосипеды. Это бесполезно для человечества в целом, но будет очень полезно для вас. Конткретнее:
1. Написать простой однопоточный однопроцессный HTTP-сервер, парсер запросов и генератор ответов сделать отдельной библиотекой. Потестить его Apache Benchmark.
2. Написать однопоточный однопроцессный сервер, основанный на select, epoll. Потестить его Apache Benchmark.
3. Написать многопроцессный сервер с моделью процесс-на-клиента. Потестить его Apache Benchmark.
4. Написать многопоточный сервер с моделью нить-на-клиента. Потестить его Apache Benchmark.
5. И так далее.
Использовать только POSIX. После каждой итерации читать чужой код, работающий по такой же схеме. По ходу читать Стивенса.
Удачи.
Настоящему индейцу завсегда везде ништяк!
Re: С чем лучше поработать для практитки сетевого и многопот
SОС: Linux, язык программирования желательно C++ c применением ООП, но можно и С, желательно чтоб БД можно было задействовать.
Для практики я бы посоветовал поставить во главу угла не взаимодействие с чем-то, а активную работу с общими для разных потоков данными. Например, какой-нибудь сервер онлайн игры. Сама игра может быть сколь угодно примитивной, главное тут — взаимодействие игроков между собой и с миром.
Re[2]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, Alu, Вы писали:
Alu>Здравствуйте, savgur, Вы писали:
Alu>4. Написать многопоточный сервер с моделью нить-на-клиента. Потестить его Apache Benchmark.
И столкнуться с проблемой C10K. Серьёзные перцы сразу пишут event based сервера ака epoll, aio, rt signal & etc.
Alu>Использовать только POSIX. После каждой итерации читать чужой код, работающий по такой же схеме. По ходу читать Стивенса.
Стивенс старьё.
Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Re[3]: С чем лучше поработать для практитки сетевого и много
Да, было бы здорово, если бы еще сторонние библиотеки не приводили к блокировке при вызове своих функций.
Увы и ах.
Здравствуйте, legogogo, Вы писали:
L>Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Re[4]: С чем лучше поработать для практитки сетевого и много
От:
Аноним
Дата:
19.08.10 14:41
Оценка:
Здравствуйте, legogogo, Вы писали:
L>Здравствуйте, legogogo, Вы писали:
L>Да и ещё, советую прочитать мою подпись, как нельзя по теме.
Если серверное приложение будет работать на SMP-системе с 16-ю 4-х ядерными процессорами, то подпись не в тему.
Re[3]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, legogogo, Вы писали:
L>И столкнуться с проблемой C10K.
Я не говорил, что эта модель венец творения. В этом и смысл написания. Пощупать самому каждую модель, оценить достоинства и недостатки. Для 10K она не пригодна, зато хороша для 10 без "К", в RTS, где важно реагировать на запросы клиентов максимально быстро.
L>Стивенс старьё.
Так и TCP/IP с различными серверными архитектурами не вчера родился И что-то вы взамен Стивенса ничего не посоветовали.
Настоящему индейцу завсегда везде ништяк!
Re[5]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, legogogo, Вы писали:
L>Здравствуйте, Alu, Вы писали:
Alu>>Здравствуйте, savgur, Вы писали:
Alu>>4. Написать многопоточный сервер с моделью нить-на-клиента. Потестить его Apache Benchmark.
L>И столкнуться с проблемой C10K. Серьёзные перцы сразу пишут event based сервера ака epoll, aio, rt signal & etc.
Alu>>Использовать только POSIX. После каждой итерации читать чужой код, работающий по такой же схеме. По ходу читать Стивенса.
L>Стивенс старьё.
Смелые слова для человека год назад познакомившегося с C.
Re[4]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, Ytz, Вы писали:
Ytz>Смелые слова для человека год назад познакомившегося с C.
Во первых с С++ познакомился года два назад, а во вторых прочитав 2/3 Стивенсона 2007 года выпуска должен взять свои слова назад. Стоящая книга, но слишком много буков, можно было тот же материал уложить страниц в 500-700, вместо 1000.
Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Re[5]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, Ytz, Вы писали:
Ytz>Смелые слова для человека год назад познакомившегося с C.
Да и асинхронного ввода/вывода в книге нет, как нет и epoll. Зато есть никому не нужные STREAMS и SCTP. И в мелочах книга расходится как минимум с флагами IPv6 ядра Linux 2.6.35 и в книге нет некоторых флагов IPv4.
Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Re[5]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, legogogo, Вы писали:
L>Здравствуйте, Ytz, Вы писали:
Ytz>>Смелые слова для человека год назад познакомившегося с C.
L>Во первых с С++ познакомился года два назад, а во вторых прочитав 2/3 Стивенсона 2007 года выпуска должен взять свои слова назад. Стоящая книга, но слишком много буков, можно было тот же материал уложить страниц в 500-700, вместо 1000.
Стивенс умер в 1999, едва ли его книга с тех пор могла измениться.
Re[6]: С чем лучше поработать для практитки сетевого и много
Здравствуйте, legogogo, Вы писали:
L>Здравствуйте, Ytz, Вы писали:
Ytz>>Смелые слова для человека год назад познакомившегося с C.
L>Да и асинхронного ввода/вывода в книге нет, как нет и epoll. Зато есть никому не нужные STREAMS и SCTP. И в мелочах книга расходится как минимум с флагами IPv6 ядра Linux 2.6.35 и в книге нет некоторых флагов IPv4.
epoll — специфический линуксовый механизм (как во FreeBSD, например, kqueue). А select/poll у Стивенса описаны.
Re[6]: С чем лучше поработать для практитки сетевого и много
И что-то вы взамен Стивенса ничего не посоветовали.
