🚀 go-pugleaf

Remy Lebeau (TeamB) wrote:

> In TServerSocket, if you do not provide a custom TServerClientThread
> descendant class to handle connections, then OnClientRead is still triggered
> even in blocking mode.

And what would one do with them ?

>>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.
> 
> That does not mean that a non-blocking socket can't also read immediately
> after writting, because it can. 

Ok. It can. But that makes no sense for me. If I choose for a
non-blocking socket then that is for a non blocking application.
If I want my application to block, that is do a read right after
a write, then I choose a blocking socket.

 > You are getting too hung up on the presense
> of event handlers and not focusing on what the socket can actually do in
> either mode.  

Indeed. It was not my intention to discuss all the possibilities
of socketprogramming. Instead I tried to find out what kind of
server/client Vin�cius wanted to make.

 > You can program a non-blocking socket in exactly the same
> manner as a blocking socket, even to go as far as getting rid of the event
> handlers.  All you have to do is take into account that operations may block
> occasionally, but that is easily handled by simply checking for
> WSAEWOULDBLOCK when non-blocking operations report errors.

Thank you for making me more aware of that.

>>When it was non-blocking it would do nothing after sendig a command.
>  
> Yes, it can.  

As said: that makes no sence for me if it does.

> I've even posted examples of exactly that in the past.

If I remember well that was in an OnRead event where you read
more than ReceiveLength() indicated. I commented then that
you were violating the event driven nature. Sadly you did
not comment then.

>>Well I do not know what Vinicius server is up to so that's
>>why I asked. Apparently you know already. Strange.
> 
> I know exactly what Vinicius is asking for, because he stated as much in his
> original message.  It has nothing to do with what the server is doing.  He
> simply wanted to implement an OnExecute approach to client-side reading. 

Strange. How I see it: All Vin�cius wanted to know was how to
write and read. Any approach was welcome.

>>Indeed the actual implementation depends on the protocol. But
>>also on the blockingmode.
> 
> No, it does not.  Blocking vs. non-blocking does not change how the data can
> be sent/read. 

It is not about /can/ but about how one would do it and especialy
/when/. It is not just only about code for sending and receiving data.
The programflow is completely different if a client does a read
right after sending a command to the server or that it does nothing
and waits for an event.

> Both modes can be programmed in exactly the same manner.  The
> events that can be triggered during non-blocking mode are NOT a requirement.

Ok. Nice to know. I have to think about that further. Maybe I can
use it in an existing application that uses a non-blocking
TClientSocket and is completely event driven. There are some situations
where I like to read rigth after having a command sent. It makes the
programflow/coding so much easier. The problem then is that the server,
can also send, at any moment, unasked data so to be sure I still have to
decode where the received data is for. That would make the code
complicated again.

Hans.