1 Разберитесь с socket API socket(), listen(), accept(), connect() и тд.
2. Напишите два класса ListeningSocket & ConnectedSocket, можно унаследывать их от одного базового MySocket. Или ищите все это на Интернете. Если не хотите зависимосто ит платформы, то Вам нельзя пользоваться всякими WSSoket-ами. Но полная независимость у Вас врядли получится. Поэтому можете использовать интерфейсы interface или абстрактные классы, что в прицыте почти одно и тоже.
3. Создавть отдельный процесс на каждое соединение довольно накладно. Стандартное решение - использовать Thread или как их еще называит потоки. Разберитесь с этим вопросом очень хорошо.
4. Не помешает хорошое знание объектно-ориентированного программирования в C++.

Можно, конечно и на обычном С написать, только стоит ли скатываться до технологий прошлого тысячелетия? ;) Ведь С++ был разработан как более хороший, читай лучший С. Да и форум этот посвящен С++ а не С.

На С сейчас, а не двадцать лет назад, пишут в основном только встроенные системы, ну там чайником управлять или пылесосом. Да еще индивидумы, которые не в состоянии осилить разницу между классом и объектом;)

А разница между С и С++ как раз в объектно ориентированном программировании. Это то, что делает С++ лучше, чем С. Поэтому, чем лучше владеешь этими свойсвами языка, тем более эффективные, гибкие и легко поддерживаемые системы создаешь.

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

White Owl
Да, для С++ это не такая простая задача. А для С - элементарная :)

Чушь абсолютная, вы бы хотябы подумали перед тем как писать. Я просто не допускаю, что вы настолько нероффесионал, что способны сделать подобное завление подумавшию Язык С являетсяся подмножеством языка С++. Практически все, что написанно на С может быть включено в текст программы написанной на С++. Ну а если уж сильно приспичет то есть синтакс extern C. Так что опустится до уровня С всегда можно. Только вот стоит ли?

White Owl
Ню-ню... Более хороший значит? Это с каких пор мешанина технологий стала более лучшей чем одна, стройная система?


У вас, возможно, это называется мешаниной технологий, а у других это называется прогрессом. И в том, что разработчики языка решили сохранить совместимость с базовым С нет ничего плохого. Как и нет ничего плохого в самом С. Только разработка на нем высоко трудоемка - и это его основной недостаток.

А то, что С++ это лучший С сказал не я. Bjarne Stroustrup: C++ is designed to be "a better C," to support data abctruction, and to support object-orientated programming. (The C++ programming language second edition). Так что книжки надо читать, тогда и в голове мешанины не будет.

Землекоп
Не всегда. Если нужно быстродействие, то используют чистый С.


Когда нужно быстродействие такие фирмы как Микрософт и Борланд используют ассемблер. Покопайтесь в исходниках и вы найдете немало ассемблерного кода там где должен быть только С. Правда в данном случае о переносимости не говорят. Как бы вам это не нравилось, но ассемблер всегда был, есть и будет эффективнее С в работе с процессором и с памятью. И хотя можно предсказать какой ассемблерный код сгенерирует компилятор, вы не сможете его оптимизировать оперируя командами языка С. Вы так же не сможете указать компилятору какю машинную инструкцию использовать в том или ином случае. Это все привилегия ассемблера.

Ну а теперь о том как мы будем делать сервер. Как вы правильно заметили надо создать виток, только я его буду называть Thread, как в первоисточнике. Здесь вас и поджидает первая проблемка. Чтобы создать Thread в Windows вам надо вызвать комманду API CreateThread(). В UNIXe эта команда работать явно не будет. Что делает в таком случае программист С? Правильно он начинает вставлять директивы препроцессора #ifdef, #ifndef и тд. Этими директивами будет утыкан весь ваш проэкт и часто будет сложно определить в какой части кода (UNIXовской или Windowsкой) вы находитесь, особенно, если вы будете вызывать подпрограммы. А вы неприменно будете это делать даже в не очень сложном проэкте.
Какие опции есть у С++ ника? Он тоже будет пользоваться директивами препроцессора, а как же без этого. Только у него есть возможность сушественно сократить их колличество. Как? Относительно просто. Создаем абстрактный класс CThreadInterface в котором определены функции которые должны воплощать наследники, а сам класс этого делать не должен. Делается это так:
class CThreadInterface
{
public:
virtual int Execute() = 0;
virtual void Suspend() = 0;
virtual void vResume() = 0;
.
.
CThreadInterface();
virtual ~CThreadInterface();
}
=0; здесь указывает, что функция не реализуется в данном классе и ее обязанны реализовать наследники.

