blocks-development — Main mailing list for Blocks

RE: [Blocks-development] Reducing broadcast messages to ~5bytes

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] Reducing broadcast messages to ~5bytes
>Date: Fri, 18 Aug 2000 18:01:30 +0200
>
>On 18 Aug 2000, at 14:06, Blat Froop wrote:
>
> > Comments?
>
>Good idea, but remember that broadcasts will get more payload in the
>future (keys, digital signatures, nicknames, ratings). So the ID of
>the advert would have to be a hash of this additional data as well.
>
>Regards,
>Erik

As long as the advert ID is unique for that advert Im not sure that
the rest matters. If the other info changes (other than routing
info) it is a new advert and should have a new ID. Author key,
signature, nick, etc... should always be static. Ratings are
another issue though and probably need more thought.

>From: "Spencer Jr., Michael" <sp...@ac...>
>To: "'Erik Moeller'" <mo...@sc...>,        
>blo...@li...
>Subject: RE: [Blocks-development] Reducing broadcast messages to ~5bytes
>Date: Fri, 18 Aug 2000 11:21:11 -0500
>
>Hmm...after thinking about this more closely...
>
>it takes 4 bits to transmit one routing table hop.  A four-hop route would
>take two bytes.

Thats for a 16 connections per node Blocknet. Im still playing with
the idea of using less/more connections (and yes, > 16 does have
some real benefits... reducing hops, more resilient to outages
etc :-)

>
>So if those two bytes are unique to the routing table, the other three 
>bytes
>would have to be unique to the file.

I was thinking of...

byte0 => message type 'A' (or whatever)
byte1 => bits 31-24 of advert ID
byte2 => bits 23-16 of advert ID
byte3 => bits 15-8  of advert ID
byte4 => bits  7-0  of advert ID


>
>Can we reasonably assume that 3 bytes can identify all the files on the
>network 'uniquely enough'?  Hash collisions will cause some files to 
>inhibit
>the spread of other files...

All we have to worry about is if 4 bytes is enough to identify
an new advert from the ones transmitted within the
last ~5 minutes.

>
>Perhaps the extra information, keys, signatures, ratings, whatever...could
>be passed as separate messages.  "I have a new signature for that file you
>already know about" "I have a new route for that file you already know
>about"...
>
>
>On an unrelated note, I would like to start creating and testing that
>web-of-trust thing soon.  If there are any interested people out there who
>would like to download, learn, and use the command-line GPG binary for 
>their
>favorite OS...and follow along in a HOWTO to use the web-of-trust, slowly
>and by hand...please email me at m...@ms....  I'll need testers.  :)

I want to try and get on a bit with V0.16. Ive got big files working,
but need to upgrade the caching logic and get sticky files working.
But the WoT offers hope in some pretty hopeless areas, so keep
me posted. Perhaps I can help out directly when things get a bit
further advanced?

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

RE: [Blocks-development] Reducing broadcast messages to ~5bytes

[Spencer Jr., M. <sp...@ac...>]

Hmm...after thinking about this more closely...

it takes 4 bits to transmit one routing table hop.  A four-hop route would
take two bytes.

So if those two bytes are unique to the routing table, the other three bytes
would have to be unique to the file.

Can we reasonably assume that 3 bytes can identify all the files on the
network 'uniquely enough'?  Hash collisions will cause some files to inhibit
the spread of other files...

Perhaps the extra information, keys, signatures, ratings, whatever...could
be passed as separate messages.  "I have a new signature for that file you
already know about" "I have a new route for that file you already know
about"...


On an unrelated note, I would like to start creating and testing that
web-of-trust thing soon.  If there are any interested people out there who
would like to download, learn, and use the command-line GPG binary for their
favorite OS...and follow along in a HOWTO to use the web-of-trust, slowly
and by hand...please email me at m...@ms....  I'll need testers.  :)

--Michael Spencer
bl...@ms...


-----Original Message-----
From: Erik Moeller [mailto:mo...@sc...]
Sent: Friday, August 18, 2000 11:02 AM
To: blo...@li...
Subject: Re: [Blocks-development] Reducing broadcast messages to ~5bytes


On 18 Aug 2000, at 14:06, Blat Froop wrote:

> Comments?

Good idea, but remember that broadcasts will get more payload in the 
future (keys, digital signatures, nicknames, ratings). So the ID of 
the advert would have to be a hash of this additional data as well.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] Reducing broadcast messages to ~5bytes

[Erik M. <mo...@sc...>]

On 18 Aug 2000, at 14:06, Blat Froop wrote:

> Comments?

Good idea, but remember that broadcasts will get more payload in the 
future (keys, digital signatures, nicknames, ratings). So the ID of 
the advert would have to be a hash of this additional data as well.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

RE: [Blocks-development] Reducing broadcast messages to ~5bytes

[Spencer Jr., M. <sp...@ac...>]

Suppose I've just received one of these 5-byte broadcasts...do I go ahead
and propogate that 5-byte broadcast to my other connections?  Or should I
wait until I've retrieved the 'full content' of the broadcast before sending
the 5-bytes on?

That seems to offer a better way to discern Eve clients (I like that term :)
) -- if someone's sending you lots of 5-byte message ID's, but doesn't
respond within a reasonable amount of time if you ask for the content of the
ID's, they're obviously a bogus connection and should be dropped.

On a related note...what are our thoughts on removing bogus clients from the
network?  On a network level, I guess we could detect bogus messages and
drop clients that way...

and on a file level and content level, I guess people could vote bad clients
off the island^H^H^H^H^H^Hnetwork.  :)

Well...the riverboat casino I've been riding has just returned to dock, and
I've got to go reconnect the fiber and turn off the wireless ethernet.  Very
good ideas, PG.  :)

--Michael Spencer
bl...@ms...

> -----Original Message-----
> From:	Blat Froop [SMTP:pet...@ho...]
> Sent:	Friday, August 18, 2000 9:06 AM
> To:	blo...@li...
> Subject:	[Blocks-development] Reducing broadcast messages to ~5bytes
> 
> Ive just had a brainstorm myself. We might be able to
> reduce the size of duplicate broadcast messages to
> 5 bytes or so.
> 
> Instead of simply sending broadcast messages to all
> connections, and ignoring messages received which are
> duplicates of recent messages, we could 'ask' the servers
> we're connected to if they would like to receive the
> message by sending them just the message ID... in fact
> a portion of the messade ID might do (say 4 or 8 bytes),
> effectively eliminating any duplicate broadcast messages
> throught the entire Blocknet. This would seem to offer
> near-optimal broadcast routing.
> 
> Comments?
> 
> ttfn
> 
> PG.
> 
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

