send() was hold when sending message with Bolcking mode

Hi,

In my case, send() function is used for sending server message by client and
the socket's mode is Blocking. When the server broke down, the client still
sent message because it didn't know the server was down. After a while, the
send() was hold and couldn't be recovered.
When the socket uses blocking mode, how to recover the blocked send()?

Thanks,
Ethan

In article <cp9oft$n0s$1@news.yaako.com>, "Ethan Yu" <ycy_76@163.net>
wrote:

> Hi,
>
> In my case, send() function is used for sending server message by client a
nd
> the socket's mode is Blocking. When the server broke down, the client stil
l
> sent message because it didn't know the server was down. After a while, th
e
> send() was hold and couldn't be recovered.
> When the socket uses blocking mode, how to recover the blocked send()?

You can use alarm() to send a signal if send() blocks for too long.  Or
use select() to check whether the socket is writable.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry, thanks! The client run based single thread, so the client will still
be blocked if I use alarm() to send a signal.
And in ethereal package, no signal was found when server broke down, I think
we can't get state of this connect.
"Barry Margolin" <barmar@alum.mit.edu> 写入消息新闻:barmar-2FB128.19305409122004@comcast.dc
a.giganews.com...
> In article <cp9oft$n0s$1@news.yaako.com>, "Ethan Yu" <ycy_76@163.net>
> wrote:
> 
>
> You can use alarm() to send a signal if send() blocks for too long.  Or
> use select() to check whether the socket is writable.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***

In article <cpkbt3$99e$1@news.yaako.com>, "Ethan Yu" <ycy_76@163.net>
wrote:

> Barry, thanks! The client run based single thread, so the client will stil
l
> be blocked if I use alarm() to send a signal.

If the SIGALRM handler performs a longjmp(), the send() will be exited
as a result.  Or you can disable system call restarting for SIGALRM, so
send() will return -1 with errno set to EINTR.

> And in ethereal package, no signal was found when server broke down, I thi
nk
> we can't get state of this connect.

Signals are not something that shows up on the network, they're internal
to the Unix process.  Did you mean "no message was sent when server
broke down"?  That's true.  This is why you have to use some kind of
timeout in the application.

> "Barry Margolin" <barmar@alum.mit.edu>
> 写入消息新闻:barmar-2FB128.19305409122004@comcast.dca.giganews.com... 

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry, thanks! The client run based single thread, so the client will still
be blocked if I use alarm() to send a signal.
And in ethereal package, no signal was found when server broke down, I think
we can't get state of this connect.
"Barry Margolin" <barmar@alum.mit.edu> 写入消息新闻:barmar-2FB128.19305409122004@comcast.dc
a.giganews.com...
> In article <cp9oft$n0s$1@news.yaako.com>, "Ethan Yu" <ycy_76@163.net>
> wrote:
> 
>
> You can use alarm() to send a signal if send() blocks for too long.  Or
> use select() to check whether the socket is writable.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***

"Barry Margolin" <barmar@alum.mit.edu> 写入消息新闻:barmar-E8FCD0.19414113122004@comcast.dc
a.giganews.com...
> In article <cpkbt3$99e$1@news.yaako.com>, "Ethan Yu" <ycy_76@163.net>
> wrote:
> 
>
> If the SIGALRM handler performs a longjmp(), the send() will be exited
> as a result.  Or you can disable system call restarting for SIGALRM, so
> send() will return -1 with errno set to EINTR.

Good idea! I'll try this solution.
Barry, thanks for your help!
 
>
> Signals are not something that shows up on the network, they're internal
> to the Unix process.  Did you mean "no message was sent when server
> broke down"?  That's true.  This is why you have to use some kind of
> timeout in the application.

Yes, the server broke down due to platform restarting, then no FIN, RESET or
other messages
were deliveried.
 
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***