Корректное использование poll recv?

Question

[maaGames]

В прошлый раз ответы сообщества мне очень помогли, ещё раз большое всем спасибо. Прога заработала и в локальной сети и через интернет.
У меня новый вопрос.

Вот я создаю сокетное соединение, accept'ом получаю парный сокет и могу туда-сюда байтики кидать.
После этого делаю poll, ожидая данные.
После этого в цикле читаю данные функцией recv и... цикл закрывается только после закрытия парного сокета. Т.е. я не знаю, сколько объектов и с какой периодичностью приходят в сокет. Сами объекты десериализируются без проблем, но я не знаю, есть ли ещё в буфере что-то и когда прилетит следующий объект (и прилетит ли он).
Т.е. получается, что один раз вызывается accept для установки соединения, один раз взывается poll, а потом "вечно" в цикле вызывается recv и висит в этой функции, пока не придёт сообщение.
Мне кажется, что я что-то делаю не правильно, потому что не ясен смысл метода poll (или он только для передачи первых байт нужен, после установки соединения, а потом можно и без него обходиться?). Соединение может оставаться установленным от пары секунд, до нескольких суток (смотря с чем приходится работать), при этом поток будет висеть в функции recv в ожидании следующего объекта, которого может и не быть в принципе. При этом в обратном направлении за это время передаются десятки тысяч объектов (независимо от общего времени работы).
Использую блокирующий сокет, неблокирующий пока что не удалось правильно использовать.

ПСЕВДОКОД

socket  = accept;
if( poll( socket ) )
{
      while( recv(....) > 0 )
     {
            ... ;
     }
}

Answer 1

[res2001]

Вы не правильно понимаете.
При таком использовании как сейчас у вас смысла в poll особого нет, а так же нет особого смысла использовать его в блокирующем режиме сокета, т.к. в этом режиме recv (send) не вернет управление пока не сделает свою работу или пока не возникнет ошибка или пока не придет сигнал.

Если вы не стремитесь сделать некоторый вариант асинхронной работы с сетью, то poll и неблокирующие сокеты можно вообще не использовать.
В блокирующем режиме poll может быть полезен тем, что он поддерживает timeout, что может быть полезно, например для проверки флага не пора ли завершить поток или что-то в этом роде. Но и в этом случае нет гарантии, что recv (send) выполнятся без блокировки и сразу вернут управление. Поэтому timeout будет работать только в вызове poll, но не recv (send).

poll вам возвращает признак есть ли в сокете данные для чтения (или готов ли он к записи). Если да - вызываете recv (send), если нет можно поделать что-то свое, потом снова вызвать poll.

Кроме того имейте ввиду, что recv может получить не полный буфер, и send отправить не весь буфер.

Всегда анализируйте возвращаемые значения системных функций, особенно когда дело касается ввода/вывода.

Comments

[maaGames]

Я уже передаю сотни мегабайт, полёт нормальный. С сокетами работаю через Poco и напрямую с буферами не общаюсь, а использую классы-обёртки, реализующие интерфейс std::stream. Просто по Poco никаких сложных примеров не нашёл и обратно читаю по С сокетам, чтобы разобраться.
Чтение-запись выполняется в отдельном потоке, поэтому настоящий асинхронный код мне не особо нужен, т.е. я могу ждать в recv хоть сколько, если это в принципе допустимо сокетами.

Т.е. при испоьзовании блокирующих сокетов можно вообще без poll/select обойтись и сразу вызывать recv и в ней сидеть и ждать?

[res2001]

maaGames,

я могу ждать в recv хоть сколько, если это в принципе допустимо сокетами.

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

Т.е. при испоьзовании блокирующих сокетов можно вообще без poll/select обойтись и сразу вызывать recv и в ней сидеть и ждать

В любом варианте сокетов использование poll/select не обязательно. Они просто добавляют дополнительный функционал при работе с вводом/выводом. Вообще если вы работаете только с 1 сокетом в блокирующем режиме, то использование функций мультиплексоров (poll/select/epoll) не особо нужно.
Они становятся особенно актуальны, когда у вас куча соединений. Да и то, стандартный подход - каждому клиенту свой поток переводит работу с пачкой клиентов в работу с одним клиентом. Хорошо подходит для не сильно нагруженных приложений.
Но в приложения, которые должны работать с сотнями и тысячами соединений такой подход быстро вызовет перерасход ресурсов.

[maaGames]

res2001, В данный помент соединение 1 к 1, но потом будет ещё одно приложение, посылающее единичные собщения, но там соединение будет разрываться сразу после подключения и пересылки данных, поэтому будет в синхронном режиме работать и select не понадобится.
Сперва сделал чтение-запись через один порт, но сейчас сделано через два порта, в один порт сервер пишет из второго читает, а клиент наоборот. Это для простоты отладки, чтобы случайно данные не портить, потом хочу на один порт поменять.
Спасибо, кое что прояснилось!
И ещё вопрос вдогонку: при использовании неблокирующего сокета, будет ли функция accept ждать подключения или тоже сразу вернёт управление и её над в цикле крутить? И connect тоже в цикле крутить?

[res2001]

maaGames, Да, accept будет сразу возвращаться, если нет соединения. Для слушающего сокета наравне со всеми остальными можно вызывать poll. Если poll вернет, что сокет готов для чтения - есть соединение для вызова accept.
C connect несколько сложнее. Она завершается сразу, при этом процесс соединения будет продолжаться. После вызова poll/select на этом сокете, если сокет готов для чтения или для записи, то вызвав getsockopt(SO_ERROR) можно получить код ошибки, если он нулевой - то соединение установлено.

На счет разделения на 2 сокета - избыточно, не вижу как это может помешать в отладке. Но это ваши дела.

Рекомендую для сетевого программирования книгу Р.Стивенс "Unix. Разработка сетевых приложений" 3-е издание. Новую уже не купите, она 2007 года, но книга очень хороша, аналогов по глубине материала на русском я не видел. Можно купить через сайты, которые продают букинистические книги. Я свой экземпляр выуживал около года на alib.ru :-)