Socket SEND()

[Fairlight]

Y'all catch dis heeyah?  Kenneth Brody been jivin' 'bout like:
> Quoting Fairlight (Mon, 10 Nov 2008 15:34:36 -0500):
> > like Windows...  "Are you sure you want to close the socket?"  "Are you
> > ABSOLUTELY POSITIVE you want to close the socket?"  "There's outstanding
> > data that may not be accounted for, you know.  Perhaps you should sit down,
> > take a stress pill, and rethink closing the socket?"
> >
> > NO, CLOSE THE BLOODY SOCKET AS INSTRUCTED!  :) :) :) :) :)
> 
> Perhaps you need a stress pill as well?  :-)

What, nobody catches 2001 HAL references anymore?  I'm sad!

And I actually take four stress pills a day, thanks.

> (And how come you have no nose?)

I stuck it where it didn't belong one too many times.  Someone bit it off.

> The socket is closed when socketclose() is called.  However, pending
> TCP/IP transactions are not canceled/aborted.  At the transport level,
> the close will take place after all outgoing data has been sent.
> 
> The problem that Nancy is running into is trying to continue reading
> from the socket after all data has been read and the socket has been
> closed.  (Sort of like reading beyond EOF on a file, except that on a
> socket, it's an error.)

Do you support MSG_PEEK?  If so, one could use that to check for incoming
data for number_of_attemts * interval_seconds.  If data shows up, it can be
read with a subsequent "real" recv().  If not, and the timespan allotted is
exceeded, one can take the appropriate steps.

mark->
-- 
"I'm not subtle. I'm not pretty, and I'll piss off a lot of people along
the way. But I'll get the job done" --Captain Matthew Gideon, "Crusade"