🚀 go-pugleaf

Hans Galema wrote

> As far as I see it the code will do in non-blocking mode.
>
> What makes you say that it does not work for non-blocking ?

I just tried to send the data (wich works perfectly with
ctBlocking), but unfortunately Client's OnError() is triggered
when ctNonBlocking (haven't checked what error). I also can see
that 'some' portion of TMemoryStream *is* actually sent to Server
but not the WHOLE content as I (normaly) wanted.

> I have some remarks:
>
> - Even if you try to send 4 bytes with SendBuf() then you
> have to check that all 4 bytes have been sent. At the moment
> you only check for -1.

Yes, I agree, and I actually think that's the problem. I have some
Remy's answer to similar Q and I'm trying to 'find myself' in it:

  "the client-side code you currently have will not work
  as-is if you are using non-blocking mode, because you
  are not checking for when SendBuffer() fails to send
  any data due to blocking.  When that happens, you have
  to wait for the OnWrite event to trigger before you can
  send more data again.  Otherwise, you are going to corrupt
  your data stream because not all of the data will be sent
  correctly."


> - I'm not quite sure if -1 means an error. It means that
> nothing was written. So you could continue the loop.

Not sure either, but I'll bookmark this just to check.

> - For every portion that you transfer to your buffer
> you send the size to the server to. That is no good. The server
> will only be interested in the size of the file. So the
> client should only once send a 4 bytes size.

Uh, I hardly managed to get this to work and now I need
the code reconstruction... Ok, I accept the remark

> > const int BUFFER_SIZE = 100;
>
> Much to small: take 5000 or more.

Ok.

> I copied this from a filesendclient I regularly use [...]

I appreciate it very much.

> I now see that I never check for these 4 bytes!! <g>

Rules are only made for beginners :)



Best regards,
Vladimir Stefanovic