Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: [ports] [tcp] Detecting peer closing connection

From: petr:krenzelok:trz:cz at: 21-Nov-2003 14:08

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-