On Aug 25, 2009, at 5:07 PM, Shane Hathaway wrote:

> Dave Smith wrote:
>> I already have a good marshaling method: Google Protocol Buffers.  
>> Now I
>> need some good software for sending messages to and from different  
>> parts
>> of the system.
>
> I mentioned Twisted.  If Python is out, I think I'd use libevent,  
> which
> provides something like the core of Twisted in C.
>
> http://www.monkey.org/~provos/libevent/


I don't get it. How can libevent (or libev for that matter) be used to  
send messages over the network to different pieces of my distributed  
system? Based on the docs for libev, it just seems like an event loop,  
nothing about network messaging at all that I can find.

I'm totally sold on Protocol Buffers. They're great for serializing/ 
deserializing messages, but now I need a stack of software that allows  
each part of my distributed system to send messages to the other  
parts, and easily do queries as well (i.e., not just send arbitrary  
messages event-style, but also ask for data and receive responses like  
an HTTP GET).

I have looked at AMQP, specifically OpenAMQ, and found its ramp-up  
time unacceptable and its documentation awkward. Further, it feels  
like overkill for the simple style of communication that I want. I'm  
looking for something that aims to achieve similar goals as AMQP, but  
with a much simpler implementation.

Yes, this question came up about a year ago, and XMPP and IRC were  
considered. I never really pursued those options further because I'm  
somewhat opposed to having a central "broker" (for lack of a better  
word) that acts as a single point of failure, and adds complexity for  
routing messages to and from the pieces of my distributed system.

The one thought that occurred to me was to have each component run a  
web server. When one component wants to send a message to another  
component, the sender would just send an HTTP POST request to the  
receiver. Likewise, if one component wants to query data from another  
component, the querier would send an HTTP GET to the queryee. That  
seems like it would work well, but HTTP has a bit too much overhead  
for me, as many of these messages will be very small, and components  
will need to respond to them very quickly. I guess this would be a web- 
services-based SOA.

Thoughts?

--Dave

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/

Reply via email to