🚀 go-pugleaf

Remy Lebeau (TeamB) wrote:

>>So your client is non-blocking.
> 
> That has nothing to do with it. 

Of course that was a logical conclusion. Vinicius was speaking of events.
There are only onread events in non-blocking mode.

 > The TClientSocket could be usd in blocking
> mode and still use its OnRead event.

A TClientSocket does not produce OnRead events when in blocking mode.
So how would that go ? Please show.

But actually we were talking about an IdTCPClient1.

>>If it was blocking then your client could do a ReadBufer() rigth
>>after the WriteBuffer(). At least if the server will send always after
>>it received a message from the client.
> 
> That has nothing to do with blocking vs. non-blocking.  

It has all to do with it. If it is a blocking client it will
will try to read as soon as it expects data from the server. Here just after
sending a command. When it was non-blocking it would do nothing after sendig
a command. Then if an OnRead event was triggered it would read.

 > And there is nothing
> preventing the server from sending unsolicited data that the client would
> read asynchronously from any writing. 

Well I do not know what Vinicius server is up to so that's why I asked.
Apparently you know already. Strange.

 > It all depends on the communication
> protocol that Vinicius is trying to implement for the actual data,

Indeed the actual implementation depends on the protocol. But also on the
blockingmode.

> not the
> reading/writing mode used.  

????

> The same data is read/written in either mode.

That is what we all will hope. But that was not discussed.

I'm still really amazed about this reply of you. I can hardly believe that
it did came from you. So stange.

Hans.