POLLHUP и POLLOUT одновременно в revents

Какую проблему решаешь?

POLLHUP считай за разновидность POLLIN. То есть если хочешь проверить неблокирующее чтение - ставишь POLLIN events и проверяешь наличие POLLIN|POLLHUP в revents. Если запись - ставишь POLLOUT в events и проверяешь POLLOUT|POLLERR в revents.

POLLHUP и POLLERR в основном возвращаются на закрытый сокет, но документация на этот счёт мутная, надеяться что в разных ОС (linux, freebsd, solaris итд) оно ведёт себя одинаково, включая установку POLLIN/POLLOUT при закрытом сокете, я бы не стал. Стратегия как описано выше вроде работает норм.

Конкретно линукс при закрытом соединении ставит POLLHUP, POLLERR, POLLOUT но не POLLIN - на тот момент когда я давно это проверял.

ставишь POLLOUT в events и проверяешь POLLOUT|POLLERR в revents

так и делаю, но приходит помимо POLLOUT еще и POLLHUP, после чего по аналогии с ffserver от ffmpeg закрываю соединение.

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

как я понимаю getsockopt мне нужно проверить всех дескрипторов, чтобы найти где ошибка!?

А можно пояснить, как именно не работает? А то из описания ничего не понятно.

Какой QoS при отправке по MQTT - 1 или 2?

Смотри в сторону настройки max_inflight_messages_set на клиенте.

Set the maximum number of messages with QoS>0 that can be part way through their network flow at once.

Defaults to 20. Increasing this value will consume more memory but can increase throughput.

2 !

гм….

«неработа» заключается в том, что ртсп сервер при вызове poll получает в revents значение 20 десятичное, что означает флаги POLLHUP и POLLOUT, что делать с этим?

Если тебя интересует только запись в сокет то POLLHUP проверять не надо. POLLHUP это чтение.

как я понимаю getsockopt мне нужно проверить всех дескрипторов, чтобы найти где ошибка!?

Какая ошибка? POLLHUP это не ошибка, это значит что с той стороны больше ничего не будут присылать в этот сокет. Повторяю, POLLHUP имеет смысл проверять только вместе с POLLIN, когда тебя интересует POLLIN.

всех дескрипторов

poll проверяет вполне конкретный дескриптор, POLLHUP относится именно к нему. При чём тут какие-то другие дескрипторы я не понял.

Может это какой-то фокус с частичным закрытием сокета? На удаленной стороне закрыли свою передачу, но вполне готовы ещё принимать данные.

Ну, то есть, на удаленной стороне вызвали shutdown(fd,SHUT_WR)

В poll передаю несколько дескрипторов минимум 2х соединений (ртсп+ртп)

Спасибо, буду думать

Да фокус, но зачем и почему и совпадает с передачей «мктт сообщения» через стороннюю либу

poll на каждый переданный дескриптор присылает свой отдельный ответ, не представляю как ты мог их перепутать.

Потому что getsockopt не сообщает мне никаких ошибок при выставлении этих 2х флагов одновременно

А и да поллин я тоже выставляю, команды ртсп же приходят, хенг-ап правда не для этого дескриптора

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

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

А ещё более важно - что если хенг-ап все таки не зря проверяется ) и убирать его не нужно, а нужно проверить что то еще

Там и не должно быть никаких ошибок, повторяю. Ещё раз, POLLHUP это разновидность POLLIN. Он, как и POLLIN, означает, что следующий вызов recv/read не будет блокироваться.

Мне кажется ты считаешь что revents это цельное числовое поле, которое надо проверять целиком. Нет, это не так. Смотри в нём только те флаги, которые тебе нужны. POLLOUT - значит в сокет можно что-то отправить. POLLIN/POLLHUP - значит можно что-то прочитать (во втором случае - прочитается 0 байт, признак EOF). POLLERR - можно посмотреть ошибку. Никак рассуждать на тему «почему POLLOUT и POLLHUP вместе» не следует, эти флаги никак друг с другом не связаны и сообщают о независимых признаках.

А покажите, пожалуйста, фрагмент кода, которому достаётся такое странное значение, и скопируйте из терминала с отладчиком всю информацию, которую в этот момент принимает и возвращает poll(): весь массив fds[nfds] и код возврата из самой poll().

куски по циклу если, то вначале

...
        if ((rc = poll(poll_table, poll_entry - poll_table, delay)) <= 0)
        {
            if (rc < 0 && ff_neterrno() != AVERROR(EAGAIN) && ff_neterrno() != AVERROR(EINTR))
            {
                fprintf(stderr, "ERROR SERVER rtsp poll: %d %s\n", errno, strerror(errno));
                break;
            }
#if DEBUG > 5
            fprintf(stdout, "POLL %d %d\n", rc, delay);
#endif /* DEBUG > 5 */
            if (!pictx->isRun) continue;
        }
...

потом цикл в цикле по соединениями, отдельный казе куда приходит

...
                case RTSPSTATE_SEND_PACKET:
                    if (ctx->poll_entry->revents & (POLLERR | POLLHUP))
                    {
                        av_freep(&ctx->packet_buffer);
                        hr = -1;
                        int err = 0;
                        socklen_t lerr = sizeof(err);
                        if (getsockopt(poll_entry->fd, SOL_SOCKET, SO_ERROR, &err, &lerr) < 0)
                            fprintf(stderr, "\nERROR SERVER rtsp getsockopt: %d %s\n", errno, strerror(errno));
                        if (err != 0)
                            fprintf(stderr, "\nERROR SERVER rtsp socket: %d %s\n", err, strerror(err));
                    }
                    else if (ctx->poll_entry->revents & POLLOUT)
                    {
                        len = send(ctx->fd, ctx->packet_buffer_ptr, ctx->packet_buffer_end - ctx->packet_buffer_ptr, 0);
                        if (len < 0)
                        {
                            if (ff_neterrno() != AVERROR(EAGAIN) && ff_neterrno() != AVERROR(EINTR))
                            {
                                av_freep(&ctx->packet_buffer);
                                hr = -1;
                            }
                            break;
                        }
                        ctx->packet_buffer_ptr += len;
                        if (ctx->packet_buffer_ptr >= ctx->packet_buffer_end)
                        {
                            av_freep(&ctx->packet_buffer);
                            ctx->state = RTSPSTATE_WAIT_REQUEST;
                        }
                    }
                    break;
...

выхлопы все чуть позже, как проверю что будет если убрать здесь проверку POLLHUP

да не исключаю что ошибка где то в другом месте и противоположная сторона на неправильные данные просто шлет хенгап

выхлоп rc (events / revents) = 1 (4 / 14) hex

POLLHUP

што ж, если исключить его обработку, то следующий send возвращает 32 Broken pipe

Ну вот, значит коннект закрывают на той стороне.

Но если что, это не повод возвращать назад интерпретацию POLLHUP как ошибки.

да, почему может приходит POLLHUP и POLLOUT одновременно в целом понятно, как писали выше наверное выполняется shutdown чтобы закрыть сразу все rtsp/rtp/rtcp соединения связанные с контекстом.

осталось понять почему та сторона это делает )

вопщим пока буду считать причиной просто потери, т.к. хоть трафик и тсп, но передается в удп тунеле от опенвпн