SO_SNDLOWAT not avalaible; how can i avoid non-blocking sockets

Hi all!

I'm writing socket app, which will transmit data in fixed size packets.
I'd like to be able to pass N bytes to send (or write) function and
ensure that it won't block.

I was willing to set SO_SNDLOWAT option properly and use select to avoid
blocking send. On linux it's impossible, because SO_SNDLOWAT option is
unavailable. After one hour fruitless googling and newsgroup browsing I
had to give up.

I know I can achieve desirable effect by using non-blocking sockets. But
due to its CPU-consuming nature I treat it as last resort.

 

Does your application have any data arriving from the other end -
perhaps replies to messages you previously sent?

If you go into a select or poll call it shouldn't be all that bad.
Typically, TCP will window update for non-trivial quantities of data -
O(2MSS) so it won't be as if you would be writing a single byte into
the socket all the time. Of course, it won't be a whopping 8KB or
what have you.

If you have messages coming back, you can use them to determine when,
beyond a shadow of a doubt some quantity of data has left your
SO_SNDBUF. If you receve some application-level ack of message N, you
know that means that the remote has received that message, which means
that TCP has received that message, and likely as not has piggy-backed
an ACK and TCP window update to the reply message (if not sooner).
That means you know that there are at least sizeof(messageN) bytes
available in your SO_SNDBUF.

Similarly, if you know you never have more than M of these messages
outstanding at any one time, if you make your SO_SNDBUF
M*sizeof(message) bytes in size, you will "know" that you can write an
entire message into the socket in one call.

rick jones

 

Thanks a lot for your answer. You presented handful useful solutions.
I have chosen even the other one. Now all connections are in blocking
mode, but each of connections has a thread dedicated to it. I hope this
will work as expected.

Cheers!

 

There was a reason I didn't mention threads Threads can be quite
convenient, heck, sometimes even useful However, "connection per
thread" isn't exactly the most "scalable" of solutions out there. I
personally do not see it as being all that much better than
"connection per process." Just keep that in mind if you decide to
scale your application out to more than a "few" (for some, rather
fluid definition of "few" ) connections.

rick jones