Re: publish/subcribe model via network
# from Scott Gifford
# on Sunday 13 April 2008 19:14:
You can simplify both of these by providing a network client that
speaks a simple TCP-based protocol and relays messages to/from the IRC
server/multicast network/Jabber server.
Well, that's what I'm doing now -- sans the IRC relay. The repository
now has a wx subscriber, which demonstrates what I'm getting at with
all of this:
http://scratchcomputing.com/svn/misc/pubsubserver
I guess the closest analogy would be pypubsub, though I haven't read it.
The STOMP protocol looks promising, but I think I'm still going to build
my own server because none of those are in Perl.
There's also BEEP, which has an IETF RFC, but insists on using XML in
the headers.
Spread looks interesting, but some light reading implies that it is
rather opaque and would require a lot of configuration overhead.
My current use-case is many transient publishers and a few persistent
subscribers on a local network. The wxSocket code takes care of the
subscriber connection quite nicely, so I just need to get the server
handling concurrent publishers properly.
It appears that the dropped messages were coming from the fact that
every child (pub or sub) was opened on a write pipe and when a
publisher tries to write to a broken filehandle (e.g. a publisher which
is now gone), all of the subsequent writes break -- not sure if that
should send a $SIG{PIPE} or what -- but clearly, unidirectional
communication has flaws.
So, now I'm thinking there will be a manager process (separate from the
accept() loop) which reads sub/pub commands from the children and
writes to the subscribers via a per-subscriber fifo.
--Eric
--
I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors.
--Ben Schneiderman
---
http://scratchcomputing.com
---
Re: publish/subcribe model via network
Eric Wilhelm [EMAIL PROTECTED] writes: Hi all, I'm trying to figure out whether this has been done before and/or looking for suggestions on the best way to implement it. I would like the publish clients to connect to a server, then publish their message and disconnect. (Optionally, they can stay connected and publish more messages.) The subscribe clients would hold persistent connections to the server (there are only 2 subscribers, though there could be more) and receive the messages immediately after publication. I have needed something like this a few times, and a good first crack is to use an IRC server. You can then use the Perl IRC clients to do both publication and subscription. IRC channels become subscription services. If you need to do something more complex than that, you will need something custom, but for simple requirements it's very fast and reliable. At one point I had to run the server on Windows, and I used a pure Perl IRC server with good success: http://pircd.sourceforge.net/ Another very straightforward technique is to use IP multicast. If I were doing it from scratch I would also consider Jabber/XMPP, just to see if it has anything interesting. You can simplify both of these by providing a network client that speaks a simple TCP-based protocol and relays messages to/from the IRC server/multicast network/Jabber server. I did this with a Perl script of about 10 lines, IIRC, and ran it under tcpserver, and it simplified client implementation greatly. I can probably dig up some of this code if it would be useful. Hope this helps, Scott.
Re: publish/subcribe model via network
On Apr 14, 2008, at 02:41, Eric Wilhelm wrote: # from Scott Gifford # on Sunday 13 April 2008 19:14: You can simplify both of these by providing a network client that speaks a simple TCP-based protocol and relays messages to/from the IRC server/multicast network/Jabber server. Well, that's what I'm doing now -- sans the IRC relay. The repository now has a wx subscriber, which demonstrates what I'm getting at with all of this: http://scratchcomputing.com/svn/misc/pubsubserver [Stomp] [BEEP] [Spread] [PubSub] You could get a lot of mileage out of POE here. All these pieces interoperate due to the common POE substrate. http://search.cpan.org/dist/POE-Component-Server-IRC/ http://search.cpan.org/dist/POE-Component-MessageQueue/ (Stomp based) http://search.cpan.org/dist/POE-Component-Client-Stomp/ http://search.cpan.org/dist/POE-Filter-Stomp/ (Stomp wire protocol) http://search.cpan.org/dist/POE-Component-Spread/ http://search.cpan.org/dist/POE-Loop-Wx/ http://search.cpan.org/dist/POE-Component-Jabber/ (and XMPP) -- Rocco Caputo - [EMAIL PROTECTED]
