Can anyone tell me how to go about setting up a conversation between a
client and server using the same socket connection?

i.e.:  I want to be able to initiate a conversation from either side without
causing a problem.  One minute the server might need to ask the client a
question and the very next minute the client ask the server a question.
Both would need to be listening for the start of a conversation and at the
same time be ready to respond to the others question.

Can this be done?

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649

Hi

Well the the main difference between a Server and a Client is that the Server
listens for
incoming connections, and controls all these connections. The Client can only
connect to a
Server and not listen for connections itself.

Once you have a Server -- Client connection both can send data to one and other
when ever
they damn well please. Only when connecting the client needs to initiate the
connection.
You can always put a Client and Server component on the same form, so that it
doesn matter
which side connects first! Sound more like peer2peer to me :)

Hope this short description helps!

Cheers

Ido

I do appreciate your answer, but it doesn't help much.  I understand how to
initiate the conversation but I don't understand how both can listen at
once.  There seems to have to be a protocol between the two systems as far
as the conversation goes.  How can both systems sit there and listen, but
still be able to talk at the same time?

This might be a bad example, but it does provide a little insight as to why
I am asking the question.  If you sniff a network connection while sending
and receiving messages on ICQ, they all seem to originate from the same
port.  Even when the server sends my ICQ program a message, it comes over
the same port.  Now the client ICQ program can't know whether it will be
needing to send or to receive a message at any given point in time, so it
has to be doing both.  So if I click the send button, it has to stop
listening on that port and send data to the server.  Then at the next
moment, switch back to listening...

Am I missing something?

Thanks,

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649
"Ido de Lepper" <ilep...@fbk.eur.nl> wrote in message
news:3C0F3123.A7F45BF8@fbk.eur.nl...

mm, ok I get the confussion.

There are 2 things that are happening, 1) connecting, and 2) communication

1)Connecting
-Server listens on a port for incoming clients
-The client connects to the server IP + server Port
The client is now connected to the server and communication can start.