RE: [Blocks-development] crazy anti-flooding idea:

[Spencer Jr., M. <sp...@ac...>]

Hmm...true, that makes sense.

Oh well.  Back to day 3 of my "Teach yourself C for Linux Programming in 21
Days" book, and chapter 1 of "Linux Socket Programming By Example"  At this
rate, I should be capable of contributing code to Blocks, oh, sometime next
year.  *kidding*

(Actually, I already know C++ rather well...I just need help and experience
tying my C++ experience to an API.  That C for Linux in 21 days book seems
to be focusing on C rather than on Linux.  Oh well.  :) )

--Michael Spencer
bl...@ms...

> -----Original Message-----
> From:	Blat Froop [SMTP:pet...@ho...]
> Sent:	Friday, August 18, 2000 9:01 AM
> To:	blo...@li...
> Subject:	Re: [Blocks-development] crazy anti-flooding idea:
> 
> >From: "Spencer Jr., Michael" <sp...@ac...>
> >To: blo...@li...
> >Subject: [Blocks-development] crazy anti-flooding idea:
> >Date: Fri, 18 Aug 2000 08:37:10 -0500
> >
> >CPU-bind the Eve clients!  ^_^
> >
> >Is there some kind of cryptographic function we can require to be used
> with
> >all broadcast messages passed, which is difficult to create (perhaps ~5
> >seconds of P3-500's processing to encode) but not difficult to decode?
> >
> >Could this be reversed, so someone could create a large number of packets
> >that are more difficult to decode than to encode (even though they'd all
> be
> >bogus packets) so they'd CPU-bind the good client instead?
> >
> >Do we want to require encoding only for people who originate the packets,
> >where packet routers just pass the data along?  Or should all broadcast 
> >data
> >(which should be protected in a special way) be encoded every time it
> gets
> >routed?
> >
> >What do you guys think?
> 
> I think the CPU requirement would kill the Blocknet. If this is
> designed to limit spam, then it would also limit normal throughput,
> and in 6 months time some script kiddie with a hacked server farm, beowulf
> 
> cluster, or with the latest $$$ box would be able to
> out perform the Blocknet. Also, for sending broadcast messages
> we would have to choose a func which was tragetted at taking 5
> mins for 16 connections. A spammer would simply send it only
> to one connection in order to flood faster... you can go on and on
> with this.
> 
> Good but of brainstorming, but I dont think this ones got much
> legs. :-)
> 
> ttfn
> 
> PG.
> 
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] Reducing broadcast messages to ~5bytes

[Blat F. <pet...@ho...>]

Ive just had a brainstorm myself. We might be able to
reduce the size of duplicate broadcast messages to
5 bytes or so.

Instead of simply sending broadcast messages to all
connections, and ignoring messages received which are
duplicates of recent messages, we could 'ask' the servers
we're connected to if they would like to receive the
message by sending them just the message ID... in fact
a portion of the messade ID might do (say 4 or 8 bytes),
effectively eliminating any duplicate broadcast messages
throught the entire Blocknet. This would seem to offer
near-optimal broadcast routing.

Comments?

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] crazy anti-flooding idea:

[Blat F. <pet...@ho...>]

>From: "Spencer Jr., Michael" <sp...@ac...>
>To: blo...@li...
>Subject: [Blocks-development] crazy anti-flooding idea:
>Date: Fri, 18 Aug 2000 08:37:10 -0500
>
>CPU-bind the Eve clients!  ^_^
>
>Is there some kind of cryptographic function we can require to be used with
>all broadcast messages passed, which is difficult to create (perhaps ~5
>seconds of P3-500's processing to encode) but not difficult to decode?
>
>Could this be reversed, so someone could create a large number of packets
>that are more difficult to decode than to encode (even though they'd all be
>bogus packets) so they'd CPU-bind the good client instead?
>
>Do we want to require encoding only for people who originate the packets,
>where packet routers just pass the data along?  Or should all broadcast 
>data
>(which should be protected in a special way) be encoded every time it gets
>routed?
>
>What do you guys think?

I think the CPU requirement would kill the Blocknet. If this is
designed to limit spam, then it would also limit normal throughput,
and in 6 months time some script kiddie with a hacked server farm, beowulf 
cluster, or with the latest $$$ box would be able to
out perform the Blocknet. Also, for sending broadcast messages
we would have to choose a func which was tragetted at taking 5
mins for 16 connections. A spammer would simply send it only
to one connection in order to flood faster... you can go on and on
with this.

Good but of brainstorming, but I dont think this ones got much
legs. :-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] crazy anti-flooding idea:

[Spencer Jr., M. <sp...@ac...>]

CPU-bind the Eve clients!  ^_^

Is there some kind of cryptographic function we can require to be used with
all broadcast messages passed, which is difficult to create (perhaps ~5
seconds of P3-500's processing to encode) but not difficult to decode?

Could this be reversed, so someone could create a large number of packets
that are more difficult to decode than to encode (even though they'd all be
bogus packets) so they'd CPU-bind the good client instead?

Do we want to require encoding only for people who originate the packets,
where packet routers just pass the data along?  Or should all broadcast data
(which should be protected in a special way) be encoded every time it gets
routed?

What do you guys think?

--Michael Spencer
bl...@ms...

Re: [Blocks-development] comments on the Blocks architecture...

[Blat F. <pet...@ho...>]

>From: "Ben Houston" <be...@ex...>
>To: "Blat Froop" <pet...@ho...>,        
><blo...@li...>
>Subject: [Blocks-development] comments on the Blocks architecture...
>Date: Wed, 16 Aug 2000 18:13:50 -0400
>
>Hi PG,
>
> > so, servers with < 7 connections always react, while servers
> > with 14 connections have a 20% chance of trying to connect.
> > The new server should accept on a first-come-first-served
> > basis.
>
>Why do you have to many connections?  Did you know that in a truly randomly
>connected graph you only need only around 2.5 - 3 connections per node to
>guarantee that the network is connected?  You could go for 4 or 5 if you
>really wanted to be secure.

Is 16 too many? I have no real idea why I chose 16 originally. Its
easily changed up or down, so this is something we can tune later
on. I guess I wanted a number that was big enough for the blocknet
to survive a network outage without becoming fragmented, and also
allow end to end routing in a small number of hops (very important
for relay netorks) but small enough so that servers can cope with
duplicate ads. I would currently guess that connections per
server would average around ~12 and that each advert will be
received ~4 times.

Im actually considering wether or not a larger number of
connections might make sense. This would have the benefit of
reducing end to end hops and allow more interconnections,
and instead of sending adverts directly (at ~120bytes each),
the server could just send the advert ID (at 16bytes, or
even half the advert ID at 8 bytes, or a quater at 4bytes)
and allow the destination server to 'request' the advert if
it hasnt already received it. This slight increase in complexity
might dramtically reduce broadcast traffic.

Still, just thinking out loud for now :-)

