Continuous nc data acquisition fails ocassionally

a closer look at what the cron cron job is doing could shed some light here.
I suspect it could be doing something to disrupt the sending process.

What is the purpose of the cron job that runs at these times?

If it's doing something like a backup for example, it could quiesce or stop services like databases, etc that the sender relies on. Log rotation jobs could stop and re-start the sender causing a loss of the open socket.

What exactly does this cron job do -- kill the sender, then restart it? nc doesn't like that. Even in UDP mode, it's not connectionless - it knows who it's talking to, knows when it dies, and won't take a second connection.

GOT IT! If you want to send to nc more than once, you always have to do so from the same source port and IP. Otherwise nc will think you're a different sender and ignore it. And the source port is randomly chosen, unless you give the sender one with -p...

I have 192.168.0.126:19999 as the receiver here, and 192.168.0.150:20000 as the sender.

Receiving:

$ nc -u -l -p 20000 192.168.0.150 19999
asdf
asdf
...

Sending:

$ echo asdf | nc -p 19999 -u -w 1 192.168.0.126 20000
$ echo asdf | nc -p 19999 -u -w 1 192.168.0.126 20000
$

Note that the sender is not quitting at end-of-line, it's quitting at end-of-file, so should still be able to handle a long, slow stream.

2 Likes

Thanks a lot to Corona and everybody!

Corona I think your solution should work but the problem is that the sender is under a DHCP so the IP would change during time if a disconnection occurs for example.

I finally reach to this solution using ncat, but I think is portable to nc:

while true do
ncat -lu -p 56045 --recv-only -i 60s | ...
end

With this if a disconnection occurs or data sender stops, ncat will start a new connection and everything will continue.

All the best!