Board index » delphi » How TIdTCPClient get random information from Server?

How TIdTCPClient get random information from Server?


2004-07-23 11:29:29 AM
delphi117
I know the Indy way to do net work is:
Connect to server
Send/Read Data
Disconnect from Server
but if I don't know when server would return data to me,because Indy is
blocking and not event driven,How could I know that the server has send
unexpected data to me??Am I clear enough? In normal winsock
programming,I connected to server,send data to server,and if server send
data back to me ,there is an event fired up,which I know I should do
something about that data.but in indy,It seems like I should exactlly
know when the server send data back to me,but how about the conditions
that I am not sure when server would send data to me? thanks.
 
 

Re:How TIdTCPClient get random information from Server?

"John Smith" <XXXX@XXXXX.COM>writes
Quote
I know the Indy way to do net work is:
Connect to server
Send/Read Data
Disconnect from Server
That is not only the Indy way - that is the TCP/IP way in general.
Quote
but if I don't know when server would return data to me,
because Indy is blocking and not event driven,How could
I know that the server has send unexpected data to me??
Do the reading in a thread or timer. In the case of the latter, you can
specifying a reading timeout so the reading does not block indefinately.
Using a separate thread is better, though.
Quote
In normal winsock programming,I connected to server,send
data to server,and if server send data back to me ,there is an
event fired up,
Only if you are using the socket in non-blocking mode. Which is not a
standard mode, BTW. It is a Microsoft-specific mode that was introduced in
Windows 3.1, when threads were not supported yet at the time. Most
non-Microsoft systems use blocking sockets only.
Gambit
 

Re:How TIdTCPClient get random information from Server?

That is not only the Indy way - that is the TCP/IP way in general.
Do the reading in a thread or timer. In the case of the latter, you
can specifying a reading timeout so the reading does not block
indefinately. Using a separate thread is better, though.
Only if you are using the socket in non-blocking mode. Which is not a
standard mode, BTW. It is a Microsoft-specific mode that was
introduced in Windows 3.1, when threads were not supported yet at the
time. Most non-Microsoft systems use blocking sockets only.
Thank you for your answer,But I was confused,I don't know how to do read
in another thread or timer,Could you please show me some code?thank you.
 

Re:How TIdTCPClient get random information from Server?

Quote

Thank you for your answer,But I was confused,I don't know how to do read
in another thread or timer,
Create a thread unit with the IDE. Add a TidTCPClient field to the thread.
Create a TidTCPClient instance in the thread constructor or at th etop of
the 'execute' method. In the body of 'execute' method, loop around a call
the TidTCPClient read methods to get your 'random information'. If you need
to access any VCL methods from the thread, use TThread.synchronize', the
sendMessage/postMessageAPIs or the Indy TidSync/TidNotify methods.
Could you please show me some code?thank you.
Have a go - you will learn more that way.
Rgds,
Martin
 

Re:How TIdTCPClient get random information from Server?

Thank you for your help,But our device can only accept one tcp
connection,Does it mean I have to use one thread to do write operation
and another thread to do read operation?How about two threads want to
connect to the device in the same time?I mean what if the read operation
and write operation are occured in random time.In event driven
architecture,I can do write operation in write event,and do read
operation in read event(Buffer full),but I don't know how to do
that in indy.
 

Re:How TIdTCPClient get random information from Server?

John Smith writes:
Quote

Thank you for your help,But our device can only accept one tcp
connection,Does it mean I have to use one thread to do write operation
and another thread to do read operation?How about two threads want to
connect to the device in the same time?I mean what if the read
operation and write operation are occured in random time.In event
driven architecture,I can do write operation in write event,and do
read operation in read event(Buffer full),but I don't know how to do
that in indy.
Hi John,
While your thread is waiting on a Read, it is possible to write to that
same socket from another thread. that is what the If you always write
from the same external thread, I think it is thread safe, too. This
lets you constantly wait for random information from the socket and
still be able to write to it any time you want. And you only need the
single TCP connection.
--
Regards,
Bruce McGee
Glooscap Software
 

Re:How TIdTCPClient get random information from Server?

Just remember to use the DisconnectSocket instead of Disconnect on the
Connection object when doing a manual disconnect, because Disconnect method
is not threadsafe (at least in Indy9).
 

Re:How TIdTCPClient get random information from Server?

Quote
Hi John,

While your thread is waiting on a Read, it is possible to write to that
same socket from another thread. that is what the If you always write
from the same external thread, I think it is thread safe, too. This
lets you constantly wait for random information from the socket and
still be able to write to it any time you want. And you only need the
single TCP connection.

I think i should make two thread,one for write and another for read,As
you said,I should pass the socket as thread parmaeter to each thread?I
thought I shoud do connect/disconnect in the thread body.so if one
thread have connceted my device,another thread can not connect into it
'cause it can only accept one connection.Sorry i was confused,I wonder
how to use same socket in two threads?thank you. May be I should create
TIdTCPClient object out of thread?then in each thread I check if it was
connected first,if not,do connect,or do read/write operation.and don't
do disconnect in thread?Someone suggests to always keep the
connection,but i don't think it is a good idea.