Can netcat block on sending side?

After failing to produce a robust messaging system using named pipes I’m trying to use netcat. My receiving side will be a small script that listens to a port using netcat, spawns a new listener and execute a script based on the received message:

message=$(netcat -l 5555)
nohup >/dev/null 2>&1 &
cmd=${message%% *}
parms=${message#* }
nohup ${cmd} ${parms} >/dev/null 2>&1 &

On the sending side it will be nothing more complex than

echo "<command> <parms>" | netcat host 5555

My problem is that there will be a short gap between the listener closing the connection and a new listener starting. The echo thru netcat ends immediately having done nothing if a listening process does not receive the message, so I have the potential to lose messages. Is it possible to have netcat block when sending data until something receives it? I’ve tried -q and -w but neither do what I want. Message rate will be high and from multiple hosts so chance for loss if high if the message sender can’t block until its message is consumed.

Additional info

To work around the sender not blocking I’ve tried to implement a robust sender for the above listener using


while [[ true ]]; do

    while [[ ${rc} -ne 0 ]]; do
        echo "<command> <parms> ${msgno} ${retrycount}" | netcat host 5555"
        echo "<command> <parms> ${msgno} ${retrycount}" >> local.log

Although I can’t find a list of netcat exit codes it appears that it should only exit with 0 if the connection can be made. What I’m seeing in the local.log on the writer end is what I would expect; msgno increasing after each send, and retrycount increasing occasionally if it can’t send. On the receiving end I occasionally get empty messages and/or gaps in the msgno sequence. I’m at a loss to explain either other than netcat sometimes seems to lose stdin, and sometimes exits with 0 even if it hasn’t sent a message. Most of the time it seems to work fine but that’s not good enough; I need to guarantee the messages get thru.

Direct Link






Both comments and pings are currently closed.

Comments are closed.