No error while sending via TCP Socket

[Martin Bürkle]

Hi NG,

I have writen a programm using TCP sockets. After i get the connection
to another socket I cut the Ethernet cable. Then I send a message.
The program doesnt raise any exception. Can somebody tell me why and
give me a hint how to get an exception

Thanks for your help.

Martin

[Ben Sizer]

Martin Bürkle wrote:

I have writen a programm using TCP sockets. After i get the connection
to another socket I cut the Ethernet cable. Then I send a message.
The program doesnt raise any exception. Can somebody tell me why and
give me a hint how to get an exception

Have you tried waiting 30 seconds or so? The connection may just take a
while to time out.

--
Ben Sizer

[Laszlo Nagy]

Martin Bürkle írta:

Hi NG,

I have writen a programm using TCP sockets. After i get the connection
to another socket I cut the Ethernet cable. Then I send a message.
The program doesnt raise any exception. Can somebody tell me why and
give me a hint how to get an exception

Okay, let's suppose you do not cut the ethernet cable and your message
arrives on the other side, but the receiver program has a problem (not
enough memory, bug in the handling code etc.) so your message is not
processed on the other side. Most of the time, you do not only want to
check if your message was transferred - you also need to check if that
is actually processed. The TCP protocol cannot do this for you.Your
clients needs to send back another message that notifies the sender
about successful processing. Your sender program can wait for this
notification, and then raise an exception after some timeout.

In other words, you need to develop your own communication protocol over
TCP/IP. You should try to minimize the number of
send-receive-notification cycles, because the answer time can be high,
compared to the transfer speed of the communication channel. And also
because notifications are usually small, and they a buffered for a
while... I have seen a paper about designing protocols over TCP/IP, but
I do not remember now. Others will help you for sure.

Please also consider UDP (if possible), which can be much more efficient.

Best,

Laszlo

[Laszlo Nagy]

Ben Sizer írta:

Martin Bürkle wrote:

I have writen a programm using TCP sockets. After i get the connection
to another socket I cut the Ethernet cable. Then I send a message.
The program doesnt raise any exception. Can somebody tell me why and
give me a hint how to get an exception

Have you tried waiting 30 seconds or so? The connection may just take a
while to time out.

I'm not sure if this will help him. He told that the program doesn't
raise an exception. I suppose this also means that socket.send() was
successful. If his program does not want to send or receive anything
else, then he will not get an exception. Otherwise if socket.send()
blocks his program, then you are right - he needs to wait. But I think
he would have seen that his program is still running, and he would not
have written what he wrote. If his program is still running, than he
shouldn't have told "it did not raise an exception". :-)

Laszlo

[Laszlo Nagy]

Laszlo Nagy írta:

Ben Sizer írta:

Martin Bürkle wrote:

I have writen a programm using TCP sockets. After i get the connection
to another socket I cut the Ethernet cable. Then I send a message.
The program doesnt raise any exception. Can somebody tell me why and
give me a hint how to get an exception

Have you tried waiting 30 seconds or so? The connection may just take a
while to time out.

I'm not sure if this will help him. He told that the program doesn't
raise an exception. I suppose this also means that socket.send() was
successful. If his program does not want to send or receive anything
else, then he will not get an exception. Otherwise if socket.send()
blocks his program, then you are right

Another idea: probably his message is too small to fit one TCP packet.
socket.send() succeeds, but the TCP packet is not sent out. By the time
the packet driver tries to send out the (short) TCP packet, the
socket.send() call is not active, so it cannot raise an exception.

Laszlo

[Grant Edwards]

On 2006-06-30, Martin Bürkle <bu******@web.de> wrote:

I have writen a programm using TCP sockets. After i get the
connection to another socket I cut the Ethernet cable. Then I
send a message. The program doesnt raise any exception. Can
somebody tell me why
Because send() has successfully passed the packet to the
network stack. If you want to know whether the application on
the other end received it, you need an application-layer
protocol that acknowleges the data.
and give me a hint how to get an exception

You can't -- unless you've enabled the keepalive option on the
TCP connection and you've waited the requisite time after the
cable is cut before sending your data (IIRC it takes a couple
hours for an idle TCP connection to time out because of a link
being down).

TCP/IP is designed to be fault-tolerant. Temporary breaks in
cables aren't supposed to cause failures.

--
Grant Edwards grante Yow! I feel like I'm
at in a Toilet Bowl with a
visi.com thumbtack in my forehead!!

[Ben Sizer]

Grant Edwards wrote:

On 2006-06-30, Martin Bürkle <bu******@web.dewrote:

I have writen a programm using TCP sockets. After i get the
connection to another socket I cut the Ethernet cable. Then I
send a message. The program doesnt raise any exception. Can
somebody tell me why

Because send() has successfully passed the packet to the
network stack. If you want to know whether the application on
the other end received it, you need an application-layer
protocol that acknowleges the data.

and give me a hint how to get an exception

You can't -- unless you've enabled the keepalive option on the
TCP connection and you've waited the requisite time after the
cable is cut before sending your data (IIRC it takes a couple
hours for an idle TCP connection to time out because of a link
being down).

TCP/IP is designed to be fault-tolerant. Temporary breaks in
cables aren't supposed to cause failures.

