BSD socket recv() Error failure after 14336 bytes transfered 98% of the

[btoback at optc.com (Bruce Toback)]

OSX Developer writes:

>So I was wondering how is it possible that two send() calls, (one with 
>only four bytes matched on the read side, and the other with any length of 
>data, match by a following recv() statement on the read side), would cause 
>two tenths of a second delay? Is that buggy? It seems like it should not 
>matter.

There's something called the Nagle algorithm that's getting in your way 
here. It's designed to try and consolidate small packets into larger 
ones, since there's overhead involved in sending a packet. The four-byte 
packet was being held just to see if you were going to send more data. 
You can disable that with a socket option (TCP_NODELAY), but just sending 
everything at once is a better solution. 

>since I can control the amount read in, current thanks to Mr. Zorko only 4 
>bytes containing the message length via the tricky htonl() function

Remember that you won't necessarily get all four bytes of the count in 
one read. Your read of the count should be in a loop, too.

>Finally I thought since I do not have any books on this subject, I would 
>ask for any comments on 'Blocking'. 
>I guess one could interpret this many ways ... 
>         Does it mean data will be sent in pieces or Blocks?
>or       Does it mean data will be sent in one BIG Block?
>or maybe Does it mean data will be blockable (or stoppable), and if so by 
>what? What purpose does this serve?
>
>...
>
>Next I realized that I had and can set the MaxPending Connections to the 
>listening Thread to a maximum possible value of 127 or so (with OSX?). I 
>would like this to be something much higher then that. 

It's unlikely that you'll ever need to queue 127 pending connections. 
Connections are "pending" for only a tiny fraction of their life. 

You really, really, really, really need to buy a book on this subject. 
The API documentation is just that: documentation for an interface to a 
series of abstractions. Unless you understand the abstractions and 
associated terminology, the documentation for an API is bound to be 
misleading. The classic book on sockets in the Unix environment is 
Stevens (<http://www.amazon.com/exec/obidos/ASIN/013490012X/opt>, but 
there are many others. Once you understand the abstractions, the API and 
the associated OO wrappers will make a lot more sense.

Buying a book will save you an awful lot of head-scratching, and you 
can't really expect chapter-length treatises as answers to questions you 
post on a mailing list. Stop what you're doing, buy a bottle/case/pot of 
your favorite tipple, put your feet up, read the book and work through 
the examples. It'll take you a day, but you've already been thrashing 
around for longer than that.

-- Bruce


--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback@xxxxxxxx                   |     -- Edna St. Vincent Millay