When push is sent in us, packets on the pull side will be lost

[halikuosang]

Describe the bug

When I use the push/pull communication method, packet loss occurs. After initializing nng_socket in the push process, calling nng_send to send data at intervals of usleep(1) results in packet loss when using nng_recv in the pull process. The packet loss rate cannot be determined as it occurs randomly. Increasing the usleep interval to usleep(100)/usleep(1000) reduces the packet loss rate, but it still cannot completely avoid packet loss. I want to know if there is a performance bottleneck when using usleep for sending.

I have already tried the following methods, but the packet loss issue remains unresolved:

1. Using nng_send with blocking mode.
2. Using non-blocking mode and polling for nng_recv.

If you have any suggestions for addressing the packet loss issue, I would greatly appreciate your input.

Expected behavior nng_recv can receive all data without losing packets

Actual Behavior The nng_recv cannot receive all data and has a certain probability of packet loss

To Reproduce See this demo:

• ./test_pilot_pushpull push
• ./test_pilot_pushpull test_pushpull.zip

Environment Details

• NNG version 1.6.0-pre
• Allwinner T507(Quad A53)
• aarch64-linux-gnu-gcc(gcc version 7.4.1 20181213) and C
• Shared library(libnng.so.1.6.0-pre)

Additional context Increasing pull sock's NNG_OPT_RECVBUF to 8K also did not solve the packet loss problem. In addition, the pub/sub communication mode is tested. When pub is sent in us mode, the sub side will also lose data

[gdamore]

You have at least three problems:

1. You're using non-blocking send with a limited buffer (SENDBUF needs to be > 100 -- the RECVBUF doesn't count because the TCP pipe will back up before the receiving process can buffer it)
2. You're not waiting for connection establishment
3. You're also using NONBLOCK sending -- which means that we don't wait until we can send -- we just fail quickly instead. If you want assured delivery with PUSH, please don't use that flag.

I don't see any actual NNG bug(s) here.

[uusdnfdsfhnttyh]

解决了吗 我也遇到这个问题了

[uusdnfdsfhnttyh]

According to my tests, this problem is probably a problem with the latest Windows 11 system, because the problem disappeared after I changed to another system even older Windows 11.