
My Favorite Database is the Network - craigkerstiens
http://lucumr.pocoo.org/2013/11/17/my-favorite-database/
======
liyanchang
Technology, just like fashion, is cyclical. There are only so many
configurations of communication patterns so technological constraints dictate
usefulness.

The two being contrasted here are the one centralized database (w/
master/slave, replica sets, etc of course) versus a peer-to-peer
configuration.

We've been in a centralized hub and spoke model as cloud servers have taken
off. As clients get more powerful and network links slow[1], we're going to
move more to peer-to-peer models.

The concept described by the author is right in the middle: hub and spoke, but
keep all the data on the spokes. Of course, the comments (EGreg) points out
that this has a disadvantage of difficult access if the spoke is storing
another spokes information.

Adding a couple peer-to-peer connections can help with this and WebRTC is a
good technology for doing it. Once you connect peers, you can move data from
peer-to-peer without hitting a central server again. Now, the central server
is merely orchestrating rather then dictating.

The author (author of flask, werkzeug, ...) is probably on the forefront of
things, so while you may not find that this model is useful yet, it's prudent
to watch as it will become more prominent in the next couple years.

[1] Phones are getting more powerful and computers/laptops already feel like
overkill for the youtube/redditing etc that we do. Networks are not slowing so
much as wireless connections are getting clogged as more people are
overloading cell providers.

------
timtadh
You really need to be careful how you implement the signing of these types of
systems. I have broken several of these systems and extracted the secret key.
If you can extract the secret key, you can essentially become anyone and do
anything that is controlled by the state in the cookie. Properly implemented,
this shouldn't be a problem. I recommend having a separate key for each client
session and storing the sessions in something fast and ephemeral like
memcache. This has the advantage of also giving you a place to store another
secret key for CSRF mitigation. Storing information in the cookie is
convenient but it isn't without its risks.

~~~
Patrick_Devine
That kind of defeats the purpose of what's being proposed. Why wouldn't you
just store all of the data in memcache instead of just the key? If you lost
the memcache you're losing all of your sessions either way.

One way you could get around it would be some kind of time based key like an
RSA token. That way each of the servers would know all of the tokens a priori
and you only accept that token for a limited period of time. Not perfect, but
you still benefit from not being tied to your database.

------
EGreg
Looks like this is only useful for storing objects related to a single session
of a user. If you have more than one device accessing the same data on a
server, the server needs to persist the data between requests.

However, it would be interesting to get rid of the client/server dichotomy and
use WebRTC between clients.

------
gburt
Is this use of MD5 subject to the known length extension attack? If so, what
would a better alternative use for an HMAC hash?

Discussed here:
[http://tools.ietf.org/html/rfc6151](http://tools.ietf.org/html/rfc6151)

~~~
the_mitsuhiko
The articles recommends using a form of HMAC and not MD5 directly. The first
code example is just a basic example of what the general concept behind is.

~~~
lucian1900
I guess this is yet another reminder that the first example sticks (waterfall
model).

------
derefr
In other words, the "signed-secret cookie" session-store approach of Rails et
al, but for data bigger than a user ID.

