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.
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...
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...
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. :-)
---Please goto your scfg-networking-qwk networking-default tagline, and put in
þ Synchronet þ My Brand-New BBS
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
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.
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).
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!
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.
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 so what I find out.
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("-");
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:
And/Or specifically deleting the Queue instance at the end of the script:
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.
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.
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.
Re: Re: Queues vs. SocketsBy: Digital Man to X V Lxxix on Thu Jun 19 2008 01:02 pm
Re: Re: Queues vs. SocketsBy: 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.
| Sysop: | fluid |
|---|---|
| Location: | wickliffe, ohio |
| Users: | 4 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 140:33:52 |
| Calls: | 50 |
| Files: | 15,838 |
| Messages: | 49,862 |