>
> > 'File advertisements' are broadcast through out the
> > network. Your Blocks application needs to be running
> > to see them. When you do a 'search' you are actually
> > searching the local list maintained by your Blocks
> > application, searches are never broadcast.
>
>Okay, so I guess the point of this is that you encourage
>people to remain on the network for longer periods of times
>since it increases the number of files that they can see.
>
>When a new client connects do you pass along the index of files
>of the clients that it connects to?

Over 11 hours or so they are sent ~10% of the servers advert
cache. Currently 90+% of adverts from multiple servers will
be duplicates since they all send the same 10% of cache. I
guess we could send a random 1/3 of the first 30% or so and
this would be much more beneficial, but nothing is planned for now.

>
>How do you track which files have dropped off the network because
>those clients left the network?

When servers disconnect (no clients in Blocks :-) a 'bad route'
message is broadcast throughout the blocknet and all the servers
mark the appropriate files in their advert cache as being
unavailable. It actually uses a slightly less correct but much more 
efficient mechanism for doing this by maintining
a 'bloacklist' of bad routes, but the effect is the same.

>
> > Other servers
> > then choose to connect to the new server depending on how many
> > connections they have, and a PRNG.
>
>What's a PRNG?
>
>Also how do you protect against someone broadcastings a bunch of lies
>instead of a real file index?

See Michael's post. Authentication is the only obvious suggestion
suggested so for, using a Web-Of-Trust to maintain relative
anonymity.

>
> > Perhaps Michael & Erik's simulator will clarify this.
>
>Neat, I'm writing a simulator too.  To start with I've created
>a few classes for creating random graphs and measuring
>the connectivity. ...it should be really easy to figure out:
>   http://www.exocortex.org/~ben/graphtools_v01.zip
>
>I'm planning on making a multithreaded simulator once I get some time that
>will simulate the behavior of clients rather than just a weighted graph.  I
>hope to make a visualizer for it a la NetViz:
>   http://www.exocortex.org/netviz
>

Wow! purdy pics :) I think the Blocks simulator was intended to
produce text output, but I suppose an 3D OpenGL application would
suffice at a push ;-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] comments on the Blocks architecture...

[Michael S. Jr. <bl...@ms...>]

Hmm...your comment about the number of connections we need makes sense.
Maybe we'll eventually come up with a way to auto-balance the network so we
still have multiple routes to files, but not so many routes that broadcast
traffic is amplified so much.

PRNG == Pseudo Random Number Generator

We're throwing around some interesting ideas that address problems similar
to your scenario.  If someone broadcasts a very large number of bogus
files...well, we don't know they're bogus without actually attempting to
download the files.  There's a fine line between violating someone's right
to advertise lots of little files, and preventing spam.

Possible defenses could be:

*  attempt to download blocks from a small random number of the file adverts
that come across...and drop the originating connection if too many of them
are bogus
*  shape the broadcast bandwidth used by each connection

I really have no idea.  I'd recommend reading about this crazy web-of-trust
idea I've been trying to sell, in the mailing list archives.  (Archive link
is on the top of the page you used to sign up for the mailing list.)  The
Blocks network is very new, but I think we suffer from the same classes of
weaknesses that can kill Gnutella.  Then again, our initial freshmeat.net
announcement was, what, three weeks ago?  :)

