🚀 go-pugleaf

"Stefano Bonifazi" <stefboombastic@email.it> wrote in message
news:41fe906e@newsgroups.borland.com...

> From a tutorial on the borland site ( Creating a threaded socket
> server and client application ) I see I should use the TWinSocketStream'
> and create my own Threads and do all the stuff in the their
> ClientExecute method...

That is one way to handle it.

> From the BCB Help I read: "The thread for each connection generates
> OnClientRead or OnClientWrite events when the server socket needs
> to read or write."

That is only true if you do not write your own thread class.  The default
TServerClientThread.ClientExecute() implementation triggers the events.  By
overriding ClientExecute() with your own implementation, you lose those
events unless you trigger them manually, which you usually don't need to do
if you are implementing ClientExecute() yourself anyway.

> I should use the OnClientWrite when I need to write to the clients.

That is not correct.  Just like with non-blocking mode, OnClientWrite is
only used to indicate that a socket has become writable, not that you should
be doing all of your writing from there.

> Finally I learnt from  a Mr Gambit's previous answer that I could easily
> reuse the code of "stNonBlocking" servers with "stThreadBlocking"
> ones calling Application->ProcessMessages() within the read loop
> (but what about the sending stuff then?)

I never said to use ProcessMessages() from a thread.  I did say, however,
that non-blocking code could be written in a similar fashion to blocking
code, as long as you taking blocking situations into account properly.

> But my confusion starts from how they work and when I should
> use a "stThreadBlocking" instead of "stNonBlocking" server.

That is entirely up to you and your actual needs.

> "When ServerType is stNonBlocking, all client connections are handled
> in a single execution thread by default", but does not this mean that all
> other sockets have to wait until the server finishes to execute the
> OnClientRead of the current socket?

Yes.

>  If so why not  this kind of server is called "blocking" instead?

Because it is not blocking.  "Blocking" vs. "non-blocking" refers to the
socket itself, not the server component managing the socket.  In blocking
mode, socket operations "block" the calling code until the socket operation
is finished.  In "non-blocking" mode, socket operations return control to
the calling code as soon as possible and then trigger asynchronous events
when the operations actually finish.

> If I need a server that sends big files to many clients what kind of
> server should I use?

It does not matter.  Both modes can handle that, as long as you code for it
properly.

> If the server should send big files to few clients?

Again, the mode does not matter either way.

> And many small packets to many clients?

Again, the mode does not matter.

> Why should I use the threaded way for a TClientSocket?

Easier coding of the socket operations (your code does not have to be
separated amongst multiple event handlers), simultaneous processing of
multiple clients at a time, etc.

> To lighten the program's main thread burden?

That is another reason, yes.


Gambit