But surely a permanent break - which is what I believe was implied -
means the data never arrives, which in turn means you never get an ack,
and eventually the TCP connection should drop, and Python should raise
an exception. Right? I'm very used to connections dropping after much
less than a minute because the host became unreachable or took too long
to send a response.

(Sorry for the large quote but all the context seemed relevant.)

--
Ben Sizer

[cmdrrickhunter]

Q: I have been looking through Volume 1 & 2 on the topics of TCP
timeouts. I have been looking in the section on "Timeout And
Retransmission" where you talk about round trip times. My question to
you would be what would make a tcp connection timeout? Is there a
certain number of retries that need to happen before a timeout?

A: TCP does not define a maximum number of retransmissions before
giving up. However, it does define a maximum segment lifetime, and
assumes that no response within two maximum segment lifetimes indicates
a hopeless situation. Thus, if one attempts to communicte with a
machine that is down, TCP will give up after retransmitting for about 5
minutes

Copied from a FAQ.

TCP will not let you know that the socket is down until you try to send
or recieve on the socket. At that time a socket error will occur.

And unless he has odd gear, the nagle algorithm will not hold a packet
back if there's no packets still being transmitted (ack pairs haven't
been received). I've had one radio which repackaged things funny, but
the data still got through, it just took some time.

[Grant Edwards]

On 2006-07-03, Ben Sizer <ky*****@gmail.comwrote:

>>and give me a hint how to get an exception

You can't -- unless you've enabled the keepalive option on the
TCP connection and you've waited the requisite time after the
cable is cut before sending your data (IIRC it takes a couple
hours for an idle TCP connection to time out because of a link
being down).

TCP/IP is designed to be fault-tolerant. Temporary breaks in
cables aren't supposed to cause failures.

But surely a permanent break - which is what I believe was
implied - means the data never arrives, which in turn means
you never get an ack, and eventually the TCP connection should
drop,

Correct. But in the case described by the OP, he disconnects
the cable when there is no traffic. Unless the keepalive
feature has been enabled, TCP won't detect the cable is broken
until some time _after_ the OP has written data to it [it won't
timeout until after the stack send and resends that data
repeatedly and doesn't get an ACK].

There's no way the TCP stack can raise an exception when the
data is written, because the TCP stack hasn't yet discovered
that the link is dead.

and Python should raise an exception. Right?

No. The TCP connection timeout only changes the state of the
socket. There's no way for the TCP stack to cause an exception
in a Python program until the Python program accesses the
socket again after the timeout has occurred.

You'll get an error when you try to write to the closed
connection or an EOF when you try to read from the closed
connection.

I'm very used to connections dropping after much less than a
minute because the host became unreachable or took too long to
send a response.

You're talking about the case where there's un-ACKed data.
Breaking a link when there's no un-ACKed data (which is what
the OP did) will require an hour or two to timeout _iff_
keepalive is enabled. If keepalive has not been enabled, a
broken connection with no un-ACKed data will never timeout.

--
Grant Edwards grante Yow! .. I must be a
at VETERINARIAN...
visi.com

[Ben Sizer]

Grant Edwards wrote:

You're talking about the case where there's un-ACKed data.
Breaking a link when there's no un-ACKed data (which is what
the OP did) will require an hour or two to timeout _iff_
keepalive is enabled. If keepalive has not been enabled, a
broken connection with no un-ACKed data will never timeout.

My mistake, Grant. I was under the impression that a blocking send()
would wait for an ACK before proceeding, but upon checking the man
pages I see that this is not the case. It does seem to make the
oft-cited TCP guarantee of data arrival a little weaker however, if you
can't necessarily know how many of your sends have succeeded or not.
Doubtless I am missing something here, too. Time to dig out my old
networking notes, perhaps.

--
Ben Sizer

[Grant Edwards]

On 2006-07-03, Ben Sizer <ky*****@gmail.comwrote:

Grant Edwards wrote:

>You're talking about the case where there's un-ACKed data.
Breaking a link when there's no un-ACKed data (which is what
the OP did) will require an hour or two to timeout _iff_
keepalive is enabled. If keepalive has not been enabled, a
broken connection with no un-ACKed data will never timeout.

My mistake, Grant. I was under the impression that a blocking
send() would wait for an ACK before proceeding, but upon
checking the man pages I see that this is not the case.

It would be awfully nice if there was such an option. I've
needed to do exactly that once or twice, and had to add a
kernel-mode ioctl() call to the Linux kernel so I could wait
until the data sent on a socket had been ACKed. The reason I
needed to do that was because the application layer protocol
was broken with no way to change it.

It does seem to make the oft-cited TCP guarantee of data
arrival a little weaker however, if you can't necessarily know
how many of your sends have succeeded or not. Doubtless I am
missing something here, too. Time to dig out my old networking
notes, perhaps.

If you really do need to know if the data got there, I guess
you're supposed to use an application layer ACK. Even if you
could wait for an ACK, that only means that the TCP/IP stack on
the other end got the packet. It doesn't mean that the
application has read the data (the application could well be
locked up somehow with the data that has been ACKed just
sitting in a buffer).

--
Grant Edwards grante Yow! Now that we're
at in LOVE, you can BUY
visi.com this GOLDFISH for a 48%
DISCOUNT.