WRT that simulator...I have a few ideas for it, but I can't contribute code
yet.  Then again, I've just recently decided to halt wasting any more time
learning C++ for Win32 coding, and my first three Linux programming books
just arrived in the mail.  (Although it seems "C Programming for Linux in 21
Days" was a waste of money -- I'm already quite good with C and C++)

(So basically my role so far has been to suggest elaborate and crazy, yet
very secure, content authentication schemes...but I can't code well enough
to do any of the work.  I need to change that.)

--Michael Spencer
bl...@ms...

----- Original Message -----
From: "Ben Houston" <be...@ex...>
To: "Blat Froop" <pet...@ho...>;
<blo...@li...>
Sent: Wednesday, August 16, 2000 5:13 PM
Subject: [Blocks-development] comments on the Blocks architecture...


> Hi PG,
>
> > so, servers with < 7 connections always react, while servers
> > with 14 connections have a 20% chance of trying to connect.
> > The new server should accept on a first-come-first-served
> > basis.
>
> Why do you have to many connections?  Did you know that in a truly
randomly
> connected graph you only need only around 2.5 - 3 connections per node to
> guarantee that the network is connected?  You could go for 4 or 5 if you
> really wanted to be secure.
>
> > 'File advertisements' are broadcast through out the
> > network. Your Blocks application needs to be running
> > to see them. When you do a 'search' you are actually
> > searching the local list maintained by your Blocks
> > application, searches are never broadcast.
>
> Okay, so I guess the point of this is that you encourage
> people to remain on the network for longer periods of times
> since it increases the number of files that they can see.
>
> When a new client connects do you pass along the index of files
> of the clients that it connects to?
>
> How do you track which files have dropped off the network because
> those clients left the network?
>
> > Other servers
> > then choose to connect to the new server depending on how many
> > connections they have, and a PRNG.
>
> What's a PRNG?
>
> Also how do you protect against someone broadcastings a bunch of lies
> instead of a real file index?
>
> > Perhaps Michael & Erik's simulator will clarify this.
>
> Neat, I'm writing a simulator too.  To start with I've created
> a few classes for creating random graphs and measuring
> the connectivity. ...it should be really easy to figure out:
>   http://www.exocortex.org/~ben/graphtools_v01.zip
>
> I'm planning on making a multithreaded simulator once I get some time that
> will simulate the behavior of clients rather than just a weighted graph.
I
> hope to make a visualizer for it a la NetViz:
>   http://www.exocortex.org/netviz
>
> Later,
> -ben houston
> www.exocortex.org/~ben
>
>
> > -----Original Message-----
> > From: Blat Froop [mailto:pet...@ho...]
> > Sent: August 15, 2000 9:45 PM
> > To: be...@ex...; blo...@li...
> > Subject: Re: [Blocks-development] the GRID proposal
> >
> >
> > >From: "Ben Houston" <be...@ex...>
> > >To: <blo...@li...>
> > >Subject: [Blocks-development] the GRID proposal
> > >Date: Tue, 15 Aug 2000 20:35:52 -0400
> > >
> > >Hi,
> > >
> > >A few people (Jonathan Byron and Michael Spencer) have mentioned in the
> > >last
> > >days the BLOCKS project.  I thought that I would drop by and
> > tell you about
> > >my self organizing protocol that I am developing:
> > >
> > >Check it out at: http://www.exocortex.org/grid.html
> > >
> > >And yesterday I developed the start of a growing preference algorithm
in
> > >order to grow it in a manner that will maintain coherence:
> > >http://www.exocortex.org/growing_v01.ppt
> > >
> > >Although I always talk in two dimensions (planar) all the algorithms
are
> > >scalable to any dimension greater than one.
> > >
> > >I'm working full time right now so I do not have time to polish these
> > >ideas.
> > >Also we are in a very fast moving field (distributed file sharing,
> > >distributed applications) so I want to get them out as quickly
> > as possible.
> >
> > Thanks for the input. I dont know much about GNUtella other than
> > that it broadcasts searches. I would have thought that it does
> > a similar sort of routing as Blocks does with file advertisements
> > (searches are not transmitted in Blocknets).
> >
> > Each Blocks server has upto 16 connections to other servers, and
> > when a new file is uploaded, it is given a unique ID (which is
> > placed in a blocklist) an advertisement is send to each
> > connection. If the advert ID is not blacklisted it is forwarded
> > to all connections (apart from the one it came from), and so
> > on for upto 6 hops (its a bit like the old flood fill algorithm).
> >
> > The interconnection logic in blocks is currently quite trivial,
> > when a new server connects to the Blocknet, the server it connects
> > to advertises the new server to all connections. Other servers
> > then choose to connect to the new server depending on how many
> > connections they have, and a PRNG.
> >
> > The formulae works a bit like this...
> >
> > connect to new server if (16-N)*10 > rand()%100
> > where N is the number of current connections.
> >
> > so, servers with < 7 connections always react, while servers
> > with 14 connections have a 20% chance of trying to connect.
> > The new server should accept on a first-come-first-served
> > basis.
> >
> > This hasnt been tuned but seems to work well enough for
> > small Blocknets. Its unclear what will happen with massive
> > Blocknets. Perhaps Michael & Erik's simulator will clarify this.
> >
> > Blocks also relies on each 'connection' to be indistinguishable
> > from all the other ones so that statistical analysis of the
> > Blocknet cannot predict the location in the Blocknet of the
> > originator of published files. This makes designing Blocknet
> > topologies particularly difficult since servers are restricted
> > in the amount of information they are allowed to have about
> > the topology.
> >
> > All comments welcome :-)
> >
> > ttfn
> >
> > PG.
> >
> >
> >
> > ________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> >
>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] comments on the Blocks architecture...

[Ben H. <be...@ex...>]

Hi PG,

> so, servers with < 7 connections always react, while servers
> with 14 connections have a 20% chance of trying to connect.
> The new server should accept on a first-come-first-served
> basis.

Why do you have to many connections?  Did you know that in a truly randomly
connected graph you only need only around 2.5 - 3 connections per node to
guarantee that the network is connected?  You could go for 4 or 5 if you
really wanted to be secure.

> 'File advertisements' are broadcast through out the
> network. Your Blocks application needs to be running
> to see them. When you do a 'search' you are actually
> searching the local list maintained by your Blocks
> application, searches are never broadcast.

Okay, so I guess the point of this is that you encourage
people to remain on the network for longer periods of times
since it increases the number of files that they can see.

When a new client connects do you pass along the index of files
of the clients that it connects to?

How do you track which files have dropped off the network because
those clients left the network?

> Other servers
> then choose to connect to the new server depending on how many
> connections they have, and a PRNG.

What's a PRNG?

Also how do you protect against someone broadcastings a bunch of lies
instead of a real file index?

> Perhaps Michael & Erik's simulator will clarify this.

Neat, I'm writing a simulator too.  To start with I've created
a few classes for creating random graphs and measuring
the connectivity. ...it should be really easy to figure out:
  http://www.exocortex.org/~ben/graphtools_v01.zip

I'm planning on making a multithreaded simulator once I get some time that
will simulate the behavior of clients rather than just a weighted graph.  I
hope to make a visualizer for it a la NetViz:
  http://www.exocortex.org/netviz

Later,
-ben houston
www.exocortex.org/~ben


