Board index » delphi » Help with TClientSocket & TServerSocket

Help with TClientSocket & TServerSocket

I have inherited a system that uses these two components. The system seems
to work for the most part but is having a proplem periodically locking up.
It is a time and attendance system made up of two programs. A server program
that "listens" for swipes that are collected by the client program. I do not
understand much about sockets or I perhaps would have this solved by now.
Perhaps one of the pros lurking the newsgroup can help....

What I know is that it is setup as NonBlocking. What appears to happen when
it locks up is that the write event on the client socket fires but then the
application goes to lunch. Again, this is not everytime, although it seems
to be getting worse. There is one swipe server and seven swipe collectors
(clients). The clients are scattered over a WAN.

I have no clue if this is enough info for someone to suggest where to look
for problems. If not, please tell me what further info is needed.

Thank you!!!

Eric

 

Re:Help with TClientSocket & TServerSocket


Quote
>What I know is that it is setup as NonBlocking. What appears to happen when
>it locks up is that the write event on the client socket fires but then the
>application goes to lunch. Again, this is not everytime, although it seems
>to be getting worse. There is one swipe server and seven swipe collectors
>(clients). The clients are scattered over a WAN.

>I have no clue if this is enough info for someone to suggest where to look
>for problems. If not, please tell me what further info is needed.

What is your client actually doing, i.e. sending loads of data,
receiving loads of data, etc.?
Is the network known to be slow?
Does the app recover (In OnError called?) or is it really more a crash
than a freeze?
Does the server disconnect the client when the freeze occurs?
Does the server continue to work normally?

Judging from the info, I could imagine that you are trying to
send/receive too much data.
OnWrite, normally, should only fire at the beginning of a connection.
If it fires afterwards, the write buffer has been full previously -
this obviously indicates that the traffic is heavy.
Also, the GUI might freeze due to a load of OnRead events being fired
(or due to code in the OnRead event) that prevents the app from
processing the normal GUI related messages normally.

Andy

Re:Help with TClientSocket & TServerSocket


See comments to individual questions below...

Quote
"Andy M." <[no-spam]andy.mail...@gmx.net> wrote in message

news:k4f9ev44hukofhp0rmeng1k8j9s0d2r8js@4ax.com...

Quote
> >What I know is that it is setup as NonBlocking. What appears to happen
when
> >it locks up is that the write event on the client socket fires but then
the
> >application goes to lunch. Again, this is not everytime, although it
seems
> >to be getting worse. There is one swipe server and seven swipe collectors
> >(clients). The clients are scattered over a WAN.

> >I have no clue if this is enough info for someone to suggest where to
look
> >for problems. If not, please tell me what further info is needed.

> What is your client actually doing, i.e. sending loads of data,
> receiving loads of data, etc.?

        The client sends a total of 27 characters in order to identify the
employee who is clocking in/out. The server processes the data and then
sends a 105 character message back to the client for display to the
employee.

Quote
> Is the network known to be slow?

        No.

Quote
> Does the app recover (In OnError called?) or is it really more a crash
> than a freeze?

        It does not recover and from what I can tell, OnError is never
called. It seems that the applicationn itself is frozen. I can Ctrl-Alt-Del
and kill the program and bring it right back up again.

Quote
> Does the server disconnect the client when the freeze occurs?

        Not sure on this one, I do not get a Disconnect event on the Client
side....have not ventured into the server side yet...

Quote
> Does the server continue to work normally?

        Yes. The other clients continue to be serviced by the server.

Quote

> Judging from the info, I could imagine that you are trying to
> send/receive too much data.

        Sending 27 characters, receiving 105 Characters. Too much?

Quote
> OnWrite, normally, should only fire at the beginning of a connection.
> If it fires afterwards, the write buffer has been full previously -
> this obviously indicates that the traffic is heavy.
> Also, the GUI might freeze due to a load of OnRead events being fired
> (or due to code in the OnRead event) that prevents the app from
> processing the normal GUI related messages normally.

       Once the app freezes, it never comes back. I have allowed it to wait
