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

Discussion in 'Linux Networking' started by przemas_r, Nov 24, 2004.

  1. przemas_r

    przemas_r Guest

    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.
    przemas_r, Nov 24, 2004
    1. Advertisements

  2. przemas_r

    Rick Jones Guest

    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
    Rick Jones, Nov 24, 2004
    1. Advertisements

  3. 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.

    =?ISO-8859-2?Q?Przemys=B3aw_R=F3=BFycki?=, Nov 26, 2004
  4. przemas_r

    Rick Jones Guest

    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
    Rick Jones, Nov 29, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.