Ok. You're in a room with a computer, and you're tasked with writing internode (and eventually interbbs) comm for a chat room or game..
There are two large buttons in front of you.
1st button: Queue() objects
2nd button: Socket() objects
which button would you push?
Granted I've already pushed a button... I'm just not sure if it was the right one. It's starting to make things very complicated.
Ok. You're in a room with a computer, and you're tasked with writing internode (and eventually interbbs) comm for a chat room or game..
There are two large buttons in front of you.
1st button: Queue() objects
2nd button: Socket() objects
which button would you push?
Granted I've already pushed a button... I'm just not sure if it was the right one. It's starting to make things very complicated.
There's another button which is the File object.
Anyway, Queues can't be used to communicate between BBSes (you need sockets or files to do that), so if you want to do interbbs, it might make sense to just use sockets. If you don't ever want to do interbbs, or you don't mind using a different communication mechanism between different nodes of your own BBS and nodes of other BBSes, then you can use Queues to communicate between your nodes. Another downside of Queues is you can't communicate
with nodes running on other computers (for the rare BBS, like Vertrauen, that has nodes split across multiple systems), so you'll need to use Socket or File I/O for that case.
So, if you want to support all use cases (inter and intra BBS, single and multi system BBSes) using a single mechanism, sockets are the way to go.
Re: Queues vs. Sockets (battle resurrected)
By: Digital Man to MCMLXXIX on Thu Oct 22 2009 22:57:22
Ok. You're in a room with a computer, and you're tasked with writing internode (and eventually interbbs) comm for a chat room or game..
There are two large buttons in front of you.
1st button: Queue() objects
2nd button: Socket() objects
which button would you push?
Granted I've already pushed a button... I'm just not sure if it was the right one. It's starting to make things very complicated.
There's another button which is the File object.
Anyway, Queues can't be used to communicate between BBSes (you need sockets or files to do that), so if you want to do interbbs, it might make sense to just use sockets. If you don't ever want to do interbbs,
or you don't mind using a different communication mechanism between different nodes of your own BBS and nodes of other BBSes, then you can use Queues to communicate between your nodes. Another downside of Queues is you can't communicate with nodes running on other computers (for the rare BBS, like Vertrauen, that has nodes split across multiple systems), so you'll need to use Socket or File I/O for that case.
So, if you want to support all use cases (inter and intra BBS, single
and multi system BBSes) using a single mechanism, sockets are the way to go.
That is precisely the point of view I was looking for. Thank you.
Unfortunately that means I have to tear apart almost everything I've
written so far, which is why I posed the question rather than make any assumptions. It's a shame to discard what I've written.
Queues are REALLY nice for internode (same system).. but that's never
really been the ultimate goal for any of this stuff.
Ok. You're in a room with a computer, and you're tasked with writing internode (and eventually interbbs) comm for a chat room or game..
There are two large buttons in front of you.
1st button: Queue() objects
2nd button: Socket() objects
which button would you push?
Granted I've already pushed a button... I'm just not sure if it was the right one. It's starting to make things very complicated.
Sysop: | Ree |
---|---|
Location: | Toronto, ON |
Users: | 2 |
Nodes: | 10 (0 / 10) |
Uptime: | 01:30:19 |
Calls: | 369 |
Files: | 2 |
Messages: | 38,903 |