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

A couple of things regarding ports

 [1/18] from: rebol:svendx:dk at: 15-Sep-2000 18:55


Hello, I have a couple of questions regarding the latest beta (REBOL/Core 2.4.35.1.1) I'm doing a multi connection server using raw tcp ports. The core loop goes like this: (I've stripped some logging, etc - so I might have broken something :-) serve: func [ /local ready-list wait-list pos ] [ wait-list: [] while [(length? port-list) > -1] [ clear wait-list foreach [port obj] port-list [append wait-list port] append wait-list 0:00:05 ready-list: wait/all wait-list if block? ready-list [ foreach port ready-list [ log 'debug [port/local-ip port/local-port "<->" port/remote-ip port/remote-port] pos: find port-list port if found? pos [ pos/2/handle-ready ] ] ] ] ] As you can see, each port is associated with an object (handler) which has a function, 'on-ready. The trouble is, that once in a while, handle-ready is called on a listen port that really hasn't got any incomming connections ??? [first port] hangs, and there's no timeout... (all listen ports are openend with open/no-wait tcp://:port-id ) have I done anything stupid, or is it a bug ?? (I still need to do some experimenting with different refinements to open, etc) On a related topic: I'd really like to get rid of the association list (port-list). probing the ports showed a word called 'locals (value: none), anyone know of any problems using it to point to the handler? Best regards Thomas Jensen

 [2/18] from: g::santilli::tiscalinet::it at: 16-Sep-2000 18:46


Hello [rebol--svendx--dk]! On 15-Set-00, you wrote: r> I'm doing a multi connection server using raw tcp ports. First of all, let me note that:
>> system/version
== 2.4.36.1.1
>> source dispatch
dispatch: func [ {Wait for a block of ports. As events happen, dispatch port handler blocks.} port-block [block!] {Block of port handler pairs (port can be timeout too).} /local ports awake timeblk result ][ ports: copy [] foreach [port job] port-block: reduce port-block [ if any [number? port time? port] [if none? timeblk [timeblk: :job]] append ports port ] forever [ either awake: wait/all ports [ if foreach item awake [ set/any 'result do select port-block item item if all [value? 'result 'break = :result] [break/return true] ] [break] ] [do :timeblk] ] ] there's a new function available. :-) r> The trouble is, that once in a while, handle-ready is called r> on a listen port that really hasn't got any incomming r> connections ??? [first port] hangs, and there's no timeout... It's probably a bug. r> On a related topic: I'd really like to get rid of the r> association list (port-list). probing the ports showed a word r> called 'locals (value: none), anyone know of any problems r> using it to point to the handler? I think you can use it freely in raw TCP ports. It is used by protocol handlers to store the data they need. Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [3/18] from: rebol:svendx:dk at: 18-Sep-2000 8:14


Hello [g--santilli--tiscalinet--it], On 16-Sep-00, [g--santilli--tiscalinet--it] wrote:
> Hello [rebol--svendx--dk]! > On 15-Set-00, you wrote:
<<quoted lines omitted: 3>>
> == 2.4.36.1.1 >>> source dispatch
-- snip dispatch source --
> there's a new function available. :-)
Hey, thanks! I was'nt aware of that.
>> The trouble is, that once in a while, handle-ready is called >> on a listen port that really hasn't got any incomming >> connections ??? [first port] hangs, and there's no timeout... > > It's probably a bug.
Never mind, it seems to have been fixed in 2.4.36.1.1...
>> On a related topic: I'd really like to get rid of the >> association list (port-list). probing the ports showed a word >> called 'locals (value: none), anyone know of any problems >> using it to point to the handler? > > I think you can use it freely in raw TCP ports. It is used by > protocol handlers to store the data they need.
I'll try it out and hope for the best :-)
> Regards, > Gabriele.
Regards Thomas Jensen

 [4/18] from: multimalte:theinbox at: 18-Sep-2000 1:42


Im also making a multi-connection app, and had the same problems, however, I don't get things to work with dispatch either.. perhaps Im not using it properly.. syntax, anyone? :) right now I go like port: dispatch [port1 port2] wrong? Cheers, malte -- Get your [firstname--lastname] email for FREE at http://NamePlanet.com/?su

 [5/18] from: al:bri:xtra at: 18-Sep-2000 21:00


malte wrote:
> Im also making a multi-connection app, and had the same problems, however,
I don't get things to work with dispatch either..
> perhaps Im not using it properly.. syntax, anyone? :) > > right now I go like > port: dispatch [port1 port2] > > wrong?
Yes. That's wrong. Have a look at the source for 'dispatch:
>> source dispatch
dispatch: func [ {Wait for a block of ports. As events happen, dispatch port handler blocks.} port-block [block!] {Block of port handler pairs (port can be timeout too).} /local ports awake timeblk result ][ ports: copy [] foreach [port job] port-block: reduce port-block [ if any [number? port time? port] [if none? timeblk [timeblk: :job]] append ports port ] forever [ either awake: wait/all ports [ if foreach item awake [ set/any 'result do select port-block item item if all [value? 'result 'break = :result] [break/return true] ] [break] ] [do :timeblk] ] ] Note the 'foreach: foreach [port job] port-block There's a job after each port value. Try: dispatch [port1 Port1Handler port2 Port2Handler] and have: Port1Handler: func [... etc. I hope that helps! Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [6/18] from: multimalte:theinbox at: 18-Sep-2000 2:24


ah yes, at a closer look at the source.... :) hmm, however, if I for example do like: dispatch [ port1 [print first port1] port2 [print first port2] ] it waits for the first port before printing the input on the second.. both the ports are open/direct/lines ideas? Cheers, malte
>Note the 'foreach: > foreach [port job] port-block
<<quoted lines omitted: 9>>
>http://members.xoom.com/AndrewMartin/ >-><-
-- Get your [firstname--lastname] email for FREE at http://NamePlanet.com/?su

 [7/18] from: al:bri:xtra at: 18-Sep-2000 21:41


> hmm, however, if I for example do like: > > dispatch [ > port1 [print first port1] > port2 [print first port2] > ] > > it waits for the first port before printing the input on the second. both
the ports are open/direct/lines Try something like: dispatch [port1 [print "Port1"] port2 [print "Port2"]] as your: print first port1 may be waiting for input on 'port1. That way, you can confirm that dispatch is working correctly. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [8/18] from: multimalte:theinbox at: 18-Sep-2000 3:00


>Try something like: > dispatch [port1 [print "Port1"] port2 [print "Port2"]] > as your: > print first port1 > may be waiting for input on 'port1.
the whole idea was to wait for data from the ports :) however, if I do it like [print "Port1"] I get spammed with a never ending list of Port1's, allthough the other end of Port1 isn't sending anything, and occasionally one or two Port2's.. something with the 'wait seems fishy enough?.. Cheers, malte -- Get your [firstname--lastname] email for FREE at http://NamePlanet.com/?su

 [9/18] from: allen:rebolforces at: 18-Sep-2000 20:24


----- Original Message ----- From: <[multimalte--theinbox--org]> To: <[list--rebol--com]> Sent: Monday, September 18, 2000 9:00 PM Subject: [REBOL] A couple of things regarding ports Re:(6)
> >Try something like: > > dispatch [port1 [print "Port1"] port2 [print "Port2"]]
<<quoted lines omitted: 7>>
> and occasionally one or two Port2's.. > something with the 'wait seems fishy enough?..
I've used 'dispatch in a basic /View chat script demo and it worked as expected. Try changing the port number to be sure nothing else on your system isn't using the same port number. (If you are using windows kill off any other REBOL processses that have accumulated in the taskmanager, they tend to hang around if the View is closed but the ports weren't closed properly.) read source for 'read-net, (which is used by 'request-download & 'read-via) to see an example of 'dispatch code. Cheers, Allen K

 [10/18] from: al:bri:xtra at: 18-Sep-2000 22:26


Allen wrote:
> I've used 'dispatch in a basic /View chat script demo and it worked as
expected. Allen's code looks like this: dispatch [ message-port :do-message event-port :do-event ] 'do-message and 'do-event are both functions. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [11/18] from: petr:krenzelok:trz:cz at: 18-Sep-2000 12:25


[Al--Bri--xtra--co--nz] wrote:
> malte wrote: > > Im also making a multi-connection app, and had the same problems, however,
<<quoted lines omitted: 30>>
> Note the 'foreach: > foreach [port job] port-block
ah, it's interesting - do you really prefer this aproach? (nested blocks) I remember Carl ones discussed he prefers one aproach, but I don't remember the result ... I would probably prefer having separate block with handlers parallel to port-block ... -pekr-

 [12/18] from: brett:codeconscious at: 18-Sep-2000 21:46


> read source for 'read-net, (which is used by 'request-download &
'read-via)
> to see an example of 'dispatch code. > > Cheers, > > Allen K >
Hi Allen, Where can I find 'read-net, 'request-download and 'read-via ? I really hope it's not a silly question :) Brett.

 [13/18] from: al:bri:xtra at: 18-Sep-2000 22:54


> Where can I find 'read-net, 'request-download and 'read-via ?
source read-net And I'm sure you can figure out the rest.
> I really hope it's not a silly question :)
Make sure you've got the latest version of Rebol. Andrew Martin ICQ: 26227169 http://members.ncbi.com/AndrewMartin/ http://members.xoom.com/AndrewMartin/

 [14/18] from: brett:codeconscious at: 18-Sep-2000 22:12


Thanks Andrew. Not having latest version was my problem. A few days from last download and I'm out of date! :) So now I can look at the source of read-net. Hmm. Ahh. Ooo. Wow. I'll say it backwards. Wow... :) Brett

 [15/18] from: petr:krenzelok:trz:cz at: 18-Sep-2000 13:37


[Al--Bri--xtra--co--nz] wrote:
> > Where can I find 'read-net, 'request-download and 'read-via ? > > source read-net > And I'm sure you can figure out the rest.
the rest - yes, the following line which probably causes panel doesn't go thru firewall and lives thru last X releases, probably still incorrect? ;-) port: open/direct/binary/no-wait [scheme: 'tcp host: host-name port-id: 80] Could above line go thru proxy? Look at Sterling's aproach taken in reb-prox.r script: port-spec: make port! [ scheme: 'tcp port-id: 80 proxy: make system/schemes/default/proxy [] ] if any [system/schemes/default/proxy/host system/schemes/http/proxy/host] [ proxy-spec: make port! [scheme: 'http] port-spec/proxy: make proxy-spec/proxy copy [] ] Sooooo? -pekr-

 [16/18] from: multimalte:theinbox at: 18-Sep-2000 5:04


>read source for 'read-net, (which is used by 'request-download & 'read-via) >to see an example of 'dispatch code.
hum.. is it just me that thinks that there are loads of undocumented functions here? :) Cheers, malte -- Get your [firstname--lastname] email for FREE at http://NamePlanet.com/?su

 [17/18] from: multimalte:theinbox at: 18-Sep-2000 8:25


On Mon, 18 Sep 2000 21:41:18 +1200 [Al--Bri--xtra--co--nz] wrote:
>> hmm, however, if I for example do like: >>
<<quoted lines omitted: 10>>
> print first port1 > may be waiting for input on 'port1.
uhm, one more thing, isn't that what it should do..? wait for data from either of the ports, and when it reaches one of them i want to, let's say, print it out?.. how should I work around it then?.. :) Cheers, malte
>That way, you can confirm that dispatch is working correctly. > >Andrew Martin >ICQ: 26227169 >http://members.ncbi.com/AndrewMartin/ >http://members.xoom.com/AndrewMartin/ >-><- >
-- Get your [firstname--lastname] email for FREE at http://NamePlanet.com/?su

 [18/18] from: sqlab:gmx at: 19-Sep-2000 10:48


Hello ---------------------------------------------- [multimalte--theinbox--org] wrote: Try something like: dispatch [port1 [print "Port1"] port2 [print "Port2"]] as your: print first port1 may be waiting for input on 'port1. the whole idea was to wait for data from the ports :) however, if I do it like [print "Port1"] I get spammed with a never ending list of Port1's, allthough the other end of Port1 isn't sending anything, and occasionally one or two Port2's.. something with the 'wait seems fishy enough?.. Cheers, malte ------------------------------ As long as you do not handle the port event correctly, you will get the event always again. You have to do something like [new-port: first serv-port] on the port after it gets a connection to satisfy the event handler. It seems to be a behaviour of wait to give back unserviced data as new until they are removed from the port. regards AR -- Sent through GMX FreeMail - http://www.gmx.net

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