Gabriele Santilli wrote:
>Hello all,
>
> while doing some tests I and Romano have discovered a strange
>behavior in REBOL TCP ports. I thought that, when the peer closes
>the TCP connection, you got NONE returned by COPY on the TCP port;
>however, it is not always so.
>
>We have discovered that, if there's data in the port output
>buffer, and the port is in binary mode, when the peer closes teh
>connection you'll get an empty binary (#{}) instead of NONE as the
>result of COPY.
>
>This way it becomes difficult to know that the connection was
>closed (because empty data also means "no new data available"). If
>you are using PORT/AWAKE, however, you can assume that an empty
>result is equivalent to NONE, since the AWAKE won't be called if
>there's no new data available.
>
>
>
Hello Gabriele,
I found one earlier post by Holger, well .... I miss his educative
posts so much :-) I don't know if you can find any answers related to
your problem there, but maybe someone other will find it quite educative:
http://www.escribe.com/internet/rebol/m15313.html
>I think this issue is the reason why some people (Gregg?) had
>problems with async:// when peer closed the connection. I'll fix
>my version of async:// soon (but becomes a bit complicated because
>of the WRITE async mode).
>
>
>
As for ports bug in general, I reported some strange behavior some time
ago. Win98 scenario, Rebol (don't remember what version), and our device
(8bit chip ethernet + tcp implementation). When we opened port in
open/direct/no-wait, followed by following loop: while [wait port data:
copy port][...], it simply escaped the loop and in Ethereal we could see
PC lowered tcp window to 0 and PC sent RST packet then. Yes, we could
tell that 8bit Scenix chip tcp implementation could be flawed, but the
case was solved by simple adding /binary refinement - so - should
open/direct/no-wait and open/direct/no-wait/binary behave differently?
The rest of the code stayed unchanged. Why without /binary refinement
wait loop was escaped? Could it be related to none vs #{} issue you
describe? The bug was not confirmed by RT and who knows if it is even a
bug, although it seems so. I would have to check with latest Rebol
releases if it is still the same ...
Cheers,
-pekr-
>(BTW, I found the strange behavior, and Romano found out the
>reason, so all the credit goes to him. :)
>
>Regards,
> Gabriele.
>
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