> -----Original Message-----
> From: Blat Froop [mailto:pet...@ho...]
> Sent: August 15, 2000 9:45 PM
> To: be...@ex...; blo...@li...
> Subject: Re: [Blocks-development] the GRID proposal
>
>
> >From: "Ben Houston" <be...@ex...>
> >To: <blo...@li...>
> >Subject: [Blocks-development] the GRID proposal
> >Date: Tue, 15 Aug 2000 20:35:52 -0400
> >
> >Hi,
> >
> >A few people (Jonathan Byron and Michael Spencer) have mentioned in the
> >last
> >days the BLOCKS project.  I thought that I would drop by and
> tell you about
> >my self organizing protocol that I am developing:
> >
> >Check it out at: http://www.exocortex.org/grid.html
> >
> >And yesterday I developed the start of a growing preference algorithm in
> >order to grow it in a manner that will maintain coherence:
> >http://www.exocortex.org/growing_v01.ppt
> >
> >Although I always talk in two dimensions (planar) all the algorithms are
> >scalable to any dimension greater than one.
> >
> >I'm working full time right now so I do not have time to polish these
> >ideas.
> >Also we are in a very fast moving field (distributed file sharing,
> >distributed applications) so I want to get them out as quickly
> as possible.
>
> Thanks for the input. I dont know much about GNUtella other than
> that it broadcasts searches. I would have thought that it does
> a similar sort of routing as Blocks does with file advertisements
> (searches are not transmitted in Blocknets).
>
> Each Blocks server has upto 16 connections to other servers, and
> when a new file is uploaded, it is given a unique ID (which is
> placed in a blocklist) an advertisement is send to each
> connection. If the advert ID is not blacklisted it is forwarded
> to all connections (apart from the one it came from), and so
> on for upto 6 hops (its a bit like the old flood fill algorithm).
>
> The interconnection logic in blocks is currently quite trivial,
> when a new server connects to the Blocknet, the server it connects
> to advertises the new server to all connections. Other servers
> then choose to connect to the new server depending on how many
> connections they have, and a PRNG.
>
> The formulae works a bit like this...
>
> connect to new server if (16-N)*10 > rand()%100
> where N is the number of current connections.
>
> so, servers with < 7 connections always react, while servers
> with 14 connections have a 20% chance of trying to connect.
> The new server should accept on a first-come-first-served
> basis.
>
> This hasnt been tuned but seems to work well enough for
> small Blocknets. Its unclear what will happen with massive
> Blocknets. Perhaps Michael & Erik's simulator will clarify this.
>
> Blocks also relies on each 'connection' to be indistinguishable
> from all the other ones so that statistical analysis of the
> Blocknet cannot predict the location in the Blocknet of the
> originator of published files. This makes designing Blocknet
> topologies particularly difficult since servers are restricted
> in the amount of information they are allowed to have about
> the topology.
>
> All comments welcome :-)
>
> ttfn
>
> PG.
>
>
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>

Re: [Blocks-development] the GRID proposal

[Blat F. <pet...@ho...>]

>From: "Ben Houston" <be...@ex...>
>To: <blo...@li...>
>Subject: [Blocks-development] the GRID proposal
>Date: Tue, 15 Aug 2000 20:35:52 -0400
>
>Hi,
>
>A few people (Jonathan Byron and Michael Spencer) have mentioned in the 
>last
>days the BLOCKS project.  I thought that I would drop by and tell you about
>my self organizing protocol that I am developing:
>
>Check it out at: http://www.exocortex.org/grid.html
>
>And yesterday I developed the start of a growing preference algorithm in
>order to grow it in a manner that will maintain coherence:
>http://www.exocortex.org/growing_v01.ppt
>
>Although I always talk in two dimensions (planar) all the algorithms are
>scalable to any dimension greater than one.
>
>I'm working full time right now so I do not have time to polish these 
>ideas.
>Also we are in a very fast moving field (distributed file sharing,
>distributed applications) so I want to get them out as quickly as possible.

Thanks for the input. I dont know much about GNUtella other than
that it broadcasts searches. I would have thought that it does
a similar sort of routing as Blocks does with file advertisements
(searches are not transmitted in Blocknets).

Each Blocks server has upto 16 connections to other servers, and
when a new file is uploaded, it is given a unique ID (which is
placed in a blocklist) an advertisement is send to each
connection. If the advert ID is not blacklisted it is forwarded
to all connections (apart from the one it came from), and so
on for upto 6 hops (its a bit like the old flood fill algorithm).

The interconnection logic in blocks is currently quite trivial,
when a new server connects to the Blocknet, the server it connects
to advertises the new server to all connections. Other servers
then choose to connect to the new server depending on how many
connections they have, and a PRNG.

The formulae works a bit like this...

connect to new server if (16-N)*10 > rand()%100
where N is the number of current connections.

so, servers with < 7 connections always react, while servers
with 14 connections have a 20% chance of trying to connect.
The new server should accept on a first-come-first-served
basis.

This hasnt been tuned but seems to work well enough for
small Blocknets. Its unclear what will happen with massive
Blocknets. Perhaps Michael & Erik's simulator will clarify this.

Blocks also relies on each 'connection' to be indistinguishable
from all the other ones so that statistical analysis of the
Blocknet cannot predict the location in the Blocknet of the
originator of published files. This makes designing Blocknet
topologies particularly difficult since servers are restricted
in the amount of information they are allowed to have about
the topology.

All comments welcome :-)

ttfn

PG.



________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] the GRID proposal

[Ben H. <be...@ex...>]

Hi,

A few people (Jonathan Byron and Michael Spencer) have mentioned in the last
days the BLOCKS project.  I thought that I would drop by and tell you about
my self organizing protocol that I am developing:

Check it out at: http://www.exocortex.org/grid.html

And yesterday I developed the start of a growing preference algorithm in
order to grow it in a manner that will maintain coherence:
http://www.exocortex.org/growing_v01.ppt

Although I always talk in two dimensions (planar) all the algorithms are
scalable to any dimension greater than one.

I'm working full time right now so I do not have time to polish these ideas.
Also we are in a very fast moving field (distributed file sharing,
distributed applications) so I want to get them out as quickly as possible.

Take care,
-ben houston
www.exocortex.org/~ben

[Blocks-development] Big Files & Slow Upload/Writing File bug.

[Blat F. <pet...@ho...>]

Ive finally got large (>250Mb) file support working after a fashion,
and this will form part of V0.16. The new limit should be 2Gb,
but there will probably be bugs to iron out for files > 1Gb. Still,
this is a big improvement allowing CD size files to be uploaded.

Also, while testing this I noticed that it took ages to upload
massive files, while it seems to take much less time to proxy
or download the files. This was strange because both these
operations need to write the file to cache so it couldnt simply
be down to disk write speed. It turns out that Blocks had a
bug which introduced an artificial limit of 20 block reads or
writes per second (20x64Kb => ~1.28Mb/sec) when inserting or
reconstructing files. This bug has now been removed and lets
uploading take place as fast as your disk will allow. However,
the agressive reading/writing to disk can make your system
grind a bit even though its for less overall time, so there
may have to be some artificial throttling to allow the user to
do other stuff while things are uploading. I think I'll just
leave it at full speed for V0.16 tho.

