Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Winsock Связь двух "серверов"
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
shasik
Небольшая преамбула: решил помочь "младшему" с курсовым. Раньше с Winsock никогда не работал. Да и вообще программирование для PC мне по стольку по скольку. Но тем не менее

Проблема: есть несколько компутарафф, есть у них "логический" сервер (по выполняемым функциям). Но с точки зрения winsock - он такой же клиент как и все остальные, т.е он находится не в пасивном прслушивании, но и довольно часто сам инициирует обмен данными. Как это лучше сделать. Первое, что пришло в голову для сделать два канала - один для передачи команд, другой для данных. Сервер прослушивает канал передачи данных и активно атакует по каналу передачи команд. Клиенты же наооборот. Получилось, работает. Но выглядит все это как-то Монструально, неэстетично.

Начал изучать book'и. Почти во всех книгах приведен пример эхо-сервера, который мне нафиг не нужен. А еще мне не нравится перечисления во многих книгах: для этой цели вы можете использовать это, это и еще вот это (например, select, WSAAsyncSelect, WSASelectEvent, порты завершения и т.п.) А я так не люблю. Хотелось бы ясности: напряжение измеряем вольтметром, силу тока - амперметром, а для win32 - используем то-то. И "смотри не перепутай, Кутузов". А тут - полный ???
Как лучше поступить в ситуации, когда необходимо равноправие в сети? Можно ли, например, работать когда есть один канал и ни на одной машине не сделан bind/listen или наоборот на всех машинах сделан bind/listen?

Что посоветуете? Обязательное условие - WinAPI и никаких классов/компонентов сторонних разработчиков.
AHTOXA
Цитата(shasik @ May 2 2008, 12:39) *
Проблема: есть несколько компутарафф, есть у них "логический" сервер (по выполняемым функциям). Но с точки зрения winsock - он такой же клиент как и все остальные, т.е он находится не в пасивном прслушивании, но и довольно часто сам инициирует обмен данными.


Разница между клиентом и сервером только в процедуре установления соединения. Сервер открывает порт - клиент втыкается в этот порт. После установления соединения оба имеют совершенно одинаковые сокеты. Двунаправленные ессна.

Цитата
Первое, что пришло в голову для сделать два канала - один для передачи команд, другой для данных. Сервер прослушивает канал передачи данных и активно атакует по каналу передачи команд. Клиенты же наооборот. Получилось, работает. Но выглядит все это как-то Монструально, неэстетично.


Ну если работает, то не всё ли равно, для курсача-то? :-)

Цитата
Начал изучать book'и. Почти во всех книгах приведен пример эхо-сервера, который мне нафиг не нужен.


Почему это? Установление соединения есть? Есть. Приём данных есть? Есть. Передача данных есть? Есть! Что ещё надо? Остальное (что и когда передавать) — это ваше личное дело.

Цитата
А еще мне не нравится перечисления во многих книгах: для этой цели вы можете использовать это, это и еще вот это (например, select, WSAAsyncSelect, WSASelectEvent, порты завершения и т.п.) А я так не люблю. Хотелось бы ясности: напряжение измеряем вольтметром, силу тока - амперметром, а для win32 - используем то-то.
И "смотри не перепутай, Кутузов". А тут - полный ???


Да, это засада:-) Вот тут расписаны варианты.

Цитата
Как лучше поступить в ситуации, когда необходимо равноправие в сети? Можно ли, например, работать когда есть один канал и ни на одной машине не сделан bind/listen или наоборот на всех машинах сделан bind/listen?


У-у-у... Читать основы :-)
Вот ещё.

Цитата
Как лучше поступить в ситуации, когда необходимо равноправие в сети? Можно ли, например, работать когда есть один канал и ни на одной машине не сделан bind/listen или наоборот на всех машинах сделан bind/listen?

Что посоветуете? Обязательное условие - WinAPI и никаких классов/компонентов сторонних разработчиков.


Скачать пример, модернизировать под свои нужды и не париться:-)
shasik
Во многом разобрался уже сам. А вот за Which I/O Strategy Should I Use? - пасиба. Есть теперь формальный аргумент в пользу того или иного метода.
А вот на счет книг - все не так хорошо, как кажется. Попалась книга, по виду хорошая, идет обсуждение о том как нужно делать, а как не нужно. И не слова о том, что все это относительно UNIX - ни слова! Догодаться можно только по fork() и заголовочным файлам (которые появляются только лишь когда приводят полный листинг - в конце книги, чаще же всего только куски). Читаешь и думаешь, что select() - это панацея.
А еще мне нравиться такое (тоже встречается в большинстве книг): вот мы принимаем столько-то байт потому, что знаем сколько мы же себе послали. А если мы не будем знать сколько нам послали, то задача усложняется. Ну и еще может быть пару слов добавят и все. Испугать - испугали, а таблетку от испуга не дали.
Может быть, кто постоянно имеет дело с подобной документацией уже имеет иммунитет, но у меня - сложилось очень плохое впечатление о структурированности подобных book'ов.

ЗЫ: тему можно закрыть
zltigo
Цитата(shasik @ May 3 2008, 07:37) *
Попалась книга, по виду хорошая, идет обсуждение о том как нужно делать, а как не нужно. И не слова о том, что все это относительно UNIX - ни слова!

Интерфейс BSD Socket, он и в Африке интрефейс. Просто не пользуйтесь без надобности виндозными "аналогами" и "расширениями" и все.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.