This is not an issue of figuring out how to do it, this is an issue of implementation.
The theory is simple: the node is writing to a file anyways, so just read as much as you can from the file in the send (File IO may be slow, but it is faster than network IO so this should not matter). In pratice, I found at least, Java was not very good at working with this sort FIFO file. So in the end I had to settle for simply reading a number of bytes of the input, and then writing it to each stream (the FileOutputStream, and the out sockets OutputStream) file (this is what the SplitOutputStream does). It is, however, possible that this could be done by writing and reading to a file at the same time. I'm not sure how well this works (if FileInputStream.available() will change correctly to reflect for data being written to the file by another thread, for example), but it should be more possible to do today then it was when I first wrote the tunneling code this winter (most noteably, there was no DataLength field then, so it would have been hard to know when the file ended). Feel free to code this (or at least try writing a test program that writes and reads from a file by two different threads and say how well it works), somebody. On Tue, 11 Apr 2000, awlydick wrote: > > Er, I don't think you have thought this through (or maybe I haven't!). > > If you are writing to the file at the same time as streaming it to the > > next node, then by the time you have finished writing to the file, you > > will have finished streaming the data too! > > > > Ian. > > Correct me if i'm wrong, but the cause of the delay is the other node taking > longer to stream then it would to just stream to localhost. If we streamed > to the other node as time/bandwidth allowed, while (in parallel) streamed to > the local (or target, if inserting into a remote node) file as fast as data > could be sent by the client. Then, once the client was done streaming, it > could > disconnect, and go on its merry way, while the node that accepted the > insertion > from the client could reopen the inserted file from the datastore and continue > streaming where it left off. > > Ex: > > The players: Node1, Node2, Client > > Client Connects to Node1. > > Client tells node1 it is inserting data and waits. > > Node1 sends off its DataRequest and waits. > > Node1 gets back "Not found" or whatever the message name is and > allows the insertion. > > Node1 allocates a buffer for Node2 to stream from and tracks the position in > the data stream that has thus far been appended to the buffer. The buffer is > streamed to Node2 as fast as is appropriate. > > Incoming data is appended to the buffer (until the buffer fills up), and is > also written to the local datastore. > > After the write is finished, the local copy of the file is reopened and > streamed to Node2 as whatever rate it accepts. The client may safely > disconnect > at this point. > > NOTES: > > This won't have an impact on streaming performance with high bandwidth > connections, as they were accepting the stream as fast as the client could > send anyway. For nodes with lower bandwidth neighbors, this will avoid the > client having to wait on them to finish streaming. > > Tell me if this is flawed :-) > > Regards, > > Adam Lydick > > -- > Freenet -- Re-Wiring the Internet > http://freenet.sourceforge.net > My Node: tcp/rivendell.yi.org:19114 > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
