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? PS: posted to feedback ... Cheers, -pekr-

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 > ------------------ > so I tried to open our device using open/binary/direct/no-wait ... and -

> So - is there anything wrong with order of refinements applied to 'open,

Paul Tretter wrote:

>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. >