🚀 go-pugleaf

Thanks very much for your responses, they are a great help.

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:430a07da$1@newsgroups.borland.com...
>
> "Paul" <plmacca@clara.co.uk> wrote in message
> news:4306da89@newsgroups.borland.com...
>
>> Is that using blocking or unblocking modes?
>
> Both.
>
>> If using blocking mode and spawning threads, what is a
>> reasonable "wait for data" time to avoid a delay in trasmitting?
>> 10ms?
>
> That depends on how often you need to send data.  Obviously, the more 
> often
> you need to send, the smaller the delay should be.
>
>> I have heard from other engineers (not using BCB), that they
>> have written async protocols by having a socket for Rx and a
>> socket for Tx.
>
> Yes, you can send the data from a different thread than the one that is
> reading.  A blocking socket works just fine when used in multiple threads,
> just as long as the threads don't try to both read from or both write to 
> the
> same socket at the same time.  But one thread can read while another 
> thread
> is writing.
>
> That is one way to do it.  But it is not the only way.
>
>> Have you used such an approach?
>
> Yes, I have, and other approaches as well.  Which approach you decide to 
> use
> really comes down to what your overall code design is.  Some approaches 
> are
> better suited for some kinds of designs, and other approaches for other
> deisgns.
>
>> Just to confirm, if using non-blocking and no threads, the "on
>> socket read" and "on socket write" events are async?
>
> Yes.  They are triggered by messages that are posted to the message queue 
> of
> the thread that owns the socket.
>
>> 1)  Is it ok to instantiate the server and client components in a thread
>
> Yes.
>
>> 2)  Is there a property to restrict the number of clients the server
>> component can accept
>
> TServerSocket does not implement that functionality.  You would have to
> implement it yourself manually.  Otherwise, you will have to switch to a
> different component that has that functionality natively implemented.
>
>> if not, whats the sequence the server events should go through to
>> reject the connection?
>
> Simply disconnect the new sockets in the OnAccept event when you already
> have too many connected
>
>
> Gambit
>
>