TClientSocket.OnRead event

[Paul Toms]

Hi!
My application uses Delphi4 and the TClientSocket component in order to
establish TCP comms between 2 computers. Whilst this is generally reliable,
there are occassions when it seems that the TClientSocket.OnRead event fails
to occur despite a message having been sent (as witnessed by a network
monitoring tool 'listening' in on the network) to the client socket. Has
anyone else experienced similar problems? Any thoughts would be gratefully
received!
Paul

[Not Me]

I'm not sure if you're already doing this, but in the OnDisconnect method
you should do another S := S +Socket.ReadText. Apparently some leftover
data may not trigger the OnRead (maybe something to do with packet size
triggers & such?)

"Paul Toms" <paul...@baesystems.com> wrote in message
news:3c690fd8$1...@pull.gecm.com...

[Dirk Claessens]

"Paul Toms" <paul...@baesystems.com> schreef in bericht
news:3c690fd8$1...@pull.gecm.com...

> Hi!
> My application uses Delphi4 and the TClientSocket component in order to
> establish TCP comms between 2 computers. Whilst this is generally
reliable,
> there are occassions when it seems that the TClientSocket.OnRead event
fails
> to occur despite a message having been sent (as witnessed by a network
> monitoring tool 'listening' in on the network) to the client socket. Has

> anyone else experienced similar problems? [snip]

Hi Paul,

I've been using Delphi's TClient/TServerSocket for many years now, and I
have never experienced such behaviour, however, only after removal of the
bugs in my code <g>
There are no blatant bugs in Tserver/TClientSocket. If you can see packets
arrive with the monitor, then either the receiving socket is closed, or a
previous error condition was not trapped. ( You _do_ trap OnError do you? )

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://users.pandora.be/dirk.claessens2
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

[Tony]

On Tue, 12 Feb 2002 12:53:21 -0000, Tony wrote:

Oh yes several times. Due to other design considerations I used to do
the following, it increases the overhead a little but if you must
guarantee receipt of all messages it's very robust.

All you do is put your the data you are going to send in a queue.
Send the top item from the queue. Take the top item off the queue when
it's receipt is acknowledged.

Make sure you are trapping error events, disconnects etc. If message
intervals vary dramatically. Set up a Heartbeat message, 'Are you
there' 'yup' sort of thing. Set a timeout on the connection and deal
with it it if it happens.

If you prefix all messages with a message_id and a type. You can get
some nice neat code without a great deal of effort.

The above strategy was used to enable a TCP/IP link between an NT
server and a MicroVax 3100 for a 24/7 operation. Once I'd ironed out a
few wrinkles it was never down for more than 60 seconds unless one of
the machines was powered down and it detected that and started up
again as soon as the machine re-appeared on the network.

[Paul Toms]

Thanks for that. Your response gave me the idea of doing a dummy read on the
socket when the TClientSocket.OnRead event fails to show up. This seems to
unblock the socket and allow subsequent messages to trigger the OnRead
events again! I can now use this as a recovery mechanism.

Another thing I've found is that if I place a delay of 200msecs between the
receipt of each message and the sending of the next message, then all OnRead
events occur correctly and there are no problems. Unfortunately this slows
down the message passing too much and so is not really feasible.

Thanks also to the others for their suggestions.

"Not Me" <no...@nowhere.com> wrote in message
news:tLea8.6756$_41.6...@news0.telusplanet.net...