On Thursday 29 January 2009 20:38, Thomas Sachau wrote:
> Daniel Cheng schrieb:
> > On Thu, Jan 29, 2009 at 12:34 AM, Matthew Toseland
> > <toad at amphibian.dyndns.org> wrote:
> >> On Wednesday 28 January 2009 04:12, Daniel Cheng wrote:
> >>> On Tue, Jan 27, 2009 at 10:20 PM, <toad at freenetproject.org> wrote:
> >>>> Author: toad
> >>>> Date: 2009-01-27 14:20:37 +0000 (Tue, 27 Jan 2009)
> >>>> New Revision: 25310
> >>>>
> >>>> Modified:
> >>>>
branches/db4o/freenet/src/freenet/client/async/SimpleManifestPutter.java
> >>>> Log:
> >>>> Fix another of TheSeeker's transient NPEs, this time caused by FMS
doing
> >> transient ClientPutComplexDir's (why it does a putdir i have no idea...)
> >>> FMS insert a freesite for user who opt-in.
> >> Hmmm, what I heard was it used ClientPutComplexDir's for *lots* of things
e.g.
> >> message lists, not just the freesite ... is this true?
> >
> > [overland]$ grep -r ClientPutComplexDir src/
> > src/freenet/introductionpuzzleinserter.cpp:
> > message.SetName("ClientPutComplexDir");
> > src/freenet/messagelistinserter.cpp:
> > message.SetName("ClientPutComplexDir");
> > src/freenet/siteinserter.cpp: message.SetName("ClientPutComplexDir");
> > src/freenet/trustlistinserter.cpp:
message.SetName("ClientPutComplexDir");
> >
> > It use ClientPutComplexDir for all USK.
> > Messagelist USK are for backward compatibility with old client (iirc)
> > and can be removed .
> >
> > No idea why ClientPutComplexDir is used, though.
>
> from SomeDude @ FMS:
>
> > The Seeker at cI~w2hrvvyUa1E6PhJ9j5cCoG1xmxSooi7Nez4V2Gd4 wrote:
> >> > Sites I can see, but why intruduction puzzles, message lists, and
> >> > trust lists?
> >
> > Only the Freesite and Message List insertion rely on USKs. The reason
> > for the ClientPutComplexDir is that ClientPut doesn't work as (I)
> > expected with USKs that have filenames. You would think you could
> > request the USK including the filename and get the data, but you cannot.
> > Freenet returns a "Too many path components" error for such a request.
> >
> > This is easy to see. Just generate an SSK and do an insert and request
> > like the following:
> >
> > ClientPut
> > URI=USK at privatekey/clientput/0/one.txt
> > Identifier=clientput
> > UploadFrom=direct
> > DataLength=1
> > EndMessage
> > 1
> >
> > ClientGet
> >
URI=USK at
JeNSgMBP85X7bpq1FUMdBayrmXAGmzTLezCl34Tps~o,Xd~eJWyFRt3KrZx3U-JS4ty9qrMwoq3Zzq4Jb2Ao70I,AQACAAE/clientput/0/one.txt
> > Identifier=clientget
> > ReturnType=direct
> > EndMessage
> >
> > This ClientGet returns "Too many path components." If you remove the
> > filename from the USK and add a TargetFilename like the following, the
> > same error is returned upon request.
> >
> > ClientPut
> > URI=USK at privatekey/clientput1/0/
> > Identifier=clientput
> > UploadFrom=direct
> > DataLength=1
> > TargetFilename=one.txt
> > EndMessage
> > 1
> >
> > ClientGet
> >
URI=USK at
JeNSgMBP85X7bpq1FUMdBayrmXAGmzTLezCl34Tps~o,Xd~eJWyFRt3KrZx3U-JS4ty9qrMwoq3Zzq4Jb2Ao70I,AQACAAE/clientput1/0/one.txt
> > Identifier=clientget
> > ReturnType=direct
> > EndMessage
> >
> > Now, if you insert the same data using a ClientPutComplexDir, it works
fine.
> >
> > ClientPutComplexDir
> > URI=USK at privatekey/clientputcomplexdir/0/
> > Identifier=clientputcomplexdir
> > DefaultName=two.txt
> > Files.0.Name=two.txt
> > Files.0.UploadFrom=direct
> > Files.0.DataLength=1
> > EndMessage
> > 2
> >
> > ClientGet
> >
URI=USK at
JeNSgMBP85X7bpq1FUMdBayrmXAGmzTLezCl34Tps~o,Xd~eJWyFRt3KrZx3U-JS4ty9qrMwoq3Zzq4Jb2Ao70I,AQACAAE/clientputcomplexdir/0/two.txt
> > Identifier=clientget
> > ReturnType=direct
> > EndMessage
> >
> > This ClientGet returns the data, 2.
> >
> > These are actual keys I used to test this, so you can request them and
> > see the issue.
AAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHH!
Seriously, do you have any idea what a slash means in the context of a freenet
key?
Let me explain:
Basic keys:
CHK at blah,blah,blah
SSK at blah,blah,blah/filename
KSK at filename
Then we have USKs:
USK at blah,blah,blah/sitename/27
Is stored as
SSK at blah,blah,blah/sitename-27
With metadata, we can have any directory structure we like under a key:
KSK at blah/blah/blah
HOWEVER, this is done by creating a metadata manifest (aka directory)
containing blah/blah, and then inserting it under KSK at blah. If KSK at blah
is
already taken because somebody inserted KSK at blah/foo/bar, we *cannot* insert
KSK at blah/blah/blah.
Furthermore, whenever we create metadata, because a file is too big to insert
as a block, because we specified a filename or because we specified a MIME
type, it costs us an additional fetch. Having said that, if the data being
inserted is between 1K and 32K, we will have to create a CHK to put it in
anyway, and the SSK is then metadata - so it doesn't cost you much to put
filenames etc in.
Now, in something like FMS, you should avoid metadata at all (reasonable)
costs. There is no point in setting a filename or a MIME type. With the
exception of inserting freesites, you should always just insert a key.
Because it saves you a fetch.
I apologise for the lack of communication that resulted in this mess, however
it will only end when p0s's Freetalk is working. I will not review a
mechanical port of FMS to Java, since Freetalk is very nearly working and
could easily be made compatible with FMS. I will not review FMS itself,
because we cannot bundle it and reviewing code we can't bundle just makes you
miss deadlines. If you believe we should bundle FMS then you will need to
convince Ian. IMHO Freetalk has major architectural advantages through being
two plugins.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090129/590ed047/attachment.pgp>
