This you shouldn't do when doing a reasonable high-performance server. I noticed that non-blocking waits eat up CPU.
--Maarten > In addition you could place a timeout on the wait > > wait wait-ports 600 > > ...and then loop through the port block performing the checks > > -----Original Message----- > From: Maarten Koopmans [mailto:[EMAIL PROTECTED]] > Sent: 09 October 2001 11:53 > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: tcp port open? > > > Phil, > > You are correct about the none? with copy > > Thanks, > > Maarten > > > This is how my tcp-server deals with it > > > > wait-ports: none > > listen-port: open/no-wait/direct/binary tcp://:9999 > > wait-ports: [ listen-port ] > > > > forever [ > > > > ; Perform asynch wait !!! > > wait wait-ports > > > > ; Is port descriptor set ? > > if not ( none? ( wait [ 0 listen-port ] ) ) [ > > > > ; Add port to block > > append wait-ports first listen-port > > ] > > > > ; Set scope of port checking > > check-ports: next wait-ports > > > > ; Check port activity ? > > while [ ( length? check-ports ) > 0 ] [ > > > > conn: first check-ports > > > > ; Is port still active ? > > either query conn [ > > > > ; Port active ... so check if any data to be read > > either not ( none? ( wait [ 0 conn ] ) ) [ > > > > ; Yes .. so determine size of data to be > > read > > readbuffer: copy #{} > > readbuffer: copy conn > > > > ; If length is none? then connection has > > been closed > > either none? readbuffer [ > > > > ; Close down port and tidy up > > wait-ports block entry > > close conn > > remove check-ports > > > > ] [ > > > > > > ; Is this NOT a HTTP request ? > > either none? ( find readbuffer > > "HTTP/1." ) [ > > > > > > ; Remove data from port > > clear conn > > > > ; Move onto next port > > check-ports: next > > check-ports > > > > ] [ > > > > ; HTTP request so detrmine > > what to do ... > > > > ; Remember it's a > > non-persistent connection > > ; Tidy up > > clear conn > > close conn > > > > ] > > > > ; VIP - empty out buffer area !!! > > clear readbuffer > > > > ] ; end of either none? readbuffer > > > > ] [ > > check-ports: next check-ports > > ] > > > > ] [ > > > > ; Port is no longer active ! > > > > ; tidy up > > clear conn > > close conn > > remove check-ports > > > > ] ; end of query conn > > > > ] ; end of while ( length? ... > > > > ] > > > > quit > > -----Original Message----- > > From: Maarten Koopmans [mailto:[EMAIL PROTECTED]] > > Sent: 09 October 2001 10:00 > > To: [EMAIL PROTECTED] > > Subject: [REBOL] Re: tcp port open? > > > > > > I know.... but I can't see that in Rebol. > > > > I am thinking of adding 'persistent connections' to Rugby but I need to > > know > > > > if the pipe is broken in order to do that. > > > > --Maarten > > > > On Tuesday 09 October 2001 10:53, you wrote: > > > You should have receive a notification that the connection has dropped > > > that's the nature of TCP! > > > > > > > > > -----Original Message----- > > > From: Petr Krenzelok [mailto:[EMAIL PROTECTED]] > > > Sent: 09 October 2001 09:23 > > > To: [EMAIL PROTECTED] > > > Subject: [REBOL] Re: tcp port open? > > > > > > Maarten Koopmans wrote: > > > > Hi, > > > > > > > > Is there a way to now if a tcp port is open on both sides. So that a > > > > > > server > > > > > > > (or client) can see whether or not the other side of the pipe is > > > > still > > > > > > open? > > > > > > I am not sure. Designing our camera we looked at Ethereal > > > (http://www.ethereal.org) packet monitor, and TCP communication is > > > several stages process of various ACK, SYN, RST, PSH, FIN type packets. > > > There is > > > > no > > > > > real > > > "connection" on the network, just packets sent here and there. That is > > > why someone can watch your packets (sniff) and see what you are > > > sending, if connected to the same network. So, alive connection is just > > > some > > state > > > > in your > > > tcp stack on your side, irrelevant to other side of "connection". There > > > is also > > > known case of semi-connection - e.g. one side timeouts, and the other > > > side is > > > still able to send packets, which are really delivered, just not > > probably > > > > processed. > > > > > > So, theoretically, if opposite side sends you FIN or RST assigned > > packet, > > > > you > > > should note it. This question is, however, for Holger. We have 'query > > > function > > > available, maybe Rebol somehow knows, if opposite side closed the > > > connection? > > > > > > -pekr- > > > > > > > Thanks, > > > > > > > > Maarten > > > > -- > > > > To unsubscribe from this list, please send an email to > > > > [EMAIL PROTECTED] with "unsubscribe" in the > > > > subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