Now, all thats required before V0.16 is...

1) Fix routing logic to stop huge files trashing everyones
   caches.
2) Sticky files (its more difficult than it looks :-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Ratings & Identities

[Erik M. <mo...@sc...>]

Let me give you a summary of my mid-term vision of a simple 
WoT/spamming/flooding protection.

Ratings & identities
--------------------

- Adverts are routed exponentially: 1->10->100 etc., Gnutella like. 
This is a great opportunity for spamming. So we have to concentrate 
on blocking false adverts to prevent index flooding/corruption.
- A single advert includes:
	1 filename
	n routes
	n ratings
	n identities
	ratings = spam, interesting, good, enjoyable etc. (predefined)
	identities = public key, digital signature, nickname
	first identity = always owner, other identities = third party
	ratings
- I have a limited number of adverts per second that I can route.
  Anything that exceeds this bandwidth is placed in a queue. This
  is not simply a first in, first out queue. It utilizes a trust
  metric that is gained from the nicknames.
- When I have downloaded a file, or received an advert, I can rate
	- the owner of the file (nickname) according to the advert
	- the persons who rated the file.
  In fact, I have an "identity manager" that allows me to check
  which files I have downloaded from whom and which ratings
  were distributed by the same person. Example:
		Frank 
		|- [file]   shell.mpg
		|- [file]   fruit.mpg
		|- [rating] mega.jpg score:5
- I can now give Frank an rating, any integer value, by hitting
  a +/- button.
- The identities and their scores are permanent (not flushed),
  while the files and ratings are flushed with each session.
- Adverts that are put in a queue are prioritized according 
  to 1) the identity of the owner, 2) (if several owners have
  the same score) the attached quality rating (where again
  the "raters" are evaluated to determine the weight of their
  rating)

Note that this is a simple WoT because ratings are independent from 
each other. It's not like in Michael's grand vision where ultimately 
you automatically trust a person because your friend of a friend of a 
friend trusts them. This might be doable by routing the data of the 
identities manager just like adverts, but that's a "nice-to-have" 
feature.

Spamming in a network that has already reached its maximum advert 
bandwidth is practically impossible. On the other hand, users who are 
trusted to deliver quality stuff should always be able to route even 
large file lists. 

-> New users can earn trust by delivering good ratings and offering 
good files.

Prioritization of file transfers:
---------------------------------

- "Upload" bandwidth can be limited both in total and as a
  minimum bandwidth per file (if this is possible). Files
  with high ratings by trusted users could be transferred
  with more bandwidth than other files, and if the maximum
  bandwidth is exceeded (i.e. no new files can be transferred
  without getting below the minimum per file) further requests
  are denied.

-> You can always leech from someone who has got the bandwidth, but 
unless you pay back in the form of ratings or good files, which will 
gain you trust, you will have trouble finding files.

Consequences for Searching:
---------------------------

Of course, the ratings are incredibly helpful if I search files. I 
can not only search by entering keywords, I can also search by 
checking categories, nicknames and/or ratings (ratings & cats take 
hardly any bandwidth--if we work with pre-defined lists, we can get 
256 categories with a single byte of information per advert). 

So I could check "Show me good pop music rated high by Michael" or 
"Show me any good pop music" or maybe later "Show me good files for 
which I have recently received adverts", etc. Or "Show me unrated 
files" to earn some trust by rating them.

Conseqeunces for Content:
-------------------------

While we allow controversial speech etc., spam, kiddie porn and stuff 
like that will be hard to get & distribute -- because these are not 
conform to the viewpoint of the majority of users. That's not 
censorship: If people want it, they can form their own Blocknets with 
their own "value system". Any BlockNet will be a reflection of the 
views of its moral majority. 

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

RE: [Blocks-development] Future Direction For Blocks

[Spencer Jr., M. <sp...@ac...>]

I hope I'll have more to say on the WoT stuff soon also.

But I'm lazy.  Or at least...it's a bit depressing to see the network die
down because of the version incompatibilities and all that.  Hopefully when
0.16 comes out, we'll all be back to normal.  :)

Within a week or so after 0.16 and a healthy network and all that, you
should see some strange-looking crypto files (with long filenames with lots
of hex digits)...and a BLOCKS-Trust-Network-HOWTO out there somewhere.  That
file will be a follow-along description of the web of trust, with step by
step procedures on how to use the web of trust.

If you don't see that after a week or so...please email me and tell me to
get to work.  :)  I get like three emails a day anyway, not counting list
traffic...so your reminder will be appreciated.

--Michael Spencer
bl...@ms...

-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Monday, August 14, 2000 1:04 PM
To: blo...@li...
Subject: Re: [Blocks-development] Future Direction For Blocks


>From: lu...@et...
>To: Erik Moeller <mo...@sc...>,        
>blo...@li...
>Subject: Re: [Blocks-development] Future Direction For Blocks
>Date: Mon, 14 Aug 2000 13:28:34 -0400
>
>* Erik Moeller wrote:
> > Before we go to ratings and authentication, we should clear the
> > scalability issue and possible routing/resuming problems.
>
>Hurm.  Given the mess that Gnutella has become, I think it's very important
>that we make sure that the blocks network is impervious (or at least
>tolerant of) to:
>
>- False announcements, advertising and other Bad data
>- Flooding and other DOS attacks
>- Bogus/incomplete data
>
>It doesn't matter how spiffy the technology is, if it can be abused, it 
>will
>be.  *sigh*

This is true, and Blocks suffers from all these classical problems :(

Possibly Michaels WoT idea might help eleviate some of these issues,
but in the meantime here are some other ideas (off the top of my
head... asbestos underpants are on :-) ...

1) Password lock servers/blocknets... so only 'authorised' people
   can join. This would allow private blocknets which is probably
   desirable anyway, but without WoT I cant see how it can be
   applied to the general anonymous blocknet.

2) Staticstical analysis can detect extreme flooding, but wont
   really help stop short burst flooders or slow flooding.

3) Spammers sending bogus ads are a real pain. Without strong
   authentication there is no way you can trust an advert.
   Explicitly checking the validity of the underlying file
   is infeasible (if not impossible). The only thing I can
   think of that might be appropriate here is some form
   of phyical violence... I wonder if there is a POSIX call
   to send an EM bust through the console like they always
   so in Startrek. I could equip block servers with a DDOS
   autotargetting facility, but that would get misused as
   well... still we can dream ;-)

