TCP failure timeouts

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the network
cable has been unpluged?? I’m using a non-blocking interface and the only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

2

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <paul@gandacar.ca> wrote:

Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the network
cable has been unpluged?? I’m using a non-blocking interface and the only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

3

You could also use a heart beat mechanism via OOB data. Both ways have
good/bad points.

-Adam

Sean Boudreau <seanb@node25.ott.qnx.com> wrote in message
news:b2l5bm$qm3$1@nntp.qnx.com…

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also > http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <> paul@gandacar.ca> > wrote:
Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the
network
cable has been unpluged?? I’m using a non-blocking interface and the
only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no
effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

4

look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.

Thanks I’ll look at these on Monday. Are they system wide global options or
local to my program?

Is there any way that I can take a look at the size of the send buffers
within the tcp/IO drivers? It would be nice if I could just monitor these
and notice myself that the data isn’t going out.

“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b2l5bm$qm3$1@nntp.qnx.com…

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also > http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <> paul@gandacar.ca> > wrote:
Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the
network
cable has been unpluged?? I’m using a non-blocking interface and the
only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no
effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

5

You could also use a heart beat mechanism via OOB data. Both ways have
good/bad points.

I’m integrating with an existing server and can’t modify it. If I could a
simple heat beat scheme would detect this connection failure easily. I am
required to send the server a heart beat every x seconds but he doesn’t
reply. The situation is that while I think I’m connected to the tcp server,
I’m talking to an ATM. I can’t have a back log of messages sitting there
incase the user leaves. If in the 11 minutes or sooner the connection is
restored, then the machine could possible complete the transaction and spit
out the money :frowning: !! This is a worst case scenario that might not even
happen but I don’t know the inner workings of the ATM protocol and it’s
timeouts, etc…


“Adam Mallory” <amallory@qnx.com> wrote in message
news:b2lo4k$7uu$1@nntp.qnx.com…

-Adam

Sean Boudreau <> seanb@node25.ott.qnx.com> > wrote in message
news:b2l5bm$qm3$> 1@nntp.qnx.com> …

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also > http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <> paul@gandacar.ca> > wrote:
Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue
I
can’t seem to resolve is that it takes 11 minutes to detect that the
network
cable has been unpluged?? I’m using a non-blocking interface and the
only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options
like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no
effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul
\

6

Paul Vander Byl <paul@gandacar.ca> wrote:

look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.

Thanks I’ll look at these on Monday. Are they system wide global options or
local to my program?

Is there any way that I can take a look at the size of the send buffers
within the tcp/IO drivers? It would be nice if I could just monitor these
and notice myself that the data isn’t going out.

Not currently as a general operation. If you want an indication at close(),
you can look at the SO_LINGER socket option.

-seanb

“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b2l5bm$qm3$> 1@nntp.qnx.com> …

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also > http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <> paul@gandacar.ca> > wrote:
Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the
network
cable has been unpluged?? I’m using a non-blocking interface and the
only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no
effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

7

I’ve looked at the TimerTimeout() and _NTO_TIMEOUT_SEND |
_NTO_TIMEOUT_REPLY.


I don’t think setting these options will help me in my case. These calls
only apply to kernel specific IPC calls and are set per thread. When I
write data on a non-blocking socket, it is dropped in the send buffer and
another thread comes along and tries to send it. I also doubt that the
thread trying to send the data is waiting on MsgSendv over the TCP
connection. It is just waiting for an ACK.

Am I totally wrong here?

I would figure that I need to set some TCP specific timeouts. All I really
need to do is modify the connection timeout / retransmit timeout value as I
already get the error I’m interested in on the read, problem is that it
takes 11 minutes.


Paul



“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b2l5bm$qm3$1@nntp.qnx.com…

To get SIGPIPE / EPIPE on write() the stack has to know the other
end has shut down the socket by receiving a FIN or RST packet. If
the cable is unplugged…

