Хотелось бы спросить, какие режимы (блокирующий или неблокирующий) и модели работы с сокетами удобнее использовать в Windows (использовать select, события). Хотелось бы, чтобы обмен не отъедал много процессорного времени. Как мне представляется при использовании блокирующего режима нельзя корректно завершить поток ожидания соединения (так как будет висеть на accept) и кроме того, процессорное время используется нерационально. Как по вашему эффектвно ли каждое соединение обрабатывать в отдельном потоке? Хотелось бы, чтобы используемая модель работы с сокетами была довольно простая,позволяла эффектвно использовать процессорное время и функции ввода вывода не вешали поток. Мне кажется, что модель WSAEventSelect является разумным компромиссом простоты реализации и эффективности ввода вывода. Хорошо было бы услышать мнение людей, работатющих с сокетами в Windows.

Akhимхо, зависит от задачи.

Так по деталам:
1. Есть сихронный (блокирующий, не блокирующий) и асинхронный режимы.
2. Любой из режимов не будет отъедать много процессорного времени, если с умом подходить.
3. Завершить корректно поток в блокирующем режиме? Не знаю, может быть. А может быть, есть способы "сброса" сокета.
4. В блокирующем режиме при ожидании чего-то процессорное время не исползуется.
5. Если соединений предпологается не много, то может и эффективно. Иначе можно подумать о менеджере выделения процессорного времени в потоке и дергать им переодически каждый коннект. Опять же зависит от задачи.
6. п.2 И зависит от задачи.
7. Евент селект, я так понимаю, асинхронный режим. В данном случае тоже прийдется решать проблемы одновременного доступа. Так что, на любителя.

Работаю в линах, но принципы ничем не отличаются (кроме WSAStartup, WSACleanup ;) ).

А как ты работаешть с сокетами. Если я правильно понял, когда поток ждёт accept(), то он не отъедает процессорное время? А можно ли не висеть при соединении с сервером (на connect()) и какие модели кроме событий позволяеют это сделать?

Akh[quot OLEG_2005]как известно это очень хороший idle для прочессора
А можно поподробнее об этом?

Akh OLEG_2005 Akh[quot OLEG_2005]как известно это очень хороший idle для прочессора
А можно поподробнее об этом?

SELECT(2) Linux Programmer’s Manual
...

ОПИСАНИЕ
...

Иногда select вызывается с пустыми наборами (всеми тремя), n равным нулю и непустым timeout для переносимой реализации
(portable) перехода в режим ожидания (sleep) на периоды с точностью более секунды.
...


Может это справедливо только для Linux? По моему, в Windows один из трех параметров должен быть ненулевым.

Akh OLEG_2005 Akh
SELECT(2) Linux Programmer’s Manual
...

ОПИСАНИЕ
...

Иногда select вызывается с пустыми наборами (всеми тремя), n равным нулю и непустым timeout для переносимой реализации
(portable) перехода в режим ожидания (sleep) на периоды с точностью более секунды.
...


Может это справедливо только для Linux? По моему, в Windows один из трех параметров должен быть ненулевым.

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

Из MSDN описание функции select:
Any two of the parameters, readfds, writefds, or exceptfds, can be given as null. At least one must be non-null, and any non-null descriptor set must contain at least one handle to a socket.

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

Именно свой класс я и хочу написать, чтобы он эффективно работал с сокетами. Пишу я на Visual C++. Я скачал несколько классов с www.codeproject.com, но мне они не очень нравятся.

Порты ввода-вывода - довольно сложная модель. Думаю для моей задачи это очень круто.

Бесплатная версия библиотеки имеет ограничения, которые меня не устраивают. Да и хочется попробовать самому разобраться.

Просто мне хотелось бы использовать класс для доступа к TCP.

Просто мне хотелось бы использовать класс, имеющий удобный интерфейс для доступа к TCP. Например, например минимальный интерфейс с методами Start(), Stop() и перехватывать события примёма данных. Кстати интересно узнать, а кто как обрабатывает приём данных, читают по одному символу и обрабатывают событие чтения очередного символа или как-нибудь по другому?

Заранее точно трудно предсказать нагрузку. Программа является одновременно TCP-клиентом - по TCP снимается данные с систем обработки данных (теоретических их может быть несколько) и сервером, обрабатывая запросы клиентских программ. Я думаю, вряд ли сервер будет обслуживать одновременно больше 10-20 соединений.

ИзопропилСкажите, какую нагрузку вы хотите обслужить?

В любом случае. по байтам читать не следует.

А как читать принимаемые данные?

Akh OLEG_2005Просто мне хотелось бы использовать класс, имеющий удобный интерфейс для доступа к TCP. Например, например минимальный интерфейс с методами Start(), Stop() и перехватывать события примёма данных. Кстати интересно узнать, а кто как обрабатывает приём данных, читают по одному символу и обрабатывают событие чтения очередного символа или как-нибудь по другому?

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

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

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

Akh OLEG_2005Допустим есть протокол, со стратовым и стоповым байтом, если читать данные по несколько байто, то сильно усложнится разбор пакетов.
Интересно узнать, как в этот случае обычно поступают?

Как угодно:
1. Алгоритмы выделения сообщений.
2. Автомат потока данных.
...

Что вы подразумеваете под алгоритмом выделения сообщений и автоматом потоком данных?
Данные в этих случаях читаются побайтно или по несколько байт?

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