Hmm... looking back at what Ive just written there doesnt
seem to be much content there :( But, hopefully, Michael
will have more to say on the WoT idea sometime soon.

ttfn

PG.




________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

RE: [Blocks-development] Future Direction: Hardening Blocks

[Spencer Jr., M. <sp...@ac...>]

I have a strange, incomplete idea for the future of Blocks.  I want to
explain what I have so far, and let's discuss this as a group.

If you follow this to the end (gosh you must be bored :) ) then you'll see
where I'm trying to go with this:  network abuse and spam can only be
loosely defined, so we need an adaptive, economic-like system that adjusts
the network in a reactive but automatic way to deliver the greatest benefit
to the most people at the least cost.  Yes, I know that's a tall order -- I
haven't figured out how to do it either.  But maybe as a group, we can come
up with something.

PROJECT GOAL, DEFINED

In a broad and general sense, we want lots of people to be able to use
Blocks to publish and find whatever information they want.  Our system is
unsuccessful when people can't find the files that other people publish --
when information producers and information consumers can't find each other
automatically.

We also know that several layers of protocol are required to bring producers
and consumers together...and some of that protocol is human.  We have
provided the automatic message passing foundation the network is built
on...and a file publishing, broadcasting, and downloading mechanism people
can use to associate filenames with data, and move the data around.  On top
of that is human language and file-naming-sense:  porn will be labelled
something porn-like, mp3's will say something about the song type, anime
episodes will have the series, episode number, etc.

And on top of that is a generic feeling of openness and trust between users:
we can be reasonably certain that people aren't going to share bogus data or
run bogus clients.

Those last two human layers are our major weakness:  they aren't being
managed and quantified automatically.  So all of this stuff I'm going to
propose, and all I have proposed in the past, amounts to a way of taking
those things that humans naturally assume will be true and checking them
with the software.

That is...from a security standpoint, humans are stupid.  They will believe
what they see, because it's easier to believe what you see than to check the
facts first.  So we should build a framework that checks facts
automatically.

MANY THREAT MODELS

It's not completely black and white, whether something is abusive or isn't
abusive.  Flooding is abusive.  Sharing popular files isn't.  Spam is kinda
abusive.  Deliberately mislabeling files is abusive.  Labeling a file
vaguely, out of ignorance or forgetfulness, is slightly abusive.

In theory...if you had a human acting as a Blocks client, physically
inspecting each and every packet that went through his node, some abusive
traffic would get through.  Floods and obvious abuses would be stopped...but
subtle attacks could still continue:  vaguely named files, truncated
files...files that nobody cares about...people trying to download every copy
of their favorite mp3 all at once.

ABUSE DEFINED AS ECONOMICS

Why does email spam suck?  So little resource usage on the attacker's end,
so much resource usage on the victim's end.

Or to say it with economics:  To the attacker, resource cost is low and
utility is high...to the victim, resource cost is high and utility is very
low.  Resource cost in this case is bandwidth:  I can spam easily from a
28.8 modem and a few open relays.  I don't have to spend much money or time
or bandwidth.  For you...your computer might take a while to display the
email, or the email might load up some graphics or popups or something...so
that's a lot more resource usage than you really wanted to spend on spam.
Utility is high for the attacker, because they get a lot of 'good' out of
the spam:  lots of eyeballs see their ad, and maybe one in a million people
buy the product, because they're stupid newbies and don't realize that
supporting spam is bad.  Utility is low for you, because you don't really
care about making money fast right now.

Television ads:  for the 'attacker', resource cost is very high, and utility
is high...and for you, resource cost is low (you're watching TV anyway,
after all) and utility is...well...about medium.

BLOCKS AND ECONOMICS

How about some Blocks-related examples?

Well, Blocks is pretty much anonymous...so from a client standpoint, you
have no idea what their resource cost or utility is like.

Very popular movie files:  resource cost is very high here, because lots of
people are trading very large files...but utility is also very high.  If you
were to talk to everyone you're connected to, they'd probably all agree that
"It sure is straining the network to send all these files, but it sure is
worth it -- I've been meaning to go see that movie..."

Packet flooding:  resource cost is high, and utility is pretty much
nonexistant.

Content flooding:  resource cost is about medium, I guess...maybe high if
the content is pretending to be popular files, and is getting downloaded a
lot...and utility is pretty much nonexistant.

Obscure or unpopular content:  resource cost is low, because the content
isn't being requested that much...but utilty is also low, since the content
really isn't helping that many people.

AUTOMATIC ECONOMICS

Obviously, if a person could physically inspect their Blocks traffic, and
could talk to everyone they're connected to, it would be easy to optimize
the network.  All you have to do is look at the packets and
connections...keep things that are 'worth their bandwidth' and drop things
that aren't.

It sure would be cool if Blocks could do that automatically:  somehow decide
how much 'worth' each packet has, and decide whether things are over the
'worth' threshhold or not.

...and after that, I draw a blank.  I can barely even imagine where to
begin.

Maybe some systems could manage this by giving each node a certain number of
points...some kind of scarce economic resource, beans or dollars or
something...which is gained by being a successful information producer and
lost by being an information consumer.  This hurts leeches and helps
central-hub nodes.  But I can't imagine how to implement that without a
central authority...and I'm not even sure if that would be a good idea
anyway.  It's just a vague thought anyway.

The resource we're controlling is bandwidth (or packet traffic in
general)...and because of the anonymous and distributed nature of Blocks,
the only bandwidth we can measure and control with any certainty is our own.
Utility also has to be managed...and perhaps that can be measured by the
web-of-trust:  popular files that people like will have positive
utility...unknown, never-before-seen files have neutral utility...and files
that people routinely mark as spam and avoid downloading have negative
utility.

So if you can correlate resource cost with utility on your node alone, you
can kinda optimize your node so it'll benefit the most people for the least
bandwidth.  Maybe a very popular central-hub node is very sensitive to
resource cost...so if you connect there and send traffic, you'd better be
serving up some top-flight popular files or you'll get disconnected.  A leaf
node could connect to someone and start leeching...but they might find their
bandwidth squeezed down to a couple k/sec once the target node figures out
that the leaf node is a leech.

