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

Read-io bug

 [1/8] from: ptretter:charter at: 13-Sep-2000 9:00


This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C01D60.FFAE8FF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I finally realized it must be a bug in read-io that causes the Network Timeout error message. Read-io is working fine as long as the server is sending data to the client. The timeout occurs before any ping command is sent from the server. I can detect from the read-io on the port when a ping is sent from the server. There is nothing to explain the problem. To test this I connected to IRC via Mirc and joined a channel called #rebolgods. Then I activated the script to connect and join the same channel. The result is a success and joins the channel. I can then query the nick and send data to it and see the output in the REBOL console. However, after a small amount of inactivity and before IRC send a ping the Network Timeout error occurs. I have looked at the help and determined that I have utilized the function correctly including the open function. It appears that some other timing algorithim is not properly accounted for in the read-io function. This also happend with the copy function on the ports data. Since read-io is native I assume that it is using copy as an internal function. Paul Tretter

 [2/8] from: carlos:lorenz at: 13-Sep-2000 14:19


Paul Yes thatīs it! Maybe someone at RT could say something about this Lorenz ----- Original Message ----- From: <[ptretter--charter--net]> To: <[list--rebol--com]> Cc: <[feedback--rebol--com]>

 [3/8] from: ptretter:charter at: 13-Sep-2000 14:10


I forwarded it to [feedback--rebol--com]. I didnt want to kill myself tyring much longer

 [4/8] from: d95-mjo::nada::kth::se at: 13-Sep-2000 22:37


On Wed, 13 Sep 2000 [ptretter--charter--net] wrote:
> I finally realized it must be a bug in read-io that causes the Network > Timeout error message. Read-io is working fine as long as the server is
<<quoted lines omitted: 12>>
> Since read-io is native I assume that it is using copy as an internal > function.
Maybe I misunderstood what you're trying to say, but I think the bug is actually a feature. :-) I believe the purpose of the network timeout is to occur when there is no data to read before the timeout. You can however wait for input to be available on the port and then read it, by using 'wait. /Martin Johannesson, [d95-mjo--nada--kth--se]

 [5/8] from: holger:rebol at: 13-Sep-2000 17:18


On Wed, Sep 13, 2000 at 09:00:01AM -0500, [ptretter--charter--net] wrote:
> I finally realized it must be a bug in read-io that causes the Network > Timeout error message. Read-io is working fine as long as the server is > sending data to the client.
Yes, that is intended behavior. Read-io, like all functions to read data from ports, has a timeout, configurable in system/schemes/default/timeout. The default is 30 seconds. If no data is received during that time then read-io returns a timeout error. You can increase the timeout if 30 seconds is not enough for your purpose. For IRC you probably want to increase it, because servers sometimes tend to be slow to respond... As for read-io not receiving data from the server, chances are the way you check for it is incorrect. Keep in mind that read-io is a low-level function that returns contents from TCP packets as they arrive, it does not attempt to recombine data in any way. An example: let's say the "pong" response from the server is broken up into two TCP packets in transit. In that case read-io will return two separate pieces of data, e.g. one with "po" and the other one with "ng". If you only check for "pong" in a single reply you received in read-io then you won't find the response. This is only one of many reasons why using read-io is not recommended. IRC is a line-oriented protocol, and for line-oriented protocols REBOL's copy/insert functions work just fine (even in older versions of REBOL), so you should use those. Here is an example of how pieces of the network request/response mechanism in an IRC client could be written. This particular example is intended to be used with current experimental versions of REBOL. To use it with older versions you may have to tweak it a little... REBOL [] system/schemes/default/timeout: 7200 ; two hours server: "us.dal.net" mynick: "q52hw2" myname: "joe" mygroup: "#test3636" scan-input: func [ /local response ] [ if not found? response: copy port [ quit ] if not empty? response [ forall response [ rp: first response handle-server-string rp ] ] ] handle-server-string: func [ str [string!] /local res ret ] [ space: charset " " nonspace: complement space prefix: [":" any nonspace some space] rules: [0 1 prefix res: any [space | nonspace]] if parse/all str rules [ ret: parse res " " if not error? try [to-integer first ret] [ print res return none ] switch first ret [ "PING" [ print "[responding to ping from server]" insert port rejoin ["PONG" rejoin at ret 2] return none ] "NOTICE" [ print rejoin [at ret 2] ] ] return ret ] none ] wait-response: func [ expected [string! word!] /local result rp response ] [ result: none while [not found? result] [ wait port if not found? response: copy port [ quit ] if not empty? response [ forall response [ rp: first response rp: handle-server-string rp if all [found? rp not found? result] [ result: find first rp expected ] ] ] ] ] send-cmd: func [ data [string!] resp [string!] ] [ insert port data wait-response resp ] irc-port: [ scheme: 'tcp host: server port-id: 6667 ] port: open/direct/lines/no-wait irc-port insert port rejoin ["NICK " mynick] insert port rejoin ["USER " mynick " 0 * " myname] insert port rejoin ["JOIN " mygroup] insert port rejoin ["WHOIS " mynick] send-cmd rejoin ["PING " server] "PONG" forever [ wait port scan-input ] -- Holger Kruse [holger--rebol--com]

 [6/8] from: ptretter:charter at: 14-Sep-2000 8:09


Thanks Martin, I used the wait command and it functioned correctly. I assumed that the forever loop was sufficient to keep read-io busy. Apparently that is not the case. This opens the door for alot more fun with ports. Paul Tretter

 [7/8] from: ptretter:charter at: 14-Sep-2000 8:59


Holger thanks for the reply. Excellent information on Read-IO. I would like to use your comments for my REBOL website Im currently working on. I want to go indepth on this subject. As for Read-io and sending responses - If data is captured in buffers do you still have the risk of receiving partial packet information? Also, what difference does COPY PORT provide in that respect? Paul Tretter

 [8/8] from: g:santilli:tiscalinet:it at: 14-Sep-2000 17:18


[carlos--lorenz--net] wrote:
> > I finally realized it must be a bug in read-io that causes the Network > > Timeout error message. Read-io is working fine as long as the server is > > sending data to the client. The timeout occurs before any ping command is > Yes thatīs it! Maybe someone at RT could say something about this
Most probably Paul just needs to use WAIT. READ-IO does wait for data for no more than the time specified in port/timeout. wait port read-io port buffer max-lenght HTH, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted