🚀 go-pugleaf

"Paul" <plmacca@clara.co.uk> wrote in message
news:43058ac8$1@newsgroups.borland.com...

> In examples I have had before on using BCB server and client
> components, the spawned server socket thread either waits for
> data, or transmits data.  This doesn't seem to aid an asynconous
> protocol

I have implemented asynchronous protocols using server threads.  They work
fine.

> as depending how long you are prepared to wait can delay transmitting
data.

Not necessarily.

> Does this mean the BCB components don't cater for a fully
> async messaging system?

They do, if you use them in non-blocking mode.  Then you don't need threads.
But then you can only process data as fast as you can process queued
messages.


Gambit

> I have implemented asynchronous protocols using server threads.  They work
> fine.

Is that using blocking or unblocking modes?

>> as depending how long you are prepared to wait can delay transmitting
> data.
>
> Not necessarily.
>

If using blocking mode and spawning threads, what is a reasonable "wait for 
data" time to avoid a delay in trasmitting? 10ms?
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.  Have you 
used such an approach?  Any drawbacks or advantages?

> They do, if you use them in non-blocking mode.  Then you don't need 
> threads.
> But then you can only process data as fast as you can process queued
> messages.

Just to confirm, if using non-blocking and no threads, the "on socket read" 
and "on socket write" events are async?

Last two questions (sorry to be annoying):

1)  Is it ok to instantiate the server and client components in a thread, if 
so, can it be done like this:
        Ssocket = new TServerSocket(NULL);

2)  Is there a property to restrict the number of clients the server 
component can accept, if not, whats the sequence the server events should go 
through to reject the connection?

Thanks

Paul.

"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

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
>
> 

I think I'm getting to grips with these components now.  I've focused on the 
non-blocking mode so far.  One thing I had not realised, or taken on board, 
was that the client will get an exception if it opens the socket and the 
server isn't running, so the app has to retry at regular intervals.  Also I 
found that you have to process the read event (Socket->ReceiveBuf) otherwise 
you don't get another event signaled.

There is one question though at this moment in time.  The OnWrite event, 
does that simply notify the application that it can start writing to the 
socket after connection?  I thought it would notify after every write had 
completed?  In my tests the test app trace only shows one OnWrite event (for 
both client and server).

Paul.

2005-08-27 12:17:08:0396 : Listening....
2005-08-27 12:17:27:0033 : Get Socket....
2005-08-27 12:17:27:0033 : Connected
2005-08-27 12:17:27:0033 : Accept
2005-08-27 12:17:27:0033 : Write Event - Write Ready
2005-08-27 12:17:28:0425 : Send Buffer (NOTE: server sends packet every 
10sec)
2005-08-27 12:17:38:0429 : Send Buffer
2005-08-27 12:17:48:0434 : Send Buffer
2005-08-27 12:17:58:0438 : Send Buffer
2005-08-27 12:18:08:0442 : Send Buffer
2005-08-27 12:18:18:0447 : Send Buffer
2005-08-27 12:18:28:0451 : Send Buffer
2005-08-27 12:18:38:0456 : Send Buffer
2005-08-27 12:18:48:0460 : Send Buffer
2005-08-27 12:18:58:0464 : Send Buffer
2005-08-27 12:19:01:0939 : Read Event - Data Ready (NOTE: client sending 64K 
byte array....)
2005-08-27 12:19:01:0939 : Read Event - Data Ready
2005-08-27 12:19:01:0939 : Read Event - Data Ready
2005-08-27 12:19:01:0939 : Read Event - Data Ready
2005-08-27 12:19:01:0949 : Read Event - Data Ready
2005-08-27 12:19:01:0949 : Read Event - Data Ready
2005-08-27 12:19:01:0949 : Read Event - Data Ready
2005-08-27 12:19:01:0949 : Read Event - Data Ready
2005-08-27 12:19:08:0469 : Send Buffer

Paul wrote:
   One thing I had not realised, or taken on board,
> was that the client will get an exception if it opens the socket and the 
> server isn't running, so the app has to retry at regular intervals. 

Errormessages are different with a nonexistent host or nonexistent server.

> Also I 
> found that you have to process the read event (Socket->ReceiveBuf) otherwise 
> you don't get another event signaled.

You have to use Socket->ReadBuf() for all the bytes indicated by
Socket->ReceiveLength().

> There is one question though at this moment in time.  The OnWrite event, 
> does that simply notify the application that it can start writing to the 
> socket after connection?  

Everytime that SendBuf() returns and did not write all the bytes you could
wait for an OnWrite event. This indicates that a successive SendBuf() could
be done then.

Hans.