Re: [GNUnet-developers] Re: What's next (was: Fwd: Asymmetric load patch)

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 31 July 2002 06:21 pm, Igor Wronsky wrote:
> On Sun, 28 Jul 2002, Christian Grothoff wrote:
> > > #NOISE     received:     39470k send:    107306k
> > > #octets    received:     61633k send:    143987k
> >
> > What can be done?
>
> Glenn suggested multiple packet sizes. Here's another similar
> idea. Sometime ago I asked in some private mail if gnunet
> could push content around. Currently its just pulling. I don't
> think the economics part of that ever got justified, but anyway
> here's another chance for pushing.
>
> When padding with noise, pad with content instead. That is,
> for each node in routing table, create incoming and outgoing
> scratch buffers. When padding and scratch is empty, read some
> content block to scratch. Pad outgoing packet with
> START flag, block hash, index in scratch and as much content as
> fits. On next packet, use CONT flag and pad with content and
> scratch index. For last piece, use END flag. The target node
> fills its own scratch as the pieces arrive (as different
> paddings) and when complete, verifies hash and stores it
> to disk if it decides to do so. Clear scratch on both ends.

This would work, except that you essentially have the same problems as
with fragmentation. Handle out-of-order, duplicates, lost packets, and the 
additional 128 kb of memory for 128 of "scratch" buffers. Also you'll have 
quite a bit more copying of data in memory (may not be that important). 

As I said before, there are many things that can be done, but writing good, 
clean code that deals with all cases nicely is part of the challenge. Btw, 
since we're already going straight for 3 MB, I'd guess the additional memory 
is not the issue -- even if we want to go say '16 k' scratch buffers, 1.6 MB 
is not *that* bad if it can safe a lot of bandwidth.

> What content to pad? What to store? Perhaps high priority content
> and/or content close to destination could be sent. Perhaps
> content could be stored atleast with low priority when there's
> free space.

I'd think the best content to send would be
a) content that has been requested by that node 
b) content that was recently requested by anybody
c) content with a very low priority locally that we're about
    to discard

Note that we can also padd with HELO messages, potentially reducing the 
(already very small) overhead that heloexchange.c produces.

> This scheme would atleast help integrating new (empty)
> activemigrative nodes to the network and instead of noise,
> transmit something that might be useful.

True. Note that this is still an orthogonal solution to scheduling queries for 
more appropriate nodes to avoid padding with noise (or content for that 
matter). Both solutions could be combined (can you see the pile of bugs that 
would result from that? :-)

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9SK/h9tNtMeXQLkIRAtyaAKCrPFDgyn+LiJjTwvzSFLkTelcErACfXBnb
gyuEctaDYVA5Oej8fbfKqUg=
=yH71
-----END PGP SIGNATURE-----