From: papamms on
hi
i have a simple network program, it is blocking socket with
multthread. all socket had set SOL_SOCKET.(SO_SNDTIMEO)
now i found it is hand on send() function. what's wrong?

code like this

bool SetSocket(SOCKET & sClient, UINT32 urecvout, UINT32 usendout)
{
int x;
UINT32 recvout = urecvout;
UINT32 sndout = usendout;
int len = recvout;

#ifndef WIN32
struct timeval tv;
tv.tv_usec = 0;
tv.tv_sec = urecvout /1000 +1;
x = setsockopt( sClient, SOL_SOCKET, SO_SNDTIMEO, &tv,
sizeof(tv));
tv.tv_sec = usendout /1000 +1;
x = setsockopt( sClient,SOL_SOCKET, SO_RCVTIMEO, &tv,
sizeof(tv));
#endif

return true;
}


bool WriteHttpRequest( SOCKET &sClient, const std::string &request)
{

int needsend = request.length();
int sended = 0;
int x;

while (1)
{
x = send(sClient, request.c_str() + sended, needsend - sended ,
0); // hang here!!!
if (x > 0)
{
sended += x;
if (sended >= needsend)
{
return true;
}
}
else if (x <=0)
{
return false;
}

}
return false;// end while
}

case 1, programer hang on send, all socket had been close(). i check
socket status by netstat -pns

case 2 programer hang on send, socket is on estable status, it had
keep on this status more than 24 hours.


my code



create socket;

SetSocket(); // set socket

while (1)
{
write_something();

read_something();


do_somethingelse();
// if this function use too many time, socket maybe closed by
remote.
// progarma will hang one next send() ???
// but i think if function usee too many time, socket closed by
remote,
// send function will return 0, ps ( i had handle PIPE single)
//
//
//

write_something();

read_something();


}

thank you


papamms

From: David Schwartz on
On May 20, 6:54 pm, papamms <ppmsn2...(a)gmail.com> wrote:

>    i have a simple network program, it is blocking socket with
> multthread. all socket had set SOL_SOCKET.(SO_SNDTIMEO)
> now i found it is hand on send() function. what's wrong?

You did a blocking send. It will block as long as it needs to in order
to either establish that the send has succeeded or cannot succeed. If
you want non-blocking operations, use them.

> #ifndef WIN32
>     struct timeval tv;
>     tv.tv_usec = 0;
>     tv.tv_sec = urecvout /1000 +1;
>      x = setsockopt( sClient, SOL_SOCKET, SO_SNDTIMEO, &tv,
> sizeof(tv));
>     tv.tv_sec = usendout /1000 +1;
>      x = setsockopt( sClient,SOL_SOCKET, SO_RCVTIMEO, &tv,
> sizeof(tv));
> #endif

I think you misunderstand the semantics of SO_SNDTIMEO and
SO_RCVTIMEO. They do *NOT* set operation timeouts.

DS
From: Rick Jones on


http://portabilityblog.com/blog/archives/10-SO_SNDTIMEO-and-SO_RCVTIMEO.html

rick jones
--
the road to hell is paved with business decisions...
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: papamms on
i run it under linux. from the blog linux actually support these
timeouts.
maybe my progarm send buff is full? and timeout didn't work?


On 5ÔÂ22ÈÕ, ÉÏÎç6ʱ23·Ö, Rick Jones <rick.jon...(a)hp..com> wrote:
> http://portabilityblog.com/blog/archives/10-SO_SNDTIMEO-and-SO_RCVTIM...
>
> rick jones
> --
> the road to hell is paved with business decisions...
> these opinions are mine, all mine; HP might not want them anyway... :)
> feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

From: David Schwartz on
On May 21, 7:43 pm, papamms <ppmsn2...(a)gmail.com> wrote:

> i run it under linux.  from the blog linux actually support these
> timeouts.
> maybe my progarm send buff is full? and timeout didn't work?

Why would you expect a perfectly healthy, 100% working connection to
timeout, regardless of what you set the timeout values to? Again,
these are *NOT* operation timeouts. They will not time out a perfectly
good connection on any sane implementation.

DS