for up to 2 hours. I have littered the client screen with labels so that I
get feedback on everything that happens in the course of the transaction. It
always freezes after a SendText command. It is as if it sends the message
and then goes into a state of waiting.
Quote
> Andy

Re:Help with TClientSocket & TServerSocket


Quote
>> Does the server disconnect the client when the freeze occurs?
>        Not sure on this one, I do not get a Disconnect event on the Client
>side....have not ventured into the server side yet...

Well, probably doesn't matter in this case.
But if the server does disconnect the client, it most probably was due
to an error that the socket raised.

Quote
>        Sending 27 characters, receiving 105 Characters. Too much?

Certainly not, no...

Quote
>       Once the app freezes, it never comes back. I have allowed it to wait
>for up to 2 hours. I have littered the client screen with labels so that I
>get feedback on everything that happens in the course of the transaction. It
>always freezes after a SendText command. It is as if it sends the message
>and then goes into a state of waiting.

Since the socket is non-blocking, this cannot happen, i.e. the socket
call itself will *not* block.
But, programs with non-blocking sockets normally resort to using a
state-machine somewhere to wait for things to happen, maybe your app
is stuck on some waiting loop there.

Another problem might arise, if your program sends the data and then
waits for the answer. Since you are sending a very small packet of
data, TCP might buffer it in order to send it together with the next
chunk of data (that's called the Nagle Algortihm) - which never comes
of course. Now your program sits waiting for the server reply, but the
server hasn't even got the data yet.
If your app *does* wait for the reply after sending it, you might want
to  check whether the server app actually received the data.

Apart from that, I don't believe in any winsock related problem but
more in a bug in the app  itself. Since you are really doing nothing
new or uncommon...

I suspect, you can't post any related source codes?

Andy

Re:Help with TClientSocket & TServerSocket


I am willing to post the code...if you are willing to take a look. I have
really littered it with status messages, would you prefer I leave my junk in
there or clean it up and post the code as it was when I started working with
it?

Thanks for your quick response thus far!!!

Eric

Quote
"Andy M." <[no-spam]andy.mail...@gmx.net> wrote in message

news:ltl9evg8ilk7h0gd7opkijhp5pi02ag4bb@4ax.com...
Quote
> >> Does the server disconnect the client when the freeze occurs?
> >        Not sure on this one, I do not get a Disconnect event on the
Client
> >side....have not ventured into the server side yet...

> Well, probably doesn't matter in this case.
> But if the server does disconnect the client, it most probably was due
> to an error that the socket raised.

> >        Sending 27 characters, receiving 105 Characters. Too much?

> Certainly not, no...

> >       Once the app freezes, it never comes back. I have allowed it to
wait
> >for up to 2 hours. I have littered the client screen with labels so that
I
> >get feedback on everything that happens in the course of the transaction.
It
> >always freezes after a SendText command. It is as if it sends the message
> >and then goes into a state of waiting.

> Since the socket is non-blocking, this cannot happen, i.e. the socket
> call itself will *not* block.
> But, programs with non-blocking sockets normally resort to using a
> state-machine somewhere to wait for things to happen, maybe your app
> is stuck on some waiting loop there.

> Another problem might arise, if your program sends the data and then
> waits for the answer. Since you are sending a very small packet of
> data, TCP might buffer it in order to send it together with the next
> chunk of data (that's called the Nagle Algortihm) - which never comes
> of course. Now your program sits waiting for the server reply, but the
> server hasn't even got the data yet.
> If your app *does* wait for the reply after sending it, you might want
> to  check whether the server app actually received the data.

> Apart from that, I don't believe in any winsock related problem but
> more in a bug in the app  itself. Since you are really doing nothing
> new or uncommon...

> I suspect, you can't post any related source codes?

> Andy

Re:Help with TClientSocket & TServerSocket


See the mail I sent you.

Andy

Other Threads