Tcp socket всегда блокирует чтение

Question

У меня есть клиентский TCP-сокет, который записывает несколько байтов каждые пять секунд, сервер отображает эти байты обратно.

Connect () и write () отлично работает, и у меня есть обратный вызов на уровне IP, который уведомляет меня о эхо-запросе сервера.Это происходит надежно между отправками.

Но у меня возникают проблемы с чтением эха из сокета.

Я пытался использовать select () , чтобы уведомить меня о входящем эхо,Странно, но мой обратный вызов не вызывался до тех пор, пока я не закрыл сокет, после чего он вызывался непрерывно.Однако для каждого из этих вызовов read () возвращает -1 / WOULD_BLOCK.

Мой второй подход вызывает асинхронно read () , когда уровень IP уведомляет меня овходящие данные.Аналогично, read () возвращает только -1 / WOULD_BLOCK.Я понимаю, что read () может превзойти данные на уровне сокетов, но, надеюсь, это будет означать больше чтения после следующей записи.

Я склонен думать, что якаким-то образом неправильно использует API, так как я - нуб IP / сокетов, а подход выбора вел себя так странно.

Это маловероятная глупая ошибка, поскольку практически идентичный путь кода прекрасно работает в режиме UDP.Единственные отличия: для UDP я использую режим DATAGRAM, sendto () и recvfrom ().Для TCP я использую режим STREAM, write () и read ().

Answer 1

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

Таким образом, мое приложение получало бы уведомление от IP-адреса о входящем TCP и полагало, что должен быть прочитан эхо, но не находило данных на уровне сокетов. Я ожидал, что это означало проблему с моим использованием API или уровней между IP и сокетами. Нет, уведомление было для ACK сервера, а не для эха, и, поскольку оно обрабатывается на уровне TCP, оно никогда не попадает в сокет.