Re: [Dibs-discussion] Congrats & some problems

[Christian S. <dib...@cs...>]

On Wed, Sep 22, 2004 at 10:04:09AM -0400, Emin Martinian wrote:
...
> > Actually, it is not clear to me why the distinction between active
> > and passive is needed at all.  Can't DIBS figure this out on its own
> > and operate on a best effort basis?
> 
> Basically, if A is behind a firewall and peering with B, then you
> don't want B constantly trying (and failing) to connect to A.  The
> reason is that in trying to connect to A, B has to wait for a time and
> this creates a bottleneck.  

You mean, it keeps the single threaded daemon waiting for 10sec or so?
Where exactly lies the problem?  That the daemon does not reply to other
requests during this time?  Naively, I'd assume that's not really a
problem for the daemon process (even if it stays single-threaded which, I
think, is a good idea for now) especially if the daemon would use some
kind of truncated binary backoff schedule for its attempts.

However, I can under stand that DIBS wants to be able to detect and
exclude the case where both peers are passive, because that's a
deadlock.  I wouldn't really know how to nicely put this into the UI
unless we would implement a testing feature or such.

BTW, is my impression correct that you tried to keep all concurrency
issues a simple as possible by sequentializing everything with a "big"
database lock? 

...
> By this I'm guessing you mean that it doesn't make sense to put 3
> copies of the same thing on Peter's box.  I would agree with you but
> claim that the problem is not with DIBS but with the fact that you
> only have one trading partner.  If you only want to have a small
> number of trading partners, you could reduce redundantPieces
> appropriately. 

Ok, so from DIBS POV this was a misconfiguration, but from a UI POV it
should at least warn about it and it should simply not store redundant
information on the same host since the unit of redundancy is "pieces on
_different_ hosts".

> > This experience also makes me believe that DIBS tries to distribute a
> > file over all available peers.  So, if I cooperate with 10 peers then my
> > files are split in 10 including the 2 redundant copies.  Is that
> > right?
> 
> DIBS first splits a file so that no piece is greater than the
> kbPerFile limit.  Then it adds redundant pieces based on the
> redundantPieces variable.  Then it tries to give each piece to a
> separate peer if possible.

Ah, let me see if I understand this:

In the above example of 10 peers with redundancy 2 and kbPerFile = 1MB
the result would be that all files smaller than 1MB are "redundanized"
(better word?) to three equal-sized copies and these three copies/pieces
are randomly distributed on different hosts.  Furthermore, each of these
copies suffices to reconstruct the file.  Is this correct?

> The reasoning behind this is as follows.
> 
> 1.  Very large files are annoying for a number of reasons (take longer
>     to transmit, take longer to verify, can make things run out of
>     memory, etc.).  The solution is to have the kbPerFile variable
>     cause large files to be split up.  This is independent of how 
>     many peers you have and how much redundancy you want.

Agreed.

> 2.  The whole point of DIBS is robustness to failures, i.e., you want
>     to be able to recover your data even if X peers fail.  The
>     solution is to generate X redundant pieces which DIBS attempts to
>     store with different peers.  This is independent of the number of
>     peers you have and issue 1 above.

Hmm, I don't know if I agree.  It depends on if I understood you
correctly above.  We'll see...

...
> > Even not verifying at all seems to be a better option! 
> 
> Yes, that is something worth considering.  The issue with that however
> is how would you prevent untrusted people from storing stuff with you?

You mean untrusted people sending data from one of your _known_ peers,
right?

...
> As a software developer, I find releasing less than perfect code
> somewhat disturbing.  Ideally, I would like to have the time to make
> things really solid before letting it out.  Realistically, though, if
> I tried to develop DIBS in isolation I would miss out on a lot of the
> feedback and encouragement which is essential to producing good
> software. 

I feel ya. :)

> To summarize, let me say that I understand your frustration with poor
> documentation and features that don't work as you want them to.  I get
> frustrated with it too.  I hope to fix these issues as soon as
> possible, but life is busy.

Yep.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F