Пытаюсь написать приложение для передачи данных по сети с использованием winsock2.h.
Подразумевается работа одного и того же приложения на двух машинах сети с чередованием выполняемых функций (клиент - сервер).

Трудность как раз на этапе смены режима работы. Не могу понять, какие операции требуются для корректного перехода.

Правильно ли делать так (на примере перехода из режима сервера в режим клиента):

1. закрытие сокета, используемого для отправки данных клиентом.
2. закрытие winsock (WSACleanup())
3. инициализация winsock
4. создание сокета для приема сообщения сервером

?

А смысл перехода?
Сделай двухпоточное приложение, один поток сервера, другой поток клиента, ну и соответственно разруливай синхронизацию между ними.

Как мне кажеться ,что с такой организацией будет немало гемороя. Всё таки лучше кодить многопоточность

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

Обе машины должны выполнять роль как сервера, так и клиента.
Дело в том, что никак не могу уяснить, что есть многопоточность. Из инетовских ресурсов на этот кейворд вылазят только примеры многопоточности для с++ билдера, где все основывается на событиях, что принципиально не соответствует данной задаче.
Подскажите, плиз, где почитать на эту тему.
Или может, кто-нить сумеет объяснить основные моменты в рамках сообщения форума?

Спасибо.

И, кстати говоря, проясните, пожалуйста, понимается ли под многопоточностью использование нескольких процессов, либо же поток подразумевает какой-то своеобразный атрибут сокета?

Посмотри, например, здесь. Вообще советую с этим разобраться, т.к. в для некоторых задач это просто суперполезная штука

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

Спасибо.