От этого класса наследуете два других: CThreadWindows и CThreadUnix в которых вы создаете и манипулируете Thread так как это положенно делать в UNIX и Windows соответственно. Вся прелесть в том, что специфика теперь разделена в отдельные классы, которые могут и по хорошему должны находиться в разных файлах. У вас больше нет мешанины кода. Каждая функция ассоциированна с классом, имя которого говорит вам с каким вариантом вы работаете.

Теперь как использовать данные классы. 1. Создаете указатель (можно создать и ссылку) на базовый класс:

CTheadInterface *pThread;

затем создаете объект, но уже специфического типа. Абстрактные классы нельзя создавать. Здесь вам пригодятся директивы препроцессора:

#ifdef _UNUX

pThread = new CThreadUnix;

#endif

#ifdef _Windows

PThread = new CThreadWindows;

#endif

А манирулируете вы уже указателем

pThread->Resume();
pThread->Suspend();

И тд. И это называется полиморфизмом. Таким же образом можно и нужно решать несовместимость API синхронизации Thread-ов, да и сокеты, хотя там и есть общий API, на самом деле лучше реализовать с учетом особенностий реализаций как в UNIX так и в Windows

Интегратор
Приехали... На С тоже можно писать в ООП - стиле и причём тут технологии прошлых тысячилетий не понимаю...


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


Не надо строить из всех дураков - всех кого я знаю из программистов чистого С - прекрасные специалистами, чего я бы не сказал про множество разработчиков С# не понимающих толком даже что такое виртуальная таблица ;) Это не касается всех - просто в среднем так выходит...


Не надо обобщать! По-вашему выходит, что С язык хороший, потому, что на нем пишут хорошие специалисты, а вот C# плохой, так как ихние программисты не знают что такое vTable. А как много ваших хороших специалистов знают что такое vTable? Да я понимаю, что оно им не нужно. На самом деле я сам считаю, что С++ лучше шарпа. Уж больно я не люблю, когда за меня кто-то решает, что мне можно делать а чего нельзя.


При недостаточно глубоком знании ООП и тонкостей его реализации на текущей платформе ничего хорошего не сделаешь. На С что делаешь то и получаешь - всё предельно прозрачно.

Опять ООП приплёл - и опять не к месту:). Разработать граммотную структуру приложения в ООП стиле на порядок сложнее чем в смешанном - процедурный + элементы ООП


Так с дуру можно и шею сломать. (Подставте нужное слово). А так в нашей проффессии приходится постоянно учиться новому. И отказ от этого ведет в никуда. Вы просто не сможете в очередной раз найти работу.


Согласен, хотя не такая и уж сверхсложная


А никто и не говорил, что она сверхсложная. Но синхронизацию Thred-ов знать нужно, я уже не говорю о том, что надо понимать, что такое Thread и чем она отличается от процесса.

redskin
Речь не о том, что "круче" - С или С++. Просто данная задача легко решается на обычном чистом С, знаний принципов работы сокетов здесь вполне достаточно. Углубляться в детали ООП и городить огород в виде иерархии классов именно в данной задаче ... Зачем? Т.е. может оно кому будет и полезно, но прописывать это как рецепт... Хм...

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

Во-вторых в ООП гораздо лучше реализуется повторное использование кода (или как это сейчас называется по-русски?).

В-третьих, вы можете использовать библиотеки классов поставляемые с компилятором STL (стандартная библиотека шаблонов) является частью стандарта языка С++ и должна быть в составе любого компилятора претендующего на соответствие стандарту. Плюс MFC и ATL от Микрософта и OWL от Борланда.

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

Землекоп,

Тот кто собирается вас пороть просто не понимает объектно-ориентированного программирования. Он наверное где-то его учил, но так и не понял до конца. Оно - это прежде всего абстрации и и строгая привязка поведения к состоянию state and behaviar. Каждый класс должен делать только свою работу и быть независим от других настолько насколько это возможно. В приведенном мною примере полиморфизм как раз и позволяет вам отделить разные классы ответственные за разную специфику работы. Еще более эффективным полиморфизм может быть с сочетании с использованием контейнеров list, vector, dequque, map и тд.

Землекоп,

Я, наверное, не совсем понятно объяснил. Вы декларируете абстрактный объект и манипулируете им. А создаете конкретный, зависящий от платфлормы.
Тоесть если вы хотите передать свой объект функции, то вы передаете указатель на CThreadInterface. Например:

void DoSomething( CThreadInterface *pThread){
pThread->Resume();
}

В таком случае потребители вашего объекта не знают как он реализован. Им достаточно знать что это реализованно и только. Единственное место где различие между Windows и Unix реализацией имеет значение - это когда вы создаете объект.

Инкапсуляция не даст вам того уровня абстракции, который даст полиморфизм.