And you are always in control of your own bandwidth (random-UDP-packet
flooding to the contrary) -- if you ask someone to lower the traffic rate on
their connection to you, and they don't do it...just drop the connection.


OK, maybe this'll get some gears turning for you network experts.  My
experience ends with the encryption and web-of-trust stuff...so I hope this
gives you all some good ideas and starts some interesting discussion.  :)

--Michael Spencer
bl...@ms...

-----Original Message-----
From: lu...@et... [mailto:lu...@et...]
Sent: Monday, August 14, 2000 12:29 PM
To: Erik Moeller; blo...@li...
Subject: Re: [Blocks-development] Future Direction For Blocks


* Erik Moeller wrote:
> Before we go to ratings and authentication, we should clear the 
> scalability issue and possible routing/resuming problems.

Hurm.  Given the mess that Gnutella has become, I think it's very important
that we make sure that the blocks network is impervious (or at least
tolerant of) to:

- False announcements, advertising and other Bad data
- Flooding and other DOS attacks
- Bogus/incomplete data

It doesn't matter how spiffy the technology is, if it can be abused, it will
be.  *sigh*

-Luke

_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] Future Direction For Blocks

[Blat F. <pet...@ho...>]

>From: lu...@et...
>To: Erik Moeller <mo...@sc...>,        
>blo...@li...
>Subject: Re: [Blocks-development] Future Direction For Blocks
>Date: Mon, 14 Aug 2000 13:28:34 -0400
>
>* Erik Moeller wrote:
> > Before we go to ratings and authentication, we should clear the
> > scalability issue and possible routing/resuming problems.
>
>Hurm.  Given the mess that Gnutella has become, I think it's very important
>that we make sure that the blocks network is impervious (or at least
>tolerant of) to:
>
>- False announcements, advertising and other Bad data
>- Flooding and other DOS attacks
>- Bogus/incomplete data
>
>It doesn't matter how spiffy the technology is, if it can be abused, it 
>will
>be.  *sigh*

This is true, and Blocks suffers from all these classical problems :(

Possibly Michaels WoT idea might help eleviate some of these issues,
but in the meantime here are some other ideas (off the top of my
head... asbestos underpants are on :-) ...

1) Password lock servers/blocknets... so only 'authorised' people
   can join. This would allow private blocknets which is probably
   desirable anyway, but without WoT I cant see how it can be
   applied to the general anonymous blocknet.

2) Staticstical analysis can detect extreme flooding, but wont
   really help stop short burst flooders or slow flooding.

3) Spammers sending bogus ads are a real pain. Without strong
   authentication there is no way you can trust an advert.
   Explicitly checking the validity of the underlying file
   is infeasible (if not impossible). The only thing I can
   think of that might be appropriate here is some form
   of phyical violence... I wonder if there is a POSIX call
   to send an EM bust through the console like they always
   so in Startrek. I could equip block servers with a DDOS
   autotargetting facility, but that would get misused as
   well... still we can dream ;-)

Hmm... looking back at what Ive just written there doesnt
seem to be much content there :( But, hopefully, Michael
will have more to say on the WoT idea sometime soon.

ttfn

PG.




________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Future Direction For Blocks

[<lu...@et...>]

* Erik Moeller wrote:
> Before we go to ratings and authentication, we should clear the 
> scalability issue and possible routing/resuming problems.

Hurm.  Given the mess that Gnutella has become, I think it's very important
that we make sure that the blocks network is impervious (or at least
tolerant of) to:

- False announcements, advertising and other Bad data
- Flooding and other DOS attacks
- Bogus/incomplete data

It doesn't matter how spiffy the technology is, if it can be abused, it will
be.  *sigh*

-Luke

Re: [Blocks-development] Bandwidth Usage

[Erik M. <mo...@sc...>]

On 14 Aug 2000, at 15:20, Blat Froop wrote:

> Adding counters like 'blocks routed' or 'blocks routed in last
> 60secs' is easy enough

I think the latter is good enough. At least you know if your node is 
active.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

Re: [Blocks-development] Bandwidth Usage

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: [Blocks-development] Bandwidth Usage
>Date: Mon, 14 Aug 2000 05:04:14 +0200
>
>It might be helpful to have some information on the bandwidth
>currently used by Blocks. That way, I'd know if I'm cutting an upload
>before I shut down the server. (It might actually give me a warning
>if I try to shut down when bandwidth is in use -- but it would have
>to check whether it's blocks being routed or just adverts.)

Adding counters like 'blocks routed' or 'blocks routed in last
60secs' is easy enough, but it wont tell you if someone is at
the start of a big bulk download which is being routed through
your connection. Even if we could tell where we were in the
current file we dont know how many he (or possibly the hundreds
of others being routed through your connection) has queued up.

Its a bit like being an internet router except they dont have
a phone number to call when the plug gets pulled :-)

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Fucked up route

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: [Blocks-development] Fucked up route
>Date: Mon, 14 Aug 2000 04:56:30 +0200
>
>Here's a screenshot of a totally fucked up route. Take a look at the
>IP numbers: there are two connections to the same IP. Might that be
>the cause of the problem? Or perhaps a 0.14 server?

The .GIF didnt come out right, but Michael already sent my
a pic. My guess is that a V0.14 server routed the advert (you
can tell V0.14 corruption because they have a blank HASH: field
in the search window).

V0.16 will have a protocol version message to stop pre-V0.16
connections.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Bandwidth Usage

[Erik M. <mo...@sc...>]

It might be helpful to have some information on the bandwidth 
currently used by Blocks. That way, I'd know if I'm cutting an upload 
before I shut down the server. (It might actually give me a warning 
if I try to shut down when bandwidth is in use -- but it would have 
to check whether it's blocks being routed or just adverts.)
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>

[Blocks-development] Fucked up route

[Erik M. <mo...@sc...>]

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  route.gif
     Date:  14 Aug 2000, 4:54
     Size:  26297 bytes.
     Type:  GIF-image

[Blocks-development] Fucked up route

[Erik M. <mo...@sc...>]

Here's a screenshot of a totally fucked up route. Take a look at the 
IP numbers: there are two connections to the same IP. Might that be 
the cause of the problem? Or perhaps a 0.14 server?

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>