On Sun, Jan 11, 2009 at 1:31 PM, Erich <[email protected]> wrote: > My thoughts were a fast server and super lightweight protocol, similar > to memcache and beanstalk. Clients would connect to the server and > communication would look something like this:
Ah, I see. At least in the case of beanstalkd, the MD5 hash of a request can be much bigger than the request itself, making the central dispatcher a bandwidth bottleneck. This is similar to an idea I had a while back. The main difference is that I wanted clients to route their requests themselves (distributing that work over more hardware). Then the problem becomes keeping clients informed of service presence and availability. I wanted a meta-service called "billboard" as a way for services to advertise themselves on a network. In a way this also reminds me of Google's "chubby" files, occasionally described as the "root of all distributed data structures". With these ideas I can think of one main drawback: it can easily add significant complexity and I'm not sure the benefit is worth that complexity. Also, a naive implementation creates a single point of failure for the entire network. I usually try to eliminate those, not introduce new ones. :) kr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
