Re: `libpeer' build problem

[Ludovic Courtès]

Hi,

On Tue, Feb 01, 2005 at 07:41:30PM +0100, Johan Rydberg wrote:
> Hi.  Thanks for you bug report.  Frankly, I'm quite surprised that
> someone even knew about libpeer.  How did you find it?  Through
> the p2p-hackers mailing list?

Right, googling and looking at the archives of `p2p-hackers'.  See,
libpeer's already famous!  ;-)

> Yes I know.  I planned to fix that, but other things got in the way.
> Thanks for the patch.
> 
> I'm thinking about removing the requirement to use `liboop'.  Even
> though it is a great event abstraction layer, it does not fit all my
> needs.  I'll most likely break out the event code into a separate
> "driver" so users of the library can adopt it to their special need.
> I'll most likely provide default drivers for liboop, glib and maybe
> even libkevent.

Did you consider using GNet (http://gnetlibrary.org)?  It seems to be
well designed, but maybe it's overkill.  And it doesn't honor the GCS
too.

> I'm also thinking about refactoring the network code so that I doesn't
> use the socket API directly.  That would make it possible to write a
> simple simulator that can be used to test libpeer, which could be
> really useful.

Yeah, that would be really nice indeed.

> There are also some other code (peer-conn.c) that needs to be
> re-written to make this possible, but that would be a minor issue.
> 
> I had some crazy idea the other night about using GnuTLS on top of it
> all, to provide some form of integrity.  I'm not sure how that would
> effect the performance, though.  Esp when making new connections
> (generating large random keys tend to be rather slow.)

I'm not sure it would be useful.  Usually, data travelling through the
overlay network are going to be encrypted already and they may contain
error detection codes too (e.g. CHK-encoded file blocks).

> Writing a DHT on top of libpeer should be quite easy.  Actually, I
> wrote a small one to test the library (src/test-3.c)  It has some
> flaws; for example it does not cache lookup results on the way back
> from the root node.

Yes, I hadn't looked into it.  I was actually thinking about a framework
allowing to compose algorithms such as Rabin fingerprints, CHK-encoding,
zlib compression, creation of "inode" trees as in Venti [1] and the
likes.

I haven't started playing with libpeer so far.  I hope to do so soonish.

Thanks!
Ludovic.

[1] http://www.cs.bell-labs.com/sys/doc/venti/venti.html