On Fri, Jul 28, 2000 at 08:01:57PM +0700, Oskar Sandberg wrote: > On Fri, 28 Jul 2000, you wrote: > > > > 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". > > I am a huge fan of naming conventions. I believe they should always be > followed. > > Come on, I though that it was MS who were the borg...
Heh. But then, having a nice 'd' at the end of a program's name easily indicates that the program is a daemon, not a user program. Yeah, this is a naming convention, but it is not a bad one (unlike Hungarian notation). > What disqualifies our java program from being a daemon btw? Shouldn't > Whiterose be nfreenetd and yours n2freenetd or something then? Technically, the Java reference node is not a daemon because it doesn't detach itself from the invoking process and give itself a new process group. Of course, this is do to limitations of the Java standard libraries. Anyways, Whiterose could be just freenetd or wfreenetd. But then, calling the Java reference node not a daemon is quite pedantic. > <> > > 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). > > Since you have be able async the receiving of data and sending of it, you are > best off writing the data to a file as it arrives, and then streaming the > outgoing stream from that file. Allowing more then one stream to access the > file is not a problem. One problem is that a node should be able to allow data larger than its datastore to pass through it (unlike the current implementation). Of course, if there is not enough room in the datastore to store a file, you could just have other requests at the same time request another node for the same data, but that would be inefficient and wasteful. One solution would be soft datastore sizes, where the incoming file would be saved to file even if it was bigger than the entire datastore, and then the file would be deleted once all the concurrent requests for the file were finished. Another way to do this would be to store the file in shared memory during the concurrent requests. However, I prefer soft datastore sizes. > Knowing what to do if the data that all those streams were reading turns out > to > be false is a lot more complicated. > > > 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. > > Not AFAIK - there is code in there to kill off connections after a period of > inactivity. If it is broken (which I don't believe it is, I tested it after I > implemented it) it is some bug, it is still not something very difficult to > implement. I have heard people say that the nodes eventually hang after connections being made but later dropped. This is just hearsay (it appears that the JVM I use is broken (it segfaults when I try to use freenet_request or freenet_insert)). -- 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: 3019 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000728/05e83778/attachment.pgp>
