 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Bo Berglund
Guest
|
 Posted: Sun Feb 05, 2006 12:01 pm Post subject: TClientSocket disconnect mystery with D7 Pro |
 |
|
I have posted two threads concerning a project I am working on which
uses TCPIP socket communications. So far I am still using the "old"
TClientSocket component.
I have a question regarding the way the sockets really work that
mystify me a lot:
If I create a test by having a client and server application and
connect from the client to the socket interface on the server and then
I shut down tha server, I will get a disconnect event on the client.
But if I connect the client to a physical port server using the same
type of connection and then I pull the network cable out of the port
server there is no disconnect event fired.
On the other hand shutting down the delphi server app makes the client
discover that the connection is broken.
Why is there a difference? I thought that a connected socket
connection monitored its connect state so that it can see if a network
cable is pulled out. But this seems not to be the case.
Can someone clarify this matter, please?
/Bo |
|
| Back to top |
|
 |
Martin James
Guest
|
| Posted: Sun Feb 05, 2006 2:00 pm Post subject: Re: TClientSocket disconnect mystery with D7 Pro |
|
|
"Bo Berglund" <bo.berglund (AT) telia (DOT) com> wrote in message
news:q7mbu1haj0grp3igsfpj5f2j434e57cue5 (AT) 4ax (DOT) com...
| Quote: | I have posted two threads concerning a project I am working on which
uses TCPIP socket communications. So far I am still using the "old"
TClientSocket component.
I have a question regarding the way the sockets really work that
mystify me a lot:
If I create a test by having a client and server application and
connect from the client to the socket interface on the server and then
I shut down tha server, I will get a disconnect event on the client.
|
Yes, as expected - a managed 'four-way-handshake' TCP disconnect.
| Quote: | But if I connect the client to a physical port server using the same
type of connection and then I pull the network cable out of the port
server there is no disconnect event fired.
|
Yes - as expected, no handshake, no disconnect.
| Quote: | On the other hand shutting down the delphi server app makes the client
discover that the connection is broken.
|
Yes, as expected - a managed 'four-way-handshake' TCP disconnect.
| Quote: | Why is there a difference? I thought that a connected socket
connection monitored its connect state so that it can see if a network
cable is pulled out.
|
There is no discrete physical connection path, so there can be no
monitoring. After a TCP connect between a client and server has been
successful, there are two 'half-connections' between them, but this does not
define any physical connection. IP was specifically designed to avoid
connection paths so that packets can be switched around between links so as
to allow communication even if one link becomes unavailable.
Think about it - two computers on different continents have a TCP
connection. There are lots of possible routes between them and IP routes
the packets transparently between them. If one route becomes unavailable
because a plug has fell out of a router in Frankfurt, the network will route
packets via a link through Hamburg.
It's just not reasonable for massive IP networks to monitor any 'connection
status' because there is no fixed connection path.
| Quote: | But this seems not to be the case.
|
This is why servers that do not reply are said to be 'unreachable', not
'disconnected'. If a server becomes unreachable because it has crashed, and
so was unable to perform a managed disconnect by exchanging data with all
its clients, the clients will be unaware that the server has gone away until
they try to send it data, at which point, a TCP timer will eventually signal
that packets have not being ACKed by the server for a long time.
IMHO, the later version of Windows, together with later 10baseT network
cards, can detect and signal that the cable *in the back of the client
computer* has been physically disconnected, but are still unable to detect
if a server has become unreachable for all the many other reasons.
The only way to determine 'reachability' is to send data to the other end
and wait to see if it is acknowledged. If a TCP client sends no data and
it's server becomes unreachable, (eg. crashes), the client will never know.
If reasonably timely notice is requred of unreachability, it's usual to use
either the 'Kepalive' socket option, (still slow and inflexible), or to use
a user protocol that exchanges 'NOP' packets wit hthe server if no data has
been exchaged for some interval.
Rgds,
Martin |
|
| Back to top |
|
|
Bo Berglund
Guest
|
| Posted: Sun Feb 05, 2006 4:00 pm Post subject: Re: TClientSocket disconnect mystery with D7 Pro |
|
|
On Sun, 5 Feb 2006 13:16:44 -0000, "Martin James"
<mjames_falcon (AT) dial (DOT) pipex.com> wrote:
| Quote: |
"Bo Berglund" <bo.berglund (AT) telia (DOT) com> wrote in message
news:q7mbu1haj0grp3igsfpj5f2j434e57cue5 (AT) 4ax (DOT) com...
If I create a test by having a client and server application and
connect from the client to the socket interface on the server and then
I shut down tha server, I will get a disconnect event on the client.
Yes, as expected - a managed 'four-way-handshake' TCP disconnect.
But if I connect the client to a physical port server using the same
type of connection and then I pull the network cable out of the port
server there is no disconnect event fired.
Yes - as expected, no handshake, no disconnect.
On the other hand shutting down the delphi server app makes the client
discover that the connection is broken.
Yes, as expected - a managed 'four-way-handshake' TCP disconnect.
|
How is this 'four-way-handshake' implemented? Can I add it to my own
client application without doing anything on the other end?
... snip
| Quote: | The only way to determine 'reachability' is to send data to the other end
and wait to see if it is acknowledged. If a TCP client sends no data and
it's server becomes unreachable, (eg. crashes), the client will never know.
If reasonably timely notice is requred of unreachability, it's usual to use
either the 'Kepalive' socket option, (still slow and inflexible), or to use
a user protocol that exchanges 'NOP' packets wit hthe server if no data has
been exchaged for some interval.
|
Then I will ask the port server vendor for a way to have a heartbeat
or keepalive signal.
Thanks,
Bo |
|
| Back to top |
|
|
Martin James
Guest
|
| Posted: Sun Feb 05, 2006 8:01 pm Post subject: Re: TClientSocket disconnect mystery with D7 Pro |
|
|
| Quote: |
How is this 'four-way-handshake' implemented?
|
The TCP stack does it on it's own. When you disconnect a connected socket,
the appropriate messaging is performed between both ends to ensure that they
both shut down and release the sockets. Note that, as I already hinted,
this can only happen if both ends are actually up and can reach each other.
| Quote: |
Then I will ask the port server vendor for a way to have a heartbeat
or keepalive signal.
|
Yes. Perhaps one already exits in your protocol - maybee you can ask for a
status or uptime report, anything that does nothing will do <g>
Rgds,
Martin |
|
| Back to top |
|
|
Bo Berglund
Guest
|
| Posted: Sun Feb 05, 2006 9:02 pm Post subject: Re: TClientSocket disconnect mystery with D7 Pro |
|
|
On Sun, 5 Feb 2006 19:57:16 -0000, "Martin James"
<mjames_falcon (AT) dial (DOT) pipex.com> wrote:
| Quote: |
How is this 'four-way-handshake' implemented?
The TCP stack does it on it's own. When you disconnect a connected socket,
the appropriate messaging is performed between both ends to ensure that they
both shut down and release the sockets. Note that, as I already hinted,
this can only happen if both ends are actually up and can reach each other.
|
I think I get it now, if any side conciously tells the TCP stack to
disconnect the socket connection then there will be a message exchange
that tells the other side what is going on. But of course if the
reason for the disconnect is more like a power fail or a physical
connection break (router or switch malfunction or physical network
cable unplugging) then there is no built-in method for catching this.
| Quote: |
Then I will ask the port server vendor for a way to have a heartbeat
or keepalive signal.
Yes. Perhaps one already exits in your protocol - maybee you can ask for a
status or uptime report, anything that does nothing will do <g
|
They have two ports to communicate on, one is a contol connection
using the Telnet port (23) and the other is a data only connection on
the (default) port 1001. It is possible to have a connection to 23
while 1001 is up and ask for the status of the device. This will at
least rule out the physical link failures since both ports come in on
the same interface. The only remaining thing then is to check if the
data port is connected properly. But they seem to miss such a check
command right now... |
|
| Back to top |
|
|
Martin James
Guest
|
| Posted: Mon Feb 06, 2006 8:02 am Post subject: Re: TClientSocket disconnect mystery with D7 Pro |
|
|
| Quote: |
I think I get it now, if any side conciously tells the TCP stack to
disconnect the socket connection then there will be a message exchange
that tells the other side what is going on. But of course if the
reason for the disconnect is more like a power fail or a physical
connection break (router or switch malfunction or physical network
cable unplugging) then there is no built-in method for catching this.
|
Yes. If the server becomes unreachable because of a network problem, a
'quiet' client knows nothing about it. If the client then disconnects its
own socket, it attempts to exchange disconnect messaging with the server.
This will fail and the server will still have its 'half-connection' still
open. Whether the managed disconnect is going to be sucessful or not, the
client disconnects and releases its own socket and returns from this
disconnect operation 'immediately'. The TCP stack on the client keeps the
socket in a 'TIMED_WAIT' state for a couple of minutes after the disconnect
so that any outstanding messaging, eg. the reainder of the 'disconnect'
protocol, can be performed, before the socket as actully made available for
re-use.
| Quote: |
They have two ports to communicate on, one is a contol connection
using the Telnet port (23) and the other is a data only connection on
the (default) port 1001. It is possible to have a connection to 23
while 1001 is up and ask for the status of the device. This will at
least rule out the physical link failures since both ports come in on
the same interface. The only remaining thing then is to check if the
data port is connected properly. But they seem to miss such a check
command right now...
|
With Indy, or TClientSocket in blocking mode, in a thread, these polls are
fairly easy since the read operations on the socket have timeouts. A
'pollSent' boolean can flag the state of the connection. This flag is
cleared whenever any data is received, including the poll ack. If the read
times out and the flag is clear, a poll request is sent and the flag set.
If the read times out and the flag is set, the server is unreachable. Note
that if writes to the socket are made from another thread, the socket.write
calls may need a critical section to prevent the read thread from writing a
poll request 'in the middle of' a data write from the other thread/s.
I'm sure that some sort of similar mechanism is possible in non-blocking
clients, but I do not know how to do this, exactly. Presumably, a timer can
be used thought, ideally, this timer should form part of the client socket
context rather than just being plonked on a form.
Rgds,
Martin |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