The *KEEPALIVE options try to detect that case where a nonblocking
read() could potentially block forever.

TCP is persistent and doesn’t give up easily on what are considered
transient network errors. If you don’t like the default timeouts,
look at TimerTimeout() on _NTO_TIMEOUT_SEND | _NTO_TIMEOUT_REPLY.
See also > http://www.unixguide.net/network/socketfaq/2.8.shtml

-seanb

Paul Vander Byl <> paul@gandacar.ca> > wrote:
Not sure if this is the right group to post this in but here goes.

I’ve got a TCP client that connects to an existing server. One Issue I
can’t seem to resolve is that it takes 11 minutes to detect that the
network
cable has been unpluged?? I’m using a non-blocking interface and the
only
error I get is a Connection Timed out on the read.

With help from qnx support, I’ve tried playing with socket options like
SO_KEEPALIVE, and TCP_KEEPALIVE to catch a SIGPIPE but these have no
effect
and the SIGPIPE is never thrown.

Any TCP experts out there have a solution for this??

Thanks,
Paul

8

Paul Vander Byl <paul@gandacar.ca> wrote:

I’ve looked at the TimerTimeout() and _NTO_TIMEOUT_SEND |
_NTO_TIMEOUT_REPLY.

I don’t think setting these options will help me in my case. These calls
only apply to kernel specific IPC calls and are set per thread. When I
write data on a non-blocking socket, it is dropped in the send buffer and
another thread comes along and tries to send it. I also doubt that the
thread trying to send the data is waiting on MsgSendv over the TCP
connection. It is just waiting for an ACK.

Am I totally wrong here?

Yes. :wink: Everything in QNX is built using IPC. So when you send data to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

9

Yes. > :wink: > Everything in QNX is built using IPC. So when you send data to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

So please tell me how setting NTO_TIMEOUT_SEND , and _NTO_TIMEOUT_REPLY
will affect the data sitting in the io-net send buffer?

Maybe I wasn’t clear. Obviously the write uses IPC to send the data to
io-net to be transmitted, but as my post says, the actual transmission over
tcp is a blind send and it just waits to receive an ACK from the server. It
doesn’t use MsgSend() for this, hence TimerTimeout(), NTO_TIMEOUT_SEND , and
_NTO_TIMEOUT_REPLY are useless in this case.





“Chris McKillop” <cdm@qnx.com> wrote in message
news:b30j5d$au8$1@nntp.qnx.com…

Paul Vander Byl <> paul@gandacar.ca> > wrote:
I’ve looked at the TimerTimeout() and _NTO_TIMEOUT_SEND |
_NTO_TIMEOUT_REPLY.

I don’t think setting these options will help me in my case. These
calls
only apply to kernel specific IPC calls and are set per thread. When I
write data on a non-blocking socket, it is dropped in the send buffer
and
another thread comes along and tries to send it. I also doubt that the
thread trying to send the data is waiting on MsgSendv over the TCP
connection. It is just waiting for an ACK.

Am I totally wrong here?


Yes. > :wink: > Everything in QNX is built using IPC. So when you send data to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

10

I think, given the restrictions you’re put under (ie. not able to modify the
server to co-operate), you can’t really do what you’re asking within the TCP
alone.

What about creating an exterior process which does the ‘connected’
monitoring, and your TCP/IP application can use it to determine connectivity
before doing/aborting it’s work?

Besides, just because it left the network interface and went onto the wire,
doesn’t mean the other side got it (and if it’s currently stuck in
retransmit doesn’t mean the other side didn’t get it, it just means their
ack hasn’t arrived). Using pending packet counts (either in the stack or on
the interface) isn’t a reliable way of determining transaction
success/failure. Perhaps ‘TCPIP for Transactions’ is what you need (book by
Stevens).

-Adam


Paul Vander Byl <paul@gandacar.ca> wrote in message
news:b30kj8$9d$1@inn.qnx.com…

