Hm. In thinking about how to write the protocol in a cleaner way, I stumbled across the concept of coroutines.
Are you familiar with them? For example, Mongrel2 uses Libtask, by Russ Cox: http://swtch.com/libtask/ It seems like this kind of thing could clean up an asynchronous protocol implementation quite a bit. Jon Cooper ([email protected]) On Thu, May 5, 2011 at 8:52 AM, Jon Cooper <[email protected]> wrote: > > - plan on using shared secret authentication schemes like PLAIN or >> > DIGEST-MD5. expect administrators to use plaintext password databases. >> >> I bet most administrators would prefer to have an encrypted password file. > > > As far as I can tell (and the docs are fairly sparse on the ground) the > most commonly used mechanisms are PLAIN, CRAM-MD5, and DIGEST-MD5. > > Unfortunately, from > http://www.postfix.org/SASL_README.html#testing_saslauthd: > > "These mechanisms send credentials encrypted but their verification process > requires the password to be available in plaintext. Consequently passwords > cannot (!) be stored in encrypted form." > > Since this is a mechanism-specific issue it is true independent of where > the passwords are stored. (The most common locations being sasldb (a > Berkeley DB on disk), an LDAP database, or a SQL database. > > There is a better mechanism out there, SCRAM-SHA-1, but it isn't widely > deployed yet. > > This is short and related: http://prosody.im/doc/plain_or_hashed > > The examples for e.g. Postfix and memcached typically steer the > administrator toward the use of sasldb for the authentication database. > Strange, I know. > > > - build an evented server modelled after beanstalkd, reusing net.c / >> > sock-*.c / sd-daemon.* / srv.c and following the patterns of conn.c / >> > prot.c. [1] >> >> Ok, but a great deal of the code in beanstalkd (especially prot.c) is >> messy and disorganized. I'm in the process of cleaning it up, bit by bit, >> as time permits. >> > > I noticed that. :) > > Are there any examples of asynchronous servers in C that you've seen which > are particularly attractive, from a codebase perspective? (This is the first > one I've ever looked at.) > > >> > - modify beanstalkd to have a switch that causes it to listen to a >> PF_UNIX >> > socket bound to a path. recvmsg() instead of accept(). >> >> Perfect. You might also want to think about modifying net.c to properly >> handle a unix socket inherited from systemd. > > > Cool. Should just be able to patch make_server_socket to check with > sd-daemon.c:sd_is_socket_unix, right? > > >> > [2] My first cut of a wire protocol: >> > ... >> >> This looks great. I have a small objection to using the word "auth", >> because it's ambiguous (it could be short for "authentication" or >> "authorization"). >> > > Fair 'nuff. > > >> Clients that intend to pipeline commands will have to stall until getting >> AUTH_OK, and probably won't be able to do much of any pipelining >> at all during authentication. I'm not sure if that needs to be explained >> as part of the protocol spec. > > > Great point, it definitely should. Especially since depending upon SASL > configuration there could be (in theory) arbitrarily many rounds of > challenge/response during authentication. > > Jon > -- 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.
