Board index » delphi » About the Indy Chat example

About the Indy Chat example


2003-06-29 10:09:10 PM
delphi204
Hi!
I want to make a simple chat program using Indy TCP components.
I have seen the Indy chat Demo, but I have a question about the Client
program.
It seems that the Client have to "read" every half-second to know if
something is "arriving" from the Server. The demo program use a Timer for
this, and sometimes the program freezes, even with the AntiFreeze component.
Is there another way to read the messages from the Server, without using a
Timer?
I think I should use a TCPServer component on the Client application, so the
Server app can send messages to the Clien app, but... how can I know the IP
of the client?
For example, UDP components has the following:
UDPServerUDPRead(Sender: TObject; AData: TStream; ABinding:
TIdSocketHandle);
"ABinding.PeerIP" and "ABinding.PeerPort" gives you the IP of the connected
"person", but with TCPServer or TCPClient doesn't have it.
Please, help!
and forgive my poor english! I am from Spain
 
 

Re:About the Indy Chat example

Quote
Please, help!
and forgive my poor english! I am from Spain

Your English is far better than my Spanish which, in turn, is better than
the Chat Demo. it is about time this demo was retired & replaced with
something more appropriate to demonstrating how to use the Indy blocking
components.
Use the Indy client components in a read thread, either TThread or one of
the Indy descendants. A 'plain' TThread descendant works fine. With all
the conect/waitForData action taking place in the read thread, there is no
problem with waiting for anything - the main VCL thread remains responsive &
available for what it is supposed to do - handle messages in event handlers.
Writing to the component from the main thread, eg, to send some lines of
input text from a memo, is no problem - a direct call to the write methods
of the component is fine. Displaying data is another matter. Use
TidNotify, postMessage or, if desperate, synchronize, to communicate read
buffers to the main thread for display.
Rgds,
Martin
 

Re:About the Indy Chat example

Hi, Martin...
Thanks you. Well, I fix the problem adding a TCPServer to the Client app.
Why? Well, the Client app is going to receive only messages from 1 person,
not more.
Server-side works fine, and it can receive messages from multiple clients,
but each cliente only receiver messages from me.
But know, I have another question.
If I want to send a file to one client... How can he know that the arriving
message is a file instead of text?
Have I to send it to another port? or to another TCPServer component?
Can I send/receive messages while the file is transfering?
Thanks for you help!
"Martin James" <XXXX@XXXXX.COM>escribi?en el mensaje
Quote

>Please, help!
>and forgive my poor english! I am from Spain
>

Your English is far better than my Spanish which, in turn, is better than
the Chat Demo. it is about time this demo was retired & replaced with
something more appropriate to demonstrating how to use the Indy blocking
components.

Use the Indy client components in a read thread, either TThread or one of
the Indy descendants. A 'plain' TThread descendant works fine. With all
the conect/waitForData action taking place in the read thread, there is no
problem with waiting for anything - the main VCL thread remains responsive
&
available for what it is supposed to do - handle messages in event
handlers.

Writing to the component from the main thread, eg, to send some lines of
input text from a memo, is no problem - a direct call to the write methods
of the component is fine. Displaying data is another matter. Use
TidNotify, postMessage or, if desperate, synchronize, to communicate read
buffers to the main thread for display.

Rgds,
Martin



 

Re:About the Indy Chat example

Check out the IdTCPDemo , its a chat program but seems to be a lot better
then the "Chat Demo" :)
James..
"Santy Concepción" <XXXX@XXXXX.COM>writes
Quote
Hi!

I want to make a simple chat program using Indy TCP components.

I have seen the Indy chat Demo, but I have a question about the Client
program.
It seems that the Client have to "read" every half-second to know if
something is "arriving" from the Server. The demo program use a Timer for
this, and sometimes the program freezes, even with the AntiFreeze
component.

Is there another way to read the messages from the Server, without using a
Timer?
I think I should use a TCPServer component on the Client application, so
the
Server app can send messages to the Clien app, but... how can I know the
IP
of the client?

For example, UDP components has the following:

UDPServerUDPRead(Sender: TObject; AData: TStream; ABinding:
TIdSocketHandle);

"ABinding.PeerIP" and "ABinding.PeerPort" gives you the IP of the
connected
"person", but with TCPServer or TCPClient doesn't have it.


Please, help!
and forgive my poor english! I am from Spain


 

Re:About the Indy Chat example

You will have to come up with your own protocol to do this, it is easy to do
with blocking sockets.
You need to send commands so the client/server knows what is going to
happen.
Quote
If I want to send a file to one client... How can he know that the
arriving
message is a file instead of text?
Have I to send it to another port? or to another TCPServer component?
Can I send/receive messages while the file is transfering?
You would be able to write while the readstream is transfering your file.
You could spawn another thread/connection to handle the file transfer as
well.
 

Re:About the Indy Chat example

Quote
Use the Indy client components in a read thread
Dear Martin,
I could use a little help concerning this read thread, you described. I
have tried to create such a thread and - since I am not very good at
Delphi programming - failed. Maybe you or another expert can contribute
the sourcecode for such a thread.
What I am trying to do is to build a simple chat application like the one
included in the indy demos, but I intend to avoid the timer by using
such a read thread. The problem I am facing is that there is no
termination string and furthermore no timeout and therefore 'ReadLn' is
not a suitable function.
Can anyone help? Please!
--- posted by geoForum on www.delphiedintorni.it