Yes. > :wink: > Everything in QNX is built using IPC. So when you send data to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

So please tell me how setting NTO_TIMEOUT_SEND , and _NTO_TIMEOUT_REPLY
will affect the data sitting in the io-net send buffer?

Maybe I wasn’t clear. Obviously the write uses IPC to send the data to
io-net to be transmitted, but as my post says, the actual transmission
over
tcp is a blind send and it just waits to receive an ACK from the server.
It
doesn’t use MsgSend() for this, hence TimerTimeout(), NTO_TIMEOUT_SEND ,
and
_NTO_TIMEOUT_REPLY are useless in this case.





“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:b30j5d$au8$> 1@nntp.qnx.com> …
Paul Vander Byl <> paul@gandacar.ca> > wrote:
I’ve looked at the TimerTimeout() and _NTO_TIMEOUT_SEND |
_NTO_TIMEOUT_REPLY.

I don’t think setting these options will help me in my case. These
calls
only apply to kernel specific IPC calls and are set per thread. When
I
write data on a non-blocking socket, it is dropped in the send buffer
and
another thread comes along and tries to send it. I also doubt that
the
thread trying to send the data is waiting on MsgSendv over the TCP
connection. It is just waiting for an ACK.

Am I totally wrong here?


Yes. > :wink: > Everything in QNX is built using IPC. So when you send data to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\

11

Perhaps ‘TCPIP for Transactions’ is what you need (book by Stevens).

Thanks I might give it a look.





“Adam Mallory” <amallory@qnx.com> wrote in message
news:b30q00$fc0$1@nntp.qnx.com…

I think, given the restrictions you’re put under (ie. not able to modify
the
server to co-operate), you can’t really do what you’re asking within the
TCP
alone.

What about creating an exterior process which does the ‘connected’
monitoring, and your TCP/IP application can use it to determine
connectivity
before doing/aborting it’s work?

Besides, just because it left the network interface and went onto the
wire,
doesn’t mean the other side got it (and if it’s currently stuck in
retransmit doesn’t mean the other side didn’t get it, it just means their
ack hasn’t arrived). Using pending packet counts (either in the stack or
on
the interface) isn’t a reliable way of determining transaction
success/failure. Perhaps ‘TCPIP for Transactions’ is what you need (book
by
Stevens).

-Adam


Paul Vander Byl <> paul@gandacar.ca> > wrote in message
news:b30kj8$9d$> 1@inn.qnx.com> …
Yes. > :wink: > Everything in QNX is built using IPC. So when you send data
to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

So please tell me how setting NTO_TIMEOUT_SEND , and _NTO_TIMEOUT_REPLY
will affect the data sitting in the io-net send buffer?

Maybe I wasn’t clear. Obviously the write uses IPC to send the data to
io-net to be transmitted, but as my post says, the actual transmission
over
tcp is a blind send and it just waits to receive an ACK from the server.
It
doesn’t use MsgSend() for this, hence TimerTimeout(), NTO_TIMEOUT_SEND ,
and
_NTO_TIMEOUT_REPLY are useless in this case.





“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:b30j5d$au8$> 1@nntp.qnx.com> …
Paul Vander Byl <> paul@gandacar.ca> > wrote:
I’ve looked at the TimerTimeout() and _NTO_TIMEOUT_SEND |
_NTO_TIMEOUT_REPLY.

I don’t think setting these options will help me in my case. These
calls
only apply to kernel specific IPC calls and are set per thread.
When
I
write data on a non-blocking socket, it is dropped in the send
buffer
and
another thread comes along and tries to send it. I also doubt that
the
thread trying to send the data is waiting on MsgSendv over the TCP
connection. It is just waiting for an ACK.

Am I totally wrong here?


Yes. > :wink: > Everything in QNX is built using IPC. So when you send data
to
on a non-blocking socket you are MsgSend()'ing that data to io-net.

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/


\