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

[REBOL] possible rebol tcp open bug ...

From: petr:krenzelok:trz:cz at: 10-Aug-2002 19:14

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-