[REBOL] Re: possible rebol tcp open bug ...
From: ptretter::charter::net at: 10-Aug-2002 13:54
Not sure what your doing Petr but make sure you checking for "none" when
using /no-wait refinement and not 'none. "none" will be sent anytime there
is no data. I find it to work flawlessly and I do alot of network port
communications with no-wait and I usually use copy on direct/no-wait ports
and 'first on non no-wait ports. I also use Ethereal for checking the
communications. You can actually check to see if the other side closes the
port connection and get notified immediatly if this happens. Here is what I
put in my REBOL leaning folder on IOS that I found:
open?: func [port][either port/state/flags = 1024 [false][true]]
The above function cannnot tell if the port is actually active or whether
the remote client has closed the socket.
However, what I have noticed is that the flags can indicate that also - so
you can use this flag state to manipulate when to close ports.
For example, I created a port with tcp scheme and opened it like such
open/lines/direct/no-wait my-port
Then I noticed that when it was connected I could get the flags as 789059
and when it got disconnected by the remote it was set to 797251. This was
observed repeatedly. Now I can query the flags and identify if they are set
to 797251 and close the port as needed. This eliminates a timeout routine
for closing the port. Note that these flags may not match all port schemes
or types of ports as this was observed also.
Hope this helps. And thanks for the info about read-io.
Paul Tretter
----- Original Message -----
From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]>
To: <[rebol-list--rebol--com]>
Sent: Saturday, August 10, 2002 12:14 PM
Subject: [REBOL] possible rebol tcp open bug ...
> Hi,
>
> last two weeks we were testing our first boards of our device, which has
> limited, but functional ethernet + tcp stack. We've fixed several bugs,
> but found possible Rebol bug, or at least strange behavior.
>
> The problem was, that using following loop, rebol escaped from loop, TCP
> window in ACK packet dropped to 0, and RST packet was generated by
> 'close command, which is probably OK for Win98 and half-closed
> connection ....
>
> However:
>
> device: open/direct/no-wait tcp?//ip-addr:55
> while [wait device data: copy device][append result data]
>
> using above code, we watched Ethereal, and we catched just several
> packets and the loop breaked - so - 'none condition would have to be met
> with 'copy, but in async mode it should be possible only if other side
> closes the connection, which was NOT the case with our device.
>
> the proof our device works correctly could be seen watching Ethereal
> packet info, follow TCP guide book, and another aproach taken with rebol:
>
> device: open/direct ....
> forever [wait device res: read-io buff buff-size][....... clear buff]
>
> I don't have exact source here, but simply put - 'read-io worked
> flawlessly (except that it SHOULD be mentioned in docs, that if we don't
> clear buffer, it will not work too)
>
> Today I remembered earlier Chris' email, here it is:
> ----------------
>
> [1] Skip on file ports opened with
>
> open/binary/direct
>
> like in:
>
> fp: open/binary/direct %file
> skip fp 100
>
> is _still_ buggy with current /View beta (I better don't mention when
> this bug has first appeared on the list and presumably been sent to
> feedback ;-)
>
> File ports opened without the /binary refinment work.
>
> [2] /skip refinement ignored when used in following scenario:
>
> read/direct/skip/part %file 100 100
>
> PLEASE FIX, those are very important.
> ------------------
>
> so I tried to open our device using open/binary/direct/no-wait ... and -
it suddenly works, in opposite to open/direct/no-wait
> So - is there anything wrong with order of refinements applied to 'open,
or with combination of refinements used? I am just curious, if I discovered
a bug, or just should I always better use /binary when I use /direct/no-wait
too?
