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

How do I? Know when a tcp port is empty?

 [1/4] from: al::bri::xtra::co::nz at: 24-Oct-2000 22:58


How do I? Know when a _tcp_ port is empty? Here's a section of my code loosely copied and combined from the Rebol WebServer and Langreiter's vanillean http://www.langreiter.com Listen: port! Connection: port! Stop: false set 'Web-Server function [ Port [integer!] Web [file!] ][ Request Filename Data ][ Listen: open/lines join tcp://: Port while [not Stop] [ Connection: first wait Listen Request: make string! 1024 repend Request [first Connection newline] while [not 1 = length? Connection/state/inBuffer] [ ; the above line disturbs me seriously... repend Request [first Connection newline] ] print Request Using lines such as: empty? Connection seems to lead to infinite loops. Can some one point me in the right direction please? Thanks! PS In case you're interested, this project (Spider) is a Wiki and Sparrow in one, along with remote updating of web pages on sites without CGI access. The ultimate Web Dialect! Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [2/4] from: petr:krenzelok:trz:cz at: 24-Oct-2000 13:25


Andrew Martin wrote:
> How do I? Know when a _tcp_ port is empty? > Here's a section of my code loosely copied and combined from the Rebol
<<quoted lines omitted: 21>>
> seems to lead to infinite loops. > Can some one point me in the right direction please?
Hasn't Holger already suggested using 'copy, when 'copy return empty string if there is no info available? Hmm, maybe one of older Holger's mails could help here? ----------- Please wait for the next experimental build (i.e. a version AFTER Core 2.4.34, View 0.10.25 or Command 0.6.12) before publically releasing any scripts that use the new non-blocking features in REBOL, because we need to change the behavior (again), for better compatibility with older scripts, and to avoid future legacy problems, This change will break scripts that rely on the behavior in the current exp-build. The changes are: copy on TCP ports opened without refinements will work the way it used to originally (i.e. block if there is no data). If you don't want copy to block then use /no-wait on the open call. This means instead of a /wait refinement there will be a /no-wait refinement, and the default behavior will be reversed compared to the current exp-build, and thus will be the same way it used to be in Core <= 2.3 (blocking). The main reason is that with this change scripts which loop on copy until it returns none will continue to work on new versions of REBOL, without adapting the script. Also, if there is no data then copy will return an empty series, not none, as it does in current exp-builds, allowing you to distinguish the no data available yet, would block case from an end of stream, i.e. the peer closing the connection (for which copy will still return none). There will also be some changes to wait to make it more useful, e.g. wait [0 port] will poll the port (i.e. return the port if there is data, and none otherwise). This also works with multiple ports. Old versions of Core already used to do this on some platforms, somewhat inofficially, but current versions don't. It will become an official feature on all platforms starting with the next experimental build. There will also be a new "/all" refinement to wait which causes wait to return a block of all ports that have data waiting (instead of returning just one port). This allows you to write your own scheduler (e.g. round-robin) for handling incoming data on a multiplexed server written in REBOL. We are also planning other enhancements to wait and ports in general in the future, to make it easier to handle interactive, asynchronous connections, to support asynchronous sending, asynchronous connecting, asynchronous accepting of connections, asynchronous UDP operation, and to simplify the handling of multiple connections at the same time, e.g. for downloads in the background and for multiplexed web/ftp servers. Lots of good stuff ahead :). Please avoid using read-io whenever possible. It is a very low-level function that exposes your script to operating system-dependent oddities. For instance the amount of data typically returned may vary with the operating system, making testing more difficult for you. You also lose the convenience of line feed conversion etc., which may cause unexpected problems with your script when moving between Windows and Unix machines. "Normal" port functions in REBOL (copy, insert etc.) do these things automatically for you. We realize that in the past some shortcomings in the "normal" port functions (in particular copy blocking) have prevented you from doing some useful things, and sometimes read-io seemed to help, but these issues should be resolved in the next exp builds, and then the use of read-io will be discouraged even more than it is now. And just in case you are wondering, those new port features together with work on some additional enhancements in VID are the reasons why the new exp build for View we promised earlier is not out yet -- sorry for that delay. RSN, really... -- Holger Kruse [holger--rebol--com] Cheers, -pekr-

 [3/4] from: al:bri:xtra at: 25-Oct-2000 22:55


pekr wrote:
> Andrew wrote: > > Can some one point me in the right direction please? > > Hasn't Holger already suggested using 'copy, when 'copy return empty
string if there is no info available?
> Hmm, maybe one of older Holger's mails could help here?
Thanks, pekr, but it didn't seem to work for me. There always seems to be one character left in the buffer of the tcp port? Maybe a bug in Rebol port code? I've CC-ed this to feedback just in case. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/

 [4/4] from: g:santilli:tiscalinet:it at: 25-Oct-2000 15:22


Andrew Martin wrote:
> How do I? Know when a _tcp_ port is empty?
empty-port?: func [p [port!]] [p <> wait [p 0]] I'd suggest you to use the /NO-WAIT refinement and COPY, too. 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