On Fri, Jul 28, 2000 at 10:28:12AM +0700, Oskar Sandberg wrote: > > a) Trust me: It is harder then it seems. > b) Why nfreenetd? This is just like all the clients being called "GUI Freenet > Client" , "Freenet Client GUI" etc. If you don't want to think up an original > name, why not at least try to make it a little catching like "freedm" > (short Freenet Daemon) for example.
But then, "freedm" doesn't fit standard Unix/Linux daemon naming conventions while nfreenetd does. Note that the full name of nfreenetd is "Alternate Freenet Node Daemon". > c) Some advice: > > The node logic as regards to receiving a message and sending it on is not that > difficult. It is complicated by requirements regarding conversations with > broken nodes and alike (being able to properly restore chains on no reply), > but > not beyond easy. The DataStore is pretty straightforward, writing a flat O(n) > closest search system like the Freenet nodes should be fairly trivial (make > sure > lookups are not O(n) though). Writing a O(log n) one was not that difficult > either, but it may depend a little on ones comfort with designing ADTs. I > don't > really see what difference having a directory tree on the disk makes. > > The message presentation is very simple. The crypto is the crypto - if your > Scott you'll find it simple, if you mortal you'll have a major headache. Some > of Scott's auxiliary work surrounding the crypto, like the full Yarrow > implementation, isn't exactly stuff that most coders through together over > night. > > The most difficult part that I have delt with, and I think it would be even > harder in C without Java's lovely threads, is (interconnected) the handeling > connections, messages, and streams. Because the Freenet protocol makes no > assumptions on the relations between Message chains (as identified by the > UniqueID on the messages) and the connections over which they are received, > you > need to properly seperate the reading of messages and handeling of them. This > is further complicated by the fact that when you have a stream of data to > handle, you very much need the actual connection. The stuff that I have been > slaving to try to get working correctly the last week or so, namely the > verification of data streams and accurate handeling/stopping/restarting of > broken ones really brings this to a max. > > Good luck. Actually, there is even more to it than what you said. First, users have to be able to request data that is also being requested by another user when the data is coming from a different node. This would involve a good amount of communication between processes or threads (I'm probably going to go with processes for nfreenetd because they are easier to debug and you don't have to go and make everything reentrant and thread safe). Another thing which should be done is timeouts so that connections don't stay forever after a node or transient node at the other end suddenly drops its connection. The current reference implementation appears to have the problem of not using timeouts. -- Travis Bemann Sendmail is still screwed up on my box. My email address is really bemann at execpc.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 2665 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000728/6d6cbdae/attachment.pgp>
