-
Queues vs. Sockets
From
MCMLXXIX@VERT/MDJ to
Digital Man on Mon Apr 28 21:37:53 2008
Ok.. now that I've cleared up the issues surround my ability to even askãquestions in here...ããI've come really far with some of these javascript games... and the nextãlogical step is making them multiplayer (real-time)ããWith the amount of data I intend to be passing back and forth between nodes,ãfile IO seems like a huge PITA. I could be wrong, but that's just how it seems.ãI've had moderate success using named queues to communicate between nodes in aãmakeshift "chat lobby" I made... but it leaves open Queues behind in memory,ãwhich interferes with the ability to detect whether or not there are any otherãusers connected. ããthat leaves me with sockets, unless there's a way to free up queues from memoryãso they don't show up in the named_queue list.ããthat being said.. is there a simple way to create a local socket connectionãbetween 2 nodes? the format is a little confusing, and I've had no success soãfar making it work.ããthanks for your patience (with my fumbles)ããã---ã þ Synchronet þ My Brand-New BBSã
-
From
Deuce@VERT/SYNCNIX to
MCMLXXIX on Tue Apr 29 00:36:07 2008
Re: Queues vs. Socketsã By: MCMLXXIX to Digital Man on Mon Apr 28 2008 09:37 pmãã > With the amount of data I intend to be passing back and forth betweenã > nodes, file IO seems like a huge PITA. I could be wrong, but that's justã > how it seems. I've had moderate success using named queues to communicateã > between nodes in a makeshift "chat lobby" I made... but it leaves openã > Queues behind in memory, which interferes with the ability to detectã > whether or not there are any other users connected.ããFile I/O is most likely to work...ãã > that leaves me with sockets, unless there's a way to free up queues fromã > memory so they don't show up in the named_queue list.ã >ã > that being said.. is there a simple way to create a local socket connectionã > between 2 nodes? the format is a little confusing, and I've had no successã > so far making it work.ããYes, you have one node bind/listen on a port and another node connect to it.ãBut it sounds like what you want is many nodes connected to many other nodes.ãIf reliability isn't needed AND it doesn't need to work on multisystemãinstalls, slicing off a part of the localnet and using broadcase would mostãlikely be easiest. Basically, have each node bind to a known port on 127.0.0.Xãwhere X is the node number. I think XP has an issue with this though... see:ã
http://support.microsoft.com/default.aspx?scid=kb;[LN];884020ããI'll see what I can whip up quickly for an example...ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
-
From
Deuce@VERT/SYNCNIX to
MCMLXXIX on Tue Apr 29 01:07:28 2008
Re: Queues vs. Socketsã By: Deuce to MCMLXXIX on Tue Apr 29 2008 12:36 amãã > Yes, you have one node bind/listen on a port and another node connect toã > it. But it sounds like what you want is many nodes connected to many otherã > nodes. If reliability isn't needed AND it doesn't need to work onã > multisystem installs, slicing off a part of the localnet and usingã > broadcase would most likely be easiest. Basically, have each node bind toã > a known port on 127.0.0.X where X is the node number. I think XP has anã > issue with this though... see:ã >
http://support.microsoft.com/default.aspx?scid=kb;[LN];884020ã >ã > I'll see what I can whip up quickly for an example...ããload("sbbsdefs.js");ãload("sockdefs.js");ããvar s=new Socket(SOCK_DGRAM, "InterNode");ãif(!s.bind(5000, "127.0.0."+bbs.node_num)) {ã writeln("Bind failed: "+s.error);ã exit(1);ã}ãif(!s.listen()) {ã writeln("Listen failed: "+s.error);ã exit(1);ã}ãwriteln("Q to quit or # to send message to node");ããwhile(1) {ã var k=console.getkey(K_NONE, 100);ã if(k.toUpperCase()=='Q')ã break;ã if(parseInt(k) > 0) {ã console.write(": ");ã var msg=console.getstr("", 77);ã s.sendto(msg,"127.0.0."+k, 5000);ã }ã if(s.data_waiting) {ã var d;ã d=s.recvfrom();ã writeln("Message from "+d.ip_address);ã writeln(d.data);ã writeln("");ã }ã writeln("Loop!");ã}ãããThis does NOT work under FreeBSD since you cannot actually listen on anyãloopback address except 127.0.0.1... not sure of other OSs. Failing that, youãcan use port number X+bbs.node_num and just not be able to broadcast... whichãmay be enough. Fiddle with the 5000 instead of 127.0.0. in the script.ããTCP gets trickier. :-)ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
-
From
MCMLXXIX@VERT/MDJ to
Deuce on Tue Apr 29 08:26:38 2008
Re: Queues vs. Socketsã By: Deuce to MCMLXXIX on Tue Apr 29 2008 00:36:07ãã > Re: Queues vs. Socketsã > By: MCMLXXIX to Digital Man on Mon Apr 28 2008 09:37 pmã > ã > > With the amount of data I intend to be passing back and forth betweenã > > nodes, file IO seems like a huge PITA. I could be wrong, but that's justã > > how it seems. I've had moderate success using named queues to communicateã > > between nodes in a makeshift "chat lobby" I made... but it leaves openã > > Queues behind in memory, which interferes with the ability to detectã > > whether or not there are any other users connected.ã > ã > File I/O is most likely to work...ã > ã > > that leaves me with sockets, unless there's a way to free up queues fromã > > memory so they don't show up in the named_queue list.ã > >ã > > that being said.. is there a simple way to create a local socket connectiã > > between 2 nodes? the format is a little confusing, and I've had no succesã > > so far making it work.ã > ã > Yes, you have one node bind/listen on a port and another node connect to it.ã > But it sounds like what you want is many nodes connected to many other nodesã > If reliability isn't needed AND it doesn't need to work on multisystemã > installs, slicing off a part of the localnet and using broadcase would mostã > likely be easiest. Basically, have each node bind to a known port on 127.0.ã > where X is the node number. I think XP has an issue with this though... seeã >
http://support.microsoft.com/default.aspx?scid=kb;[LN];884020ã > ã > I'll see what I can whip up quickly for an example...ã > ããI pretty much have no idea what you're talking about.. Guess I've got someãinvestigating to do. and don't make fun of my tagline! I had just reset myãmessage bases!ãã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã
-
From
MCMLXXIX@VERT/MDJ to
Deuce on Tue Apr 29 08:39:08 2008
Re: Queues vs. Socketsã By: Deuce to MCMLXXIX on Tue Apr 29 2008 01:07:28ãã > Re: Queues vs. Socketsã > By: Deuce to MCMLXXIX on Tue Apr 29 2008 12:36 amã > ã > > Yes, you have one node bind/listen on a port and another node connect toã > > it. But it sounds like what you want is many nodes connected to many otheã > > nodes. If reliability isn't needed AND it doesn't need to work onã > > multisystem installs, slicing off a part of the localnet and usingã > > broadcase would most likely be easiest. Basically, have each node bind tã > > a known port on 127.0.0.X where X is the node number. I think XP has anã > > issue with this though... see:ã > >
http://support.microsoft.com/default.aspx?scid=kb;[LN];884020ã > >ã > > I'll see what I can whip up quickly for an example...ã > ã > load("sbbsdefs.js");ã > load("sockdefs.js");ã > ã > var s=new Socket(SOCK_DGRAM, "InterNode");ã > if(!s.bind(5000, "127.0.0."+bbs.node_num)) {ã > writeln("Bind failed: "+s.error);ã > exit(1);ã > }ã > if(!s.listen()) {ã > writeln("Listen failed: "+s.error);ã > exit(1);ã > }ã > writeln("Q to quit or # to send message to node");ã > ã > while(1) {ã > var k=console.getkey(K_NONE, 100);ã > if(k.toUpperCase()=='Q')ã > break;ã > if(parseInt(k) > 0) {ã > console.write(": ");ã > var msg=console.getstr("", 77);ã > s.sendto(msg,"127.0.0."+k, 5000);ã > }ã > if(s.data_waiting) {ã > var d;ã > d=s.recvfrom();ã > writeln("Message from "+d.ip_address);ã > writeln(d.data);ã > writeln("");ã > }ã > writeln("Loop!");ã > }ã > ã > ã > This does NOT work under FreeBSD since you cannot actually listen on anyã > loopback address except 127.0.0.1... not sure of other OSs. Failing that, yã > can use port number X+bbs.node_num and just not be able to broadcast... whicã > may be enough. Fiddle with the 5000 instead of 127.0.0. in the script.ã > ã > TCP gets trickier. :-)ã > ããOk that makes sense. I'll see what I can do with it. Thanks!ãã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã
-
From
Lord Time@VERT/TIME to
MCMLXXIX on Tue Apr 29 10:48:00 2008
---ãM> þ Synchronet þ My Brand-New BBSãM> ãPlease goto your scfg-networking-qwk networking-default tagline, and put inãthe name of your bbs & telnet addressãã---ãRob StarrãLord Time SysOp of Time Warp of the Future BBSãTelnet://Time.Darktech.Org:24ãor Telnet://Time.Synchro.Net:24ãICQ # 11868133 Yahoo : lordtime2000ãAIM : LordTime20000 MSN : Lord Timeããþ CMPQwk 1.42 16554 þ Upload Error #69 - Blonde Not Attachedã---ã þ Synchronet þ Time Warp of the Future BBS - Home of League 10 IBBS Gamesã
-
From
Angus McLeod@VERT/ANJO to
Deuce on Tue Apr 29 09:04:00 2008
Re: Queues vs. Socketsã By: Deuce to MCMLXXIX on Tue Apr 29 2008 00:36:00ãã > Yes, you have one node bind/listen on a port and another node connect to it.ã > But it sounds like what you want is many nodes connected to many other nodesããHow about a comms-handler task that queues all the data and manages ãdistribution by node number?ãã---ãAmarok: 17,459 tracks from 1,238 albums by 1,349 artists, but none playing.ã þ Synchronet þ Making sure Jason works OK at The ANJO BBSã
-
From
Digital Man@VERT to
MCMLXXIX on Tue Apr 29 18:53:48 2008
Re: Queues vs. Socketsã By: MCMLXXIX to Digital Man on Mon Apr 28 2008 09:37 pmãã > Ok.. now that I've cleared up the issues surround my ability to even askã > questions in here...ã >ã > I've come really far with some of these javascript games... and the nextã > logical step is making them multiplayer (real-time)ã >ã > With the amount of data I intend to be passing back and forth betweenã > nodes, file IO seems like a huge PITA. I could be wrong, but that's justã > how it seems. I've had moderate success using named queues to communicateã > between nodes in a makeshift "chat lobby" I made... but it leaves openã > Queues behind in memory, which interferes with the ability to detectã > whether or not there are any other users connected.ããNamed queues are *supposed* to be automatically deleted when the last "user"ãthread deletes their instance of the queue object (which *should* happenãwhenever the script terminates).ãã > that leaves me with sockets, unless there's a way to free up queues fromã > memory so they don't show up in the named_queue list.ããDon't abandon the Queue idea so quickly. I'll see if I can reproduce whatãyou're describing and fix it.ãã > that being said.. is there a simple way to create a local socket connectionã > between 2 nodes? the format is a little confusing, and I've had no successã > so far making it work.ããFile I/O or a Queue would be easier. I'd like to see if we can get the namedãqueues working for ya.ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #56:ã1/4 of the bones in your body are in your feet.ãNorco, CA WX: 69.4øF, 56% humidity, 2 mph WSW wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
MCMLXXIX@VERT/MDJ to
Digital Man on Wed Apr 30 08:18:38 2008
Named queues are *supposed* to be automatically deleted when the last ã > "user" thread deletes their instance of the queue object (which *should* ã > happen whenever the script terminates).ãã ãI first ran the multiplayer engine, then quit. It happens even if only one ãperson runs it, but I set each script to ignore their own connection in the ãlist so it's unnoticable.ããThenmade a test script that loops through the list_named_queues() array and ãlogs the name, read_level, and write_level. Sometimes they disappear, ãsometimes they don't. Don't know if that's of any help to you.ãã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã
-
From
Tracker1@VERT/TRN to
MCMLXXIX on Thu May 1 15:05:53 2008
On 04/29/2008 05:39 AM, MCMLXXIX wrote:ã>> if(!s.bind(5000, "127.0.0."+bbs.node_num)) {ã>> ã>> TCP gets trickier. :-)ã>ã> Ok that makes sense. I'll see what I can do with it. Thanks!ããAnother suggestion if you can't use 127.0.0.* .. you could just do aã5000 + bbs.node_num for the listening port, and have each node have a ãdifferent port.. say from 5001 - 500x ...ããKinda kludgy, but could work... not sure how something like a trivia chat ãwould work... I would just create a service in js that each node connects to..ãã-- ãMichael J. Ryan - tracker1(at)theroughnecks(dot)net - www.theroughnecks.netãicq: 4935386 - AIM/AOL: azTracker1 - Y!: azTracker1 - MSN/Win: (email)ãã... FRA #102: Nature decays, but latinum lasts forever.ãã---ã þ Synchronet þ theroughnecks.net - you know you want itã
-
From
MCMLXXIX@VERT/MDJ to
Digital Man on Sat May 3 12:35:00 2008
Re: Re: Queues vs. Socketsã By: MCMLXXIX to Digital Man on Wed Apr 30 2008 08:18:38ãã > > Named queues are *supposed* to be automatically deleted when the lastã > > "user" thread deletes their instance of the queue object (which *should*ã > > happen whenever the script terminates).ã > ã > ã > I first ran the multiplayer engine, then quit. It happens even if only oneã > person runs it, but I set each script to ignore their own connection in theã > list so it's unnoticable.ã > ã > Thenmade a test script that loops through the list_named_queues() array andã > logs the name, read_level, and write_level. Sometimes they disappear,ã > sometimes they don't. Don't know if that's of any help to you.ããAny luck duplicating those results? I'm messing around with UDP sockets,ãcurrently, but they make it kind of impossible to tell if anyone else isãconnected. with named queues you can at least check for their presence.. I'mãreally trying to avoid file i/oãã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã
-
From
Digital Man@VERT to
MCMLXXIX on Wed May 7 13:08:32 2008
Re: Re: Queues vs. Socketsã By: MCMLXXIX to Digital Man on Sat May 03 2008 12:35 pmãã > Re: Re: Queues vs. Socketsã > By: MCMLXXIX to Digital Man on Wed Apr 30 2008 08:18:38ã >ã > > > Named queues are *supposed* to be automatically deleted when the lastã > > > "user" thread deletes their instance of the queue object (whichã > > > *should* happen whenever the script terminates).ã > >ã >ã > > I first ran the multiplayer engine, then quit. It happens even if onlyã > > one person runs it, but I set each script to ignore their own connectionã > > in the list so it's unnoticable.ã >ã > > Thenmade a test script that loops through the list_named_queues() arrayã > > and logs the name, read_level, and write_level. Sometimes theyã > > disappear, sometimes they don't. Don't know if that's of any help toã > > you.ã >ã > Any luck duplicating those results?ããNo, I haven't tried yet. It's on my next-to-do-list, so I'll let you know soonãwhat I find out.ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #114:ãThe oldest known animal was a tortoise, which lived to be 152 years old. ãNorco, CA WX: 61.3øF, 68% humidity, 0 mph SSW wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
MCMLXXIX@VERT/MDJ to
Digital Man on Wed May 7 16:45:46 2008
Re: Re: Queues vs. Socketsã By: Digital Man to MCMLXXIX on Wed May 07 2008 13:08:32ãã > ã > No, I haven't tried yet. It's on my next-to-do-list, so I'll let you know soã > what I find out.ã > ããOk cool. I got a form of it working nicely, using file IO and UDP sockets, butãin order to transmit things like screen coordinates or anything that needs toãcome through and be received as it was intended, named queues seem like theãbest option. ãã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã
-
From
Digital Man@VERT to
MCMLXXIX on Thu Jun 12 01:11:27 2008
Re: Re: Queues vs. Socketsã By: MCMLXXIX to Digital Man on Sat May 03 2008 12:35 pmãã > Re: Re: Queues vs. Socketsã > By: MCMLXXIX to Digital Man on Wed Apr 30 2008 08:18:38ã >ã > > > Named queues are *supposed* to be automatically deleted when the lastã > > > "user" thread deletes their instance of the queue object (whichã > > > *should* happen whenever the script terminates).ã > >ã >ã > > I first ran the multiplayer engine, then quit. It happens even if onlyã > > one person runs it, but I set each script to ignore their own connectionã > > in the list so it's unnoticable.ã >ã > > Thenmade a test script that loops through the list_named_queues() arrayã > > and logs the name, read_level, and write_level. Sometimes theyã > > disappear, sometimes they don't. Don't know if that's of any help toã > > you.ã >ã > Any luck duplicating those results?ããI tried to reproduce your problem, but could not. I created a simple scriptã(queue.js):ããprint("before:");ãprint(list_named_queues());ãprint("-");ããnew Queue("test");ãconsole.pause();ããprint("after:");ãprint(list_named_queues());ãprint("-");ããAnd I ran this one node, left it at the pause prompt, logged into another nodeãand ran it again leaving the second instance also at the pause prompt. Then Iãhit a key on the first instance, hit a key on the second (so both scripts haveãnow terminated) and when running it again, it shows there are no named queues.ãI tried letting the second script exit first and I get the same result.ããPerhaps its the way in which you're executing the script (in the same scope asãyour command shell maybe?). I just used ";EXEC ?queue.js", which shouldãsimulate how it would execute as a door or loadable module. Or maybe you haveãto write to the queue before the anomoly occurs? I don't enough informationãcurrently to know. More details on how to reproduce the problem are requested!ã:-)ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #116:ãThe largest fish is the whale shark - it can be over 50 feet long and weigh 2 tons. ãNorco, CA WX: 64.2øF, 67% humidity, 0 mph SE wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
X V Lxxix@VERT to
Digital Man on Thu Jun 19 08:21:05 2008
I tried to reproduce your problem, but could not. I created a simple script ã > (queue.js):ãã > print("before:");ã > print(list_named_queues());ã > print("-");ãã > new Queue("test");ã > console.pause();ãã > print("after:");ã > print(list_named_queues());ã > print("-");ãã ãwell. I'm pretty sure the problem only occurs when there is data waiting in ãthe queue read or write buffers. when the queue is unused, it deletes as ãnormal. ããtry putting this in there:ãq=new Queue("test" + bbs.node_number);ãq.write("testing");ããthat way each instance will create its own uniquely named queue and write data ãto it, then exit.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
X V Lxxix@VERT to
X V Lxxix on Thu Jun 19 08:30:48 2008
Using the following code, I was able to duplicate my previous results.. ãOnce the queues are stuck, they're stuck there until you restart the bbs, I ãthink. ããprint("before:");ãprint(list_named_queues());ãprint("-");ããq=new Queue("test" + bbs.node_num);ãq.write("testing");ãconsole.pause();ããprint("after:");ãprint(list_named_queues());ãprint("-");ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
Digital Man@VERT to
X V Lxxix on Thu Jun 19 11:12:53 2008
Re: Re: Queues vs. Socketsã By: X V Lxxix to X V Lxxix on Thu Jun 19 2008 08:30 amãã > Using the following code, I was able to duplicate my previous results..ã > Once the queues are stuck, they're stuck there until you restart the bbs, Iã > think.ã >ã > print("before:");ã > print(list_named_queues());ã > print("-");ã >ã > q=new Queue("test" + bbs.node_num);ã > q.write("testing");ã > console.pause();ã >ã > print("after:");ã > print(list_named_queues());ã > print("-");ããTry declaring 'q' as a local variable:ãã var q=new Queue("test" + bbs.node_num);ããAnd/Or specifically deleting the Queue instance at the end of the script:ãã delete q;ããBoth (either one) of these fixes forces the Queue destructor to be called atãthe end of the script which is responsible for detaching the node thread fromãthe Queue and removing the Queue from the named-queue list.ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #76:ãThe average person spends 2 years on the phone in his/her lifetime.ãNorco, CA WX: 64.2øF, 67% humidity, 0 mph SE wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
X V Lxxix@VERT to
Digital Man on Thu Jun 19 12:46:57 2008
Try declaring 'q' as a local variable:ãã var q=new Queue("test" + bbs.node_num);ãã > And/Or specifically deleting the Queue instance at the end of the script:ãã delete q;ãã > Both (either one) of these fixes forces the Queue destructor to be called ã > at the end of the script which is responsible for detaching the node thread ã > from the Queue and removing the Queue from the named-queue list.ããthat worked. I think part of the problem was that to make the queue ãcommunications work for more than 2 people, I had to create more than one ãqueue, and consequently each participating user had to create a local instance ãof each named queue. ããIt made things a lot harder to clean up. Since you have a local instance of ãevery user's queue, you can't rely on the queue's existence to determine if ãthe user is still present. so I had to make an exiting user broadcast on a ãnamed "quit" channel so that listening connections would know the person has ãleft, and both would have to delete their instance of the queue. ããSomewhere in that nonsense things did not work.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
Digital Man@VERT to
X V Lxxix on Thu Jun 19 13:02:50 2008
Re: Re: Queues vs. Socketsã By: X V Lxxix to Digital Man on Thu Jun 19 2008 12:46 pmãã > > Both (either one) of these fixes forces the Queue destructor to beã > > called at the end of the script which is responsible for detaching theã > > node thread from the Queue and removing the Queue from the named-queueã > > list.ã >ã > that worked. I think part of the problem was that to make the queueã > communications work for more than 2 people, I had to create more than oneã > queue, and consequently each participating user had to create a localã > instance of each named queue.ã >ã > It made things a lot harder to clean up. Since you have a local instance ofã > every user's queue, you can't rely on the queue's existence to determine ifã > the user is still present. so I had to make an exiting user broadcast on aã > named "quit" channel so that listening connections would know the personã > has left, and both would have to delete their instance of the queue.ã >ã > Somewhere in that nonsense things did not work.ããGlad it's working for you now. In general, it's good practice to use 'var' toãdefine variables as the scope is then specified (not global) and you'll haveãbetter garbage collection.ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #127:ãA hummingbird's heart beats 1,400 times a minute. ãNorco, CA WX: 64.2øF, 67% humidity, 0 mph SE wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
Digital Man@VERT to
X V Lxxix on Thu Jun 19 17:37:19 2008
Re: Re: Queues vs. Socketsã By: Digital Man to X V Lxxix on Thu Jun 19 2008 01:02 pmãã > Re: Re: Queues vs. Socketsã > By: X V Lxxix to Digital Man on Thu Jun 19 2008 12:46 pmã >ã > > > Both (either one) of these fixes forces the Queue destructor to beã > > > called at the end of the script which is responsible for detachingã > > > the node thread from the Queue and removing the Queue from theã > > > named-queue list.ã > >ã > > that worked. I think part of the problem was that to make the queueã > > communications work for more than 2 people, I had to create more thanã > > one queue, and consequently each participating user had to create aã > > local instance of each named queue.ã > >ã > > It made things a lot harder to clean up. Since you have a local instanceã > > of every user's queue, you can't rely on the queue's existence toã > > determine if the user is still present. so I had to make an exiting userã > > broadcast on a named "quit" channel so that listening connections wouldã > > know the person has left, and both would have to delete their instanceã > > of the queue.ã > >ã > > Somewhere in that nonsense things did not work.ã >ã > Glad it's working for you now. In general, it's good practice to use 'var'ã > to define variables as the scope is then specified (not global) and you'llã > have better garbage collection.ããBTW, I realize it's probably not clear from the documentationã(
http://synchro.net/docs/jsobjs.html#Queue), but the "value" argument to theãQueue.write() method can be any of several JS value types: bool, string,ãnumber, null, *even* an object (with properties of any of these types,ãincluding nested objects).ããThis may help in passing complex state information between threads (nodes)ãwithout requiring complex string parsing.ãã digital man (xbox-live: digitlman)ããSnapple "Real Fact" #76:ãThe average person spends 2 years on the phone in his/her lifetime.ãNorco, CA WX: 64.2øF, 67% humidity, 0 mph SE wind, 0.00 inches rain/24hrsã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã
-
From
X V Lxxix@VERT to
Digital Man on Fri Jun 20 07:34:25 2008
Re: Re: Queues vs. Socketsã By: Digital Man to X V Lxxix on Thu Jun 19 2008 01:02 pmãã > > Re: Re: Queues vs. Socketsã > By: X V Lxxix to Digital Man on Thu Jun 19 2008 12:46 pmã >ã > > > > Both (either one) of these fixes forces the Queue destructor to be ã > > > > called at the end of the script which is responsible for detaching ã > > > > the node thread from the Queue and removing the Queue from the ã > > > > named-queue list.ã > > >ã > > > that worked. I think part of the problem was that to make the queue ã > > > communications work for more than 2 people, I had to create more than ã > > > one queue, and consequently each participating user had to create a ã > > > local instance of each named queue.ã > > >ã > > > It made things a lot harder to clean up. Since you have a local ã > > > instance of every user's queue, you can't rely on the queue's ã > > > existence to determine if the user is still present. so I had to make ã > > > an exiting user broadcast on a named "quit" channel so that listening ã > > > connections would know the person has left, and both would have to ã > > > delete their instance of the queue.ã > > >ã > > > Somewhere in that nonsense things did not work.ã > >ã > > Glad it's working for you now. In general, it's good practice to use ã > > 'var' to define variables as the scope is then specified (not global) ã > > and you'll have better garbage collection.ã > ã > BTW, I realize it's probably not clear from the documentation ã > (http://synchro.net/docs/jsobjs.html#Queue), but the "value" argument to ã > the Queue.write() method can be any of several JS value types: bool, ã > string, number, null, *even* an object (with properties of any of these ã > types, including nested objects).ãã > This may help in passing complex state information between threads (nodes) ã > without requiring complex string parsing.ãããVERY good to know. For some reason I was under the assumption that was not the ãcase. I think I tried passing an object and it didn't work. But....... I've ãbeen known to pull on the "push to open" doors.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã