# 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 ---------------------------------------------------