2)Communication between Server&Client and Client&Server
-The server can send info to the client, eg WriteInteger(1); WriteString('hello
to you client')
-The client receives the number 1 and the string, and can take action according
to the number
it receives, eg 1 = hello, 2 = name , 3 = chat message, etc
-The client then sends WriteInteger(2), WriteString('my name is ...'), to let
the server know what the clients
name is.
This is a small example of a communication protocol that could be possible.

Also take in mind that after the Client has connected to the Server either party
(client or server) can send
data to one and other. So the client doesnt have to wait for data from the
server to react, but can send whenever
he want to. You just need some communication rules so that the server and client
dont start japping together.
Just like in real life.

Hope this is better?

Cheers

Ido

ps, about the icq example, icq is peer 2 peer, so each icq application is a
Server + Client all
rolled into one. When sending data from your icq to a buddy you connect to the
buddys local icq server.
But if he is behind a firewall he cant start a server so everything goes via the
main ICQ server.
If your buddy sends you something he connects to your local icq server with his
icq client.
Try to look up some info about peer2peer communication!

Cheers

will do on the Peer-to-Peer stuff, but I'll give you my problem in a
nutshell.

On the server after the client connects, I have to get the server to wait
for a string from the client to get an ID.  When I issue the command.

Athread.connection.readln;

The entire thread stops until that client sends something.  That means that
while the server is waiting for something, it can not send anything because
there is no means of sending a response back until the current process is
finished.

Thanks,

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649
"Ido de Lepper" <ilep...@fbk.eur.nl> wrote in message
news:3C0F8452.AC22DEDA@fbk.eur.nl...

Also I could be wrong, but I think that ICQ attaches to a server and
forwards your messages through that server out to the member you wish to
communicate with.  All messages go to the server IP not to individual IP
addresses.  If that were the case if I had 50 people in my icq list, I would
have to have 50 different connections to manage versus 1 with the ICQ
server.

I am pretty sure thats how it works anyway...

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649
"Ido de Lepper" <ilep...@fbk.eur.nl> wrote in message
news:3C0F8452.AC22DEDA@fbk.eur.nl...

Peer-to-Peer,

I have been reading up on Peer-to-Peer since you suggested it was the
possible solution, but unless I am missing something, it is simply a
Protocol itself, and doesn't really change my question.  Even using
Peer-to-Peer, you still seem to be governed by the laws of TCP/IP which is
one machine is the server, the other is the client and they both carry on
some supported conversation between the two systems over a connection
through a port.

So I guess my question stays:  How do they do it?  How do they have a
process that is listening on a port for some communication with the client,
but at the same time be able to send data through that same link to the
client?

Thanks,

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649
"Ido de Lepper" <ilep...@fbk.eur.nl> wrote in message
news:3C0F8452.AC22DEDA@fbk.eur.nl...

Use non-blocking sockets opened for reading and writing.  Investigate ICS components.

news:3c0f8e42_2@dnews...

There is no biggie problem.  It is perfectly feasible for one thread to
write to the client while another is blocked waiting.  I do this all the
time in my servers - I can type 'DIR' in both client & server terminal
windows, press return on both & see a listing of each other's directory
appear 'simultaneously'.

You just need a suitable protocol and threads.  Or, if you're really
desperate/suicidal, a non-blocking server and monster state machine.

Rgds,
Martin

So its ok then to have 2 different connections to the server for each
client?  One to read and the other to write.  This seems the simplest
approach but I wanted to make sure it was the best approach and I wasn't
wasting resources.  I have this approach working but after seeing what ICQ
was doing, it made me wonder if I was missing something.

Thanks,

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649

news:3c0fc2d3_2@dnews...

Glenn Hancock schrieb:

Of course you can send while waiting for the ReadLn to complete. Simply
use another thread to send from. Usually the Peer thread created by the
Indy server automatically on accept is used to ReadLn. In that case,
simply call WriteLn from the main thread context or from a third one.

-Michael

Glenn Hancock schrieb:

No.

One client - one connection. One server - multiple connections.

From the POV of one side, reading and writing at the same time using the
same connection is not not only possible but the usual thing.

Compare with _one_ telephone line where both partners speak
simultaneously. If you concentrate (i. e. if speaking is easy (or if you
use different threads for speaking and listening)) you even can
understand what the other one says.

-Michael

Ok,  Just so I understand...

I have 1 client and 1 server.  The client kicks off a connection to the
server.  When it does the server is looking for a response from the client
telling it what it wants to do.  However,   whenever you issue a readln
command it causes the entire process to wait until a response is sent from
the client.  So, instead of issuing a readln, I thread another process and
pass it the Athread.connection process and let it wait for a response from
the client.  Then, it will be handling all requests from the client.

Now, the process that spawned the thread to communicate with the client,
begins to loop and look for information in which it needs to share with the
client such as new files that have arrived and so on.  As soon as it sees
something, it shoots off a writeln to the client process on the other end.
Now I have two conversations going on at once.  I am also assuming that in
order for this to work, I have to spawn off a thread on the client as well
to handle its writeln processes to keep them seperate from the readln.

Here is where I am confused.  With a single writeln from the client to the
server, the server will start responding.  These responses go back to the
client in a form of writeln.  Now I have a single connection on the client
already that has two processes listening for incoming communications.  How
would the client component know which process needs to handle the incoming
information from the server.

The more I go into this, the more I find it impossible to do cleanly.  Maybe
someone could provide a good book on the subject or a better explanation
than "Yeah you can do it".

Thanks,

--
Glenn Hancock
SofTek Software Int'l Inc.
www.softeksoftware.com
ghanc...@softeksoftware.com
770-957-5649

news:3c0ff6ad_1@dnews...

What you want CAN be done with INDY and blocking sockets, by creating threads and  using the created thread on each end to perform
the opposite function with the same socket ( the sockets are opened for both reading and writing).

With non-blocking sockets that are opened for reading and writing, you receive an event when there is something to read, and an
event (if you want) when a write is finished.  What the program (either the Server or Client) do when it is not processing those
events is up to the programmer.

If you have app/server where logic dictates that data flows in sequence:

  a-->b
  b-->a
  a-->b
  b-->a

Then blocking sockets make it slightly easier to code.

If you have an app/server where data can flow in either direction at any time, or maybe one direction mutiple times, then I prefer
non-blocking sockets, use a case statement to determine what to do with received data, and don't have to resort to multi-threading
to accomplish my logic.

Perfectly describes non-blocking sockets.