Как заставить сокет UDP заменять старые сообщения (еще не recv () 'd) при поступлении новых?

Это будет сложно получить полностью правильно только на стороне слушателя, поскольку он может фактически пропустить последний пакет в микросхеме сетевого интерфейса, что не позволит вашей программе когда-либо увидеть его.

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

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

В качестве потоков вам понадобится мьютекс (семафор или что-то в этом роде) для защиты указателя (или ссылки) на структуру, используемую для хранения 1 полезной нагрузки UDP и всего, что вы хотите там (размер, IP-адрес отправителя, порт отправителя, отметка времени и т. д.).

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

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

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

Вы можете расширить это, используя очередь, а не просто один указатель в качестве места обмена для двух потоков. Единственный указатель - это просто очередь длиной 1, и ее очень легко обработать.

Вы также можете расширить это, попытавшись заставить поток слушателя определять наличие нескольких ожидающих пакетов и фактически помещать только последний из них в очередь для потока процессора. То, как вы это делаете, зависит от платформы, но если вы используете * nix, тогда он должен вернуть 0 для сокетов, ничего не ожидающих:

while (keep_doing_this()) {
    ssize_t len = read(udp_socket_fd, my_udp_packet->buf, my_udp_packet->buf_len); 
    // this could have been recv or recvfrom
    if (len < 0) {
        error();
    }
    int sz;
    int rc = ioctl(udp_socket_fd, FIONREAD, &sz);
    if (rc < 0) {
        error();
    }
    if (!sz) {
        // There aren't any more packets ready, so queue up the one we got
        my_udp_packet->current_len = len;

        my_udp_packet = swap_udp_packet(my_ucp_packet);
        /* swap_udp_packet is code you would have to write to implement what I talked
           about above. */

        tgkill(this_group, procesor_thread_tid, SIGUSR1);
    } else if (sz > my_udp_packet->buf_len) {
        /* You could resize the buffer for the packet payload here if it is too small.*/
    }
}

udp_packet должен быть выделен для каждого потока, а также 1 для указателя подкачки. Если вы используете очередь для обмена, тогда у вас должно быть достаточно udp_packets для каждой позиции в очереди - поскольку указатель представляет собой просто очередь длиной 1, ему нужна только 1.

Если вы используете систему POSIX, подумайте о том, чтобы не использовать сигнал реального времени для сигнализации, потому что они выстраиваются в очередь. Использование обычного сигнала позволит вам относиться к многократному сигналу так же, как к сигналу только один раз, пока сигнал не будет обработан, пока сигналы реального времени не выстраиваются в очередь. Периодическое пробуждение для проверки очереди также позволяет вам обрабатывать возможность поступления последнего сигнала сразу после того, как вы проверили, есть ли у вас новые пакеты, но перед вызовом pause для ожидания сигнала.