On Thursday 29 January 2009 20:38, Thomas Sachau wrote: > Daniel Cheng schrieb: > > On Thu, Jan 29, 2009 at 12:34 AM, Matthew Toseland > > <[email protected]> wrote: > >> On Wednesday 28 January 2009 04:12, Daniel Cheng wrote: > >>> On Tue, Jan 27, 2009 at 10:20 PM, <[email protected]> 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 see...@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=...@privatekey/clientput/0/one.txt > > Identifier=clientput > > UploadFrom=direct > > DataLength=1 > > EndMessage > > 1 > > > > ClientGet > > uri=...@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=...@privatekey/clientput1/0/ > > Identifier=clientput > > UploadFrom=direct > > DataLength=1 > > TargetFilename=one.txt > > EndMessage > > 1 > > > > ClientGet > > uri=...@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=...@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=...@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: c...@blah,blah,blah s...@blah,blah,blah/filename k...@filename Then we have USKs: u...@blah,blah,blah/sitename/27 Is stored as s...@blah,blah,blah/sitename-27 With metadata, we can have any directory structure we like under a key: k...@blah/blah/blah HOWEVER, this is done by creating a metadata manifest (aka directory) containing blah/blah, and then inserting it under k...@blah. If k...@blah is already taken because somebody inserted k...@blah/foo/bar, we *cannot* insert k...@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.
pgp81hzWmgWLe.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
