Re: [Blocks-development] Filesharing concept discussion: limited resources, and queueing...

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

Hey! Good to see there is still some interest in anonymous P2P
and maybe even Blocks :-)

>
>I've had some ideas gnawing at me for the past while, and if any of you are
>still out there...I'd like to bounce the ideas off of you guys before I try
>to post some incoherent ramblings to infoanarchy or shouldexist or
>something.
>
>I'd like to talk about some potential features for filesharing systems:
>
>1)  queues
>

Good idea, but wont people just disconnect when it says its going
to take more than 5 mins? Most users are very impatient, thats
why unfriendly ftp clients which open several connections to
the same file are so popular.

>
>2)  less interactivity of service...batch service?
>

Im not sure batch mode for user interaction is a viable idea,
however, for content replication between servers both
queuing and batch mode are pretty interesting. Obviously
its more elegant to have a single ubiqitous mechanism
for both if at all possible.

>
>3)  More human interaction
>

WoT is the key to stopping spamming, but its needed on the
adverts (or search results) rather than just the data. Since
there will be more info packets than data packets efficiency
is always going to be a problem. Perhaps you could send info
packets in larger 'conatiners' which are signed in some way?

>----
>
>BTW, early February I accepted a position as a programmer at a credit card
>processing company here in town.  I can't believe I was always afraid of
>Windows programming -- now that I have (financial) motivation to sit down
>and figure the stuff out, I'm doing great!
>
>Perhaps it's time to reinvent Blocks...but this time with two or more
>programmers.  ^_^

I think the idea is sound, but competeing with the likes of
BearShare is going to be difficult. What about perhaps
trying to design a distributed anonymous GNUtella backend?
I guess the sucky P2P protocol would allow the men in black
to shutdown the point of content tho :-(

>
>----
>
>With the recent developments in OpenNap server operators coming under
>attack, it's becoming clear:  no matter how legally sound your position is,
>someone with power can still lash out at you if they can find out who you
>are.

You have to make it ineffective cost wise to shut down
servers, and the bad guys have bundles of cash. Not impossible
though, even the old Blocks servers would require a lot
of effort to prove it did anything wrong.

>
>I've been thinking about how Blocks was designed.  If I'm remembering
>correctly...if we don't readvertise files to new connections, and if you
>make *sure* that you aren't connected to someone you don't trust at the 
>time
>you share a file, it's impossible for someone to pull a MediaEnforcer on 
>the
>Blocks network.

Yup, that was the key fact. You never know if the server you
are connected to is just a proxy or in fact the real server.
Assuming not everything gets cached (like freenet) and the
proxy logic has sufficient randomness in data acquisition
(doesnt need much) its a *huge* effort to apply statistical
analysis without being able to directly snoop on the
server in question.

>
>Think about that for a minute:  not even Freenet can claim that level of
>immunity.  On Freenet, the act of requesting content (to check for its
>presence) causes the content to be replicated to that machine.  There's 
>some
>legal protection there, although I'm not a lawyer.  However, the attacker
>can merely go to the ISP and say "I represent this really big organization,
>and we would appreciate it if you stopped this user from running this
>perfectly legal service.  Besides, the user is consuming a much higher than
>average portion of our upstream bandwidth, isn't it?  It'll save you money
>in the long run to remove users like this from your service! *nudge nudge*"
>A Freenet node can be shut down merely because it's a node on an 
>*unpopular*
>network.
>
>Blocks doesn't have established port numbers.  With a little work, it could
>even have a difficult-to-guess protocol, requiring either some 'hash cash'
>or a bit of information that proves you learned about the IP and port
>through the network, not through a host scan.
>
>Ooh...wouldn't that be cool?  Your first connection to the first server
>would require that you connect to a port, and without reading *any* data,
>compute and send 50-million-operations worth of hash-cash to a 'mute'
>socket, before the other end would even talk to you.  That would certainly
>chill efforts to scan hosts for open ports, checking to see if any ports 
>are
>running Blocks nodes.

Just listen to a few (say 5 ports) immediately above and below
the real port. If anyone tries to connects to these, shut down
the main socket and go into stealth mode for a while. That
would defeat 99% or scans. Wont stop people hacking the Blocks
protocol though, any distributed system needs to be able to
locate and connect to other nodes.

Actually thinking about it, locating servers is a task best
done outside of the servers themselves. You just need a
simple server which dishes out the last 100 ips/ports when
it receives a new connection. It can then add the new ip
(and I guess port) for this connection to the list. The
bad guys can shut it down because it has nothing to do
with data.

>
>----
>
>If my tone just changed...it's because within the last three paragraphs I
>suddenly realized that Blocks is providing something that *no other 
>service*
>can provide right now.  It's enough to make me want to pick it up and dust
>it off and start hacking again.

What about encryption? none of the others did that either :-)

>
>I just installed a new 40 GB hard disk.  Once I confirm that UDMA is OFF
>(it's a CRC-skipping Western Digital...it was cheap) I'll put a 30 GB 
>Blocks
>cache up on michael.mspencer.net port 8017 ^_^
>
>Have some anime.  Cowboy Bebop is definitely top-shelf anime, if you don't
>mind reading subtitles.  And it has nothing at all to do with cowboys or
>be-bop.  Ignore the funny name and give it a chance.  ^_^
>
>----
>
>In an attempt to make a 'real programmer' out of me, the CTO has had me
>flowcharting our existing code.  For the past two weeks.  I think I'm
>starting to like it.  *shudders*
>
>I'm going to try to create a flowchart of the current version of Blocks.
>Once I understand the code (and can help others understand the code, 
>through
>flowcharts), I'd like to start working on Blocks myself.  Probably starting
>with a Windows-only ugly stepchild version.

Heh, Blocks was never well designed and is full of kludgy bits.
The network code is quite well contained and very portable tho.
FLTK rocks... check it out before you decend into the hell that
is MFC.

>
>(I can see it now -- instead of falling into the usual trap of making a 
>full
>dialog page for connection information, I'll be like Napster...but I'll say
>"Disconnected"  "Kinda connected"  "Connected"  "Very connected")
>
>That does it.  I need to go to sleep.  Please, let me know what you think
>about both the broad filesharing system ideas and about dusting Blocks off
>and standing it on its feet again.
>
>Also...I've started hosting the Blocks homepage (kinda) at
>http://www.mspencer.net/blocks

Ive got them on CD somewhere... have to check.

I got my own internet connection in my apt now (10mbits!) but
its having a few teething problems, and the next couple of
months are going to be hectic workwise for me. Still, good
to hear there is still some interest in these concepts :-)

ttfn

PG.

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