[ANN] mc.go: A pure Go memcache client with SASL support (binary protocol only)

982 views
Skip to first unread message

bmizerany

unread,
Nov 5, 2011, 6:02:42 PM11/5/11
to golan...@googlegroups.com
I needed a pure Go implementation of the Memcached binary protocol that supported SASL authentication; So I wrote one.

Here it is:

Any constructive feedback at all is appreciated.

-b
@bmizerany

Brad Fitzpatrick

unread,
Nov 5, 2011, 6:15:50 PM11/5/11
to golan...@googlegroups.com
Doesn't look like it supports sharding.  That's kinda the whole point of memcached. :)

I wrote a client too.  It doesn't speak the binary protocol, but it does support sharding:

Dustin

unread,
Nov 5, 2011, 6:22:26 PM11/5/11
to golan...@googlegroups.com
I wrote a binary protocol server, but it doesn't support SASL (holy crap, that was a couple days short of two years ago).  We should combine forces and fight crime.


bmizerany

unread,
Nov 5, 2011, 6:54:22 PM11/5/11
to golan...@googlegroups.com
I agree. This is just a start.

Keith Rarick

unread,
Nov 5, 2011, 6:54:33 PM11/5/11
to Brad Fitzpatrick, golan...@googlegroups.com
On Sat, Nov 5, 2011 at 3:15 PM, Brad Fitzpatrick <brad...@golang.org> wrote:
> Doesn't look like it supports sharding.  That's kinda the whole point of
> memcached. :)

Blake, you said you had plans to support sharding, right?
With an option to let users drop in their own sharding
algorithm, in case they need to interoperate with another
memcached client with its own sharding scheme.

IIRC, it was

type Chooser interface {
Choose(key string, servers []string) (n int)
}

with a DefaultChooser that does something reasonable,
so that something like

mc.New(nil, "10.0.0.1:11211", "10.0.0.2:11211")

would be the common usage. Is that about right?

kr

bmizerany

unread,
Nov 5, 2011, 6:55:24 PM11/5/11
to golan...@googlegroups.com
Power up. Let's do it. I'll be hacking it on it more over the next few days. Just wanted to ship something today.

Keith Rarick

unread,
Nov 5, 2011, 7:01:12 PM11/5/11
to golan...@googlegroups.com
On Sat, Nov 5, 2011 at 3:54 PM, Keith Rarick <k...@xph.us> wrote:
> type Chooser interface {
>    Choose(key string, servers []string) (n int)
> }

Though now that I think about it, the Chooser might want
to compute a relatively expensive data structure from the
list of servers (which changes infrequently), so it's
probably better to split that up into separate methods:

type Chooser interface {
Add(server string)
Remove(server string)
Choose(key string) int
}

kr

Brad Fitzpatrick

unread,
Nov 5, 2011, 8:38:36 PM11/5/11
to Keith Rarick, golan...@googlegroups.com
I'd think and Add and Remove are methods on an implementation of a particular implementation.

I went with this:

Gustavo Niemeyer

unread,
Nov 7, 2011, 9:58:28 AM11/7/11
to Keith Rarick, golan...@googlegroups.com
>> type Chooser interface {
>>    Choose(key string, servers []string) (n int)
>> }
>
> Though now that I think about it, the Chooser might want

FWIW, the above interface still feels nicer. The type implementing
that interface can always do custom actions internally when it finds
unknown servers.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.

Vasiliy Tolstov

unread,
Nov 8, 2011, 3:50:00 AM11/8/11
to Gustavo Niemeyer, Keith Rarick, golan...@googlegroups.com
2011/11/7 Gustavo Niemeyer <gus...@niemeyer.net>:

May be the good solution to create abstract package like sql (nosql
for example) and create drivers to all nosql databases (mongo, redis,
memcache...) ?

--
Vasiliy Tolstov,
Clodo.ru
e-mail: v.to...@selfip.ru
jabber: va...@selfip.ru

Francisco Souza

unread,
Nov 8, 2011, 10:24:46 AM11/8/11
to Vasiliy Tolstov, Gustavo Niemeyer, Keith Rarick, golan...@googlegroups.com
On Tue, Nov 8, 2011 at 6:50 AM, Vasiliy Tolstov <v.to...@selfip.ru> wrote:
2011/11/7 Gustavo Niemeyer <gus...@niemeyer.net>:
>>> type Chooser interface {
>>>    Choose(key string, servers []string) (n int)
>>> }
>>
>> Though now that I think about it, the Chooser might want
>
> FWIW, the above interface still feels nicer. The type implementing
> that interface can always do custom actions internally when it finds
> unknown servers.
>
> --
> Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog
>
> -- I never filed a patent.
>

May be the good solution to create abstract package like sql (nosql
for example) and create drivers to all nosql databases (mongo, redis,
memcache...) ?

No, it's not a good solution. nosql databases are not as similar as sql databases are. 

--
Francisco Souza

Reply all
Reply to author
Forward
0 new messages