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. 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. On Fri, 28 Jul 2000, you wrote: > > I'm going to write another Freenet node implementation. This > implementation is going to be in plain ANSI C, not C++. It will use > an encrypted datastore which is designed to be quite scalable. The > datastore will not be a flat directory full of files whose names are > the hashed keys for those files, but rather a tree of directories. > I've figured out the semantics for this, but I don't have time to > explain them right now. Anyways, the name of this freenet node is > going to be nfreenetd (the n differentiates it from Whiterose, which > might use the name freenetd) and it is targeted at Unix/Linux > systems. It will be designed with mainly security, stability, and > scalability in mind, and speed will mainly be a side effect from it > being written in C rather than Java or C++. Yes, I am going to make > sure to check array bounds when I have to use fixed arrays, and I am > going to avoid fixed arrays like the plague. This practice will stop > crashes from overrunning arrays and buffer overflow exploits (which > are particulary nasty as exploits go). Note that I haven't written > this yet. > > -- > Travis Bemann > Sendmail is still screwed up on my box. > My email address is really bemann at execpc.com. ---------------------------------------- Content-Type: application/pgp-signature; name="unnamed" Content-Transfer-Encoding: 7bit Content-Description: ---------------